|
> Why not use the actual language or framework your engineers like instead? Consistency and predictability, but with a more convenient technology underneath. I don't want to mess around with JDK runtimes or .NET. I don't want to experiment with various static packaging techniques and wonder whether any sort of reflection will be incompatible with that or any of the large frameworks that pre-date it will work. The runtimes themselves are good, but that's just busywork. At the same time, I do want the ability to pick up a project made with a certain framework and approximately know how things work and how to do stuff. Less undocumented internal utilities and custom libraries, more of something predictable - controllers here, services there, repositories over here, here's how the ORM works that's tightly integrated with everything else, here's how you make a RESTful API. Think more like Angular than React to use a good front end example (e.g. a pre-packaged setup with batteries included). Or, you know, a direct comparison between the likes of Ruby on Rails, Laravel, Django, Spring Boot, ASP.NET etc., maybe not verbatim, but something consistent and close enough. Go's standard library is also pretty good and includes a lot of stuff. The IDE experience is good (no need to even think that much about configuring your own code formatting), the compiler is good, platform support is good, runtime performance is good while the language remains higher level and easier than the likes of Rust, it's not hard to get everything into a single self-contained executable. There's numerous projects that have sprung up around that, even something like K3s (full Kubernetes distribtion) can be downloaded as a single file. Also really good for just CLI utilities, or full blown desktop apps (e.g. with Wails). In other words, to take the technological advancements, shed the legacy cruft and still be able to have many projects be predictable and keep the productivity high, regardless of whether the greater language community is more interested in a grab bag of more self-contained libraries. |
I personally believe that it is a much better language and ecosystem, and wouldn't bother using Go which has way more boilerplate, has pretty bad expressivity (so that libraries/frameworks will suffer from a usability perspective, e.g. look at JOOQs, a completely type-safe SQL query builder) for negligible benefits.