|
Top-level
 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/ 4 comments
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. |
Gregory's Server
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/