|
Top-level
 But beyond that, if you were working on a large software project in Java or C++ you likely had a lot of very powerful tools in your IDE. You had a strong SDK and tools that worked with it. You had a robust development environment. You had powerful frameworks that had been battle tested for years and dependency managers that, while everyone complained about them, they mostly _worked_ and their quirks, while not solved, were also not blockers for most work. So for a lot of us it wasโฆ okay? 6/ 33 comments
Developers were graduating with better and better knowledge of the systems we worked with. There was one of the big pushes in category theory that seems to happen every few years going on. The developers who _had_ graduated _years_ ago weren't leaving industry but they _were_ getting older. People were looking at concepts like pattern matching and fp. Go was explicitly made for new graduates, but developers are only new graduates (if they are graduates at all) for a very short period of time 8/ So along comes go and in every respect it seems to be looking backwards, but not in the way that the industry rediscovers actors every ten years or so. It wasn't rediscovering the past, it was flat-out tacking that direction. But. A language existed that was sometimes used for servers but was used for a _lot_ of utility scripts and applications and that a lot of people struggled with for large projects. Where there were already libraries for CSP but they were used but inconsistently. 9/ Python developers often really liked Go and SREs who had to maintain major python projects REALLY liked go There were IDEs for python, but they weren't at the level of maturity that Java or C++ had. They were dynamically typed and so a little type safety often felt like an improvement rather than a step backwards. The fast compile times were appealing, and the style guide appealed to a group who believed "there's one obvious right way to do it" We saw a lot of go taking over in that space 10/ 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/  @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 @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. @hrefna the โone right way to do itโ is a direct contrast to scala -which I wanted to love- where there are 5 right ways to do it and every shop has its own style guide, making learning the language as an itinerant contractor impossible. I ended up going back to modern java (for preference) and learning golang for new customers. @steely_glint I programmed in scala seriously for several years. I have been on scala projects that were _great_, easy to read, cleanly codedโฆ โฆand also ones that aren't IME you need really tight discipline to make it work and it helps if you have a small team that's all relatively senior and dedicated to quality. When I've had that, I've really seen the elegance Whenever I see a large project that doesn't check those boxes and managed to not be an eldritch nightmare I can't help but applaud. |
Gregory's Server
We had incremental compilation, so the only time you had to do a full compile was on the CI/CD infrastructure. It was often still painful, but we were finding more and more ways around it with good build tools.
We had autocomplete. We had extensive refactoring tooling.
We had subtypes and a lot of strong language features that made it _easier_, not harder, to read on our large software projects.
What's more, there was a lot of looking to the future.
7/