They made Go faster (priorities), added some very niche number types and TLS 1.3 support?
The only language features they seem to have added are small improvements to error handling.
The only language features they seem to have added are small improvements to error handling.
It's mostly not new number types, it's new number syntactic niceties.
As the guy who ends up maintaining the build tooling at work, I'm _very_ excited about a lot of the tooling changes:
- "Reproducible builds (independent of build path)" means 2 things to me: That customers building plugins for our product will no longer need to care about how our CI set GOPATH, and that I can drop hacks around the linker on macOS including timestamps (which would otherwise result in expensive Docker rebuilds)
- "Let 'go build' write many binaries" will let me adjust the build scripts to be faster, especially in mostly-no-op cases that my coworkers like to gripe about how slow it is.
I'm also excited about os.UserConfigDir.
priorities == latency control.
In fact, since the scheduler is now more complex, there will be more overhead (however small) and hence slower overall.
Time to move back to JavaScript.
It’s very frustrating how unstable and slow in terms of dev speed things are in the last THREE places I’ve worked (as a frontend with the backends all written in Golang). Go teams seem to rebuild everything from scratch and they never seem to understand micro services in the context of distributed systems. I mean we are doing microservices, Golang, grpc, cockroach dB and we have a few thousand users maximum. It drives me up the wall that this stack is so popular and the engineers championing it can’t deliver reliable software quickly in it... most of them can't even optimise queries in SQL and are concatenating strings together in SQL queries.
Take the Elixir ecosystem; I could outpace a team of three Golang engineers easily writing stuff in Elixir and my software would almost never crash or panic and be very flexible when changes were needed. Everything in Golang is calcified around current product requirements and a nightmare to change. So forgive me when I think Golang has a long way to go before it's something I'd want to use for anything but the smallest of command line tools.
I never said my code is perfect or bug free at all, you just made up a straw man to weaken my anecdotal evidence.
You can add a datapoint to that based on what I have experienced as well at an employer. Exactly what you mentioned, so much time wasted either due to reinventing the wheel, or because of language friction and it being way underpowered to model the problem at hand. I keep laughing that Java would have been a way superior fit in practically all fronts.
and, once again imho, this state of affairs is _exactly_ right as well. newer h/w, a deeper perspective on what works and what doesn’t all contribute significantly to this flux.
embrace the change :)