|
Top-level
 Basically: the execs notwithstanding, most engineers didn't see go as a silver bullet but as a nice enough tool in the toolbox, especially for writing, say, command line utilities or simple web servers. C++ and java devs weren't willing to sacrifice the performance or more sophisticated typing, packaging, etc. They had tools to reduce the complexity they had to deal with and go seemed to shove all of that complexity at them and say "BUT THIS IS A SIMPLER WAY OF DOING IT." 11/ 26 comments
@12 heh, I know this is rhetorical, but I actually can take a pretty reasonable stab about where that aversion comes from if you'd like. :p  @hrefna fucking please. There are two few languages that we can get our head around, and golang is, almost, one of them. except for that bit. @12 So it comes out of a combination of type theory, a counter-culture reaction to Java, some thoughts out of structured concurrency, and Rob Pike et al's desire to "simplify" the language by pushing complexity onto the developer who is writing the code. It works a bit like this: When you call a function it will have a return value with an associated types. Errors are just another kind of type, so if your program has a type `T` then with the exception it becomes `T | IllegalArgumentException` @hrefna our brain learned: ``` @12 Try-catch blocks evolved from how these errors often cluster and how we want to intercept them and wanting to avoid eight million if-else blocks. That's the plus side. The downside is that the error can come from anywhere in the block of code and anywhere in that block of code's call stack. It may have weird handling requirements (like Interrupts) or may be a nop, or it may never happen in reality. @hrefna we've found ChatGPT helpful, yes, we know, in figuring out golang withot fighting with tutorial sites. We're like, ok, show us how to do this. And from that, we can see how it does the thing and do the thing ourself like @12 I actually like the AI tools for this sort of thing, personally. Sometimes they can help illustrate something that is difficult to see otherwise. I've used bard to learn cypher and a few other things like that because while its coding is atrocious it can often help with the things no one talks about. @hrefna right! And like tutorial sites are like, here is this simplified thing that you don't want to learn. We learn best by seeing how others do it. Sidenote: good gods software *engineers* are scary. build systems and test cases and dependency management and release tagging and shit, where we're from you're lucky if you get a `cc -o dothething -I./src/common -I./src/thinglib thinglib_core.c thinglib_tui.c dothething.c dothething_plugins.c` @hrefna we're a software hacker in the 1980s unix sense. It plays right hell with our atempt to get a job, too @hrefna yeeeesh. We feel like as a kid we learned like a weird bastardised combination of C and Python? and that has just absolutely stuck with us, and then we learned C#......... of the terrible projects we created in C# we hall not speak @12 My first language was hypertalk, which is a bizarre language but also a very cool one. It's _really_ hard to shake early paradigms with languages. I'm generally of the view that languages are easy, but learning the ecosystem is difficult and learning paradigms is difficult I've seen programmers with decades of experience segfault entirely when running into a different paradigm. So you aren't alone in that, and in this case they picked up none of the things that makes that patternโฆ work. @hrefna yeah, the paradigm we learned was... very C-style. Very very C. Not that we can hack it in C; the only thing we ever wrote in C were some truly dirty Linux kernel hacks @12 But in go you: a) Lack generics So you end up with code that is extremely verbose and contains a lot of if-else-if-else-if-else calls. Which even for someone who prefers to avoid try-catch blocks in languages with good semantics for it makes me _really_ twitchy ^^;; @12 Oh, and one more note on this, in the languages with operator overloading this becomes downright _clean_. It becomes something like: RunSomething >>| do_something_with_result >>| do_another_thing >>= deal_with_errors |> add_callback Now it can even be concurrent and still nice and clean, with no changes to the code. Which is why a lot of people like this pattern, but it does involve a different way of thinking, and I'd argue its absence from go is keenly felt. The execs insistence here was especially painful for _data engineers_ because our lives revolved around taking data from one place, applying a series of transforms to it, and putting it somewhere else. The steps were often very similar to each other but with differently shaped data, so we could reuse a lot of code in a lot of cases. Do you know what languages make that easy? If you answered _anything with parametric polymorphism/generics_ you are most likely correct. 12/ I want to emphasize: None of this is really a flaw in Go _per se_ (well, some aspects may be, but I'm not talking about that right now). Go has a pretty strong core and it works well in that area. There are a lot of go programmers, and a lot of the issues I'm describing have been smoothed over with time, and execs have become lessโฆ enthusiastic. It does mean I think thatโfor what Go was initially being advertised forโa lot of people who were already in that space found it difficult. 13/ It works "well enough" in that space but it is just "well enough." Its advantages were muddled when compared to languages like Java, C++, and C# and it wasn't _clearly_ better, which made adoption difficult against those languages. It's still managed at points, but it's because a team evaluates the tradeoffs and finds that it fits, not because it is head and shoulders better (like, you know, everyone in industry for more than six months would expect). 14/ It goes back to: there are no silver bullets. You can't just rub a programming language on top of bad practices and get a good result. You are going to get a bad result regardless of what language you are writing in, and safeguards can backfire in a large enough project because they make things difficult to reason about or adequately test. Anyways, I may have more to rant about on this eventually, but I'll leave off for right now. 15/TBD @hrefna one thing that golang โkind ofโ is a silver bullet for is not having to worry about the concurrency model with libbashing an app together, which was my main pain point in c++ and python (when I used to do Java I wasnโt writing systems so dodged that problem) and was something not entirely settled the last time I built something in rust. The โdeveloper hostilityโ is felt in the terse tools as well. Itโs getting better, but compared to rust or JavaScript it feels of another century. @hrefna interesting read. I am a "hobby programmer" - as in I write really small projects once in a while for my own enjoyment/use, and personally I really love Go. It feels like I have more control than python but much less of a hassle than C. so I think the statement made here is very correct, at least anecdotally. |
Gregory's Server
@hrefna in our experience with golang, we only hae one objection:
Who, in their fucking right mind, decided that `try: catch: finally:` blocks were bad? like, fuck sake