I do not understand the appeal of go.

> The proposal argues that Golang developers are forced to work around language when writing hash-based data structures like Tries or concurrent hash maps. Developers who want an efficient hash-based data structure have only the builtin map to choose from. When this issue was originally created in 2017, Golang didn't have generics

And then the author goes to tell us about how this is not a stable solution.

I get wanting to solve a problem, but at what point into fighting the language, to accomplish something simple, do you take a step back and just pick a better one?

The appeal of Go:

- A pretty simple, if not very expressive, language (it's anti-Perl, and seems simpler than JS); you can learn it down to a reasonably productive level in a weekend. (I did.)

- A memory-safe language (like Java) with good performance (like Java) without the need to install any runtime, and the ability to ship as a single binary (unlike Java).

- A reasonably good and ergonomic concurrency approach (like JS, unlike Java), based around channels, not futures, and able to embrace multicore parallelism (unlike JS, like Java, and somehow like Erlang).

- Highly opinionated, well-crafted built-in data structures (like Python), and a general approach discouraging you from rolling your own.

- Good cross-platform support; fast compilation.

That is, it's a language that works well in a case where most of your team is junior devs, and you write some kind of a network server. The devs are forced to follow simple, if repetitive and wordy, patterns, and are limited in their ability to raise creative mayhem in the code base, all while writing reasonably performant, concurrency-friendly code that's a piece of cake to deploy. Combined with some overview from more senior folks, this should work reasonably well (and apparently that's what how it works at Google).

No. it's not a joy to use, it has warts (or, rather, deliberate compromises) in many areas, it requires boilerplate which pushes the user towards copy-paste programming, etc. If you can afford to not use it, don't, but sometimes it's the easiest tool for a job, much like, well, PHP.

Possible with GraalVM. Has been possible if you were willing to pay long before that. GraalVM produces statically linked binaries with only one external dependency — zlib, which is preinstalled pretty much everywhere. Startup time is measured in milliseconds.

I recently built a mid-size REST backend with quarkus — it ships as a single binary with size comparable to what I'd expect to see if it was written in Go, and starts in about 200 ms (from executing the command to when it's ready to serve its first request).

Having written code in both, I hope GraalVM buries Go in the long term, but in our hype-driven culture it's unlikely.

https://quarkus.io/guides/building-native-image#configuring-...

https://github.com/oracle/graal

> A reasonably good and ergonomic concurrency approach (like JS, unlike Java)

This is also very close to being solved.