[StevePerkins]

I would wager that the vast majority of backend software jobs are for people writing REST API microservices, exchanging JSON, with a mindset that is more practical and "blue-collar" than academic.

Golang is an absolutely ideal language for writing REST API microservices, that exchange JSON, with a practical and blue-collar mindset.

Plus it compiles to small-ish native executables. Which renders Docker superfluous in many uses cases, and also makes it well-suited for writing DevOps tooling (e.g. Docker, everything from HashCorp, etc).

It's not trying to out-cool Haskell and Rust on online message boards. But I would never in a million years evangelize either of those two languages for routine REST API work in most real-world shops, whereas I could suggest Golang without losing professional credibility.

[avgcorrection]

It’s funny to emphasize the vibes of a language contra other ones when you’re supposed to be on the supposedly pragmatic side. Haskell and Rust are popular on “message boards”? Better not mention them among my peers and risk my blue collar street cred.

But it’s a red herring in any case since enum types are such a basic programming language feature. No need to evoke the Cool Kids languages at all.

[tgv]

Completely true. And most of the time, I enjoy writing go. But the enums are weak. However, if the Go team wants to tackle an important addition to the language, it should be non-nillable pointers. No need for Option sum types, just a type annotation that says it cannot be nil (but can be assigned a nil type if you've tested it for not being nil). I've thought about building a linter (like the Uber one), but the way the types in the syntax tree are resolved makes it too complex for a small project.

[pkulak]

> Golang is an absolutely ideal language for writing REST API microservices

Those are strong words for a language with all the flaws I just mentioned. :D Yes, green threads are great for network programming, but it's not the only language with them, and one feature does not make it "ideal". If I had to pick the best networking language... I'd probably say Elixir.

But even if we agree that it's ideal, it doesn't change my point.

[smw]

I find go distasteful, but are there really many other languages with an m:n threading model? Only other popular one I can think of is Erlang/Elixir.

[pkulak]

Java 21, and I assume like every scripting language (Ruby, Python, etc). Though I guess with scripting you can't use more than one OS thread (not totally sure). Rust started off with it, and C# tried it too, but there are huge downsides to the model, so it's not like it's perfection incarnate and every other language just can't pull it off.

[smw]

Does 21 actually automatically schedule fibers? to open cores?

[pkulak]

Yup. It's all 100% automatic. Just use a different name for the thread pool and you're done, I believe.

[Thaxll]

Elixir performance is pretty average and it's not a statically typed language, things will blow up at runtime.

[neonsunset]

The better language at this to both Java, Go and, god forbid, Elixir is C#. It properly implements generics, pattern matching and task-based asynchronous model which allows to trivially interleave or dispatch all kinds of method calls in ways which require extremely verbose and bulky code in Go.

[gregors]

completely agree Elixir is a much better language all around for this type of work