The article concludes: "If concurrency is central to your application, Go is the language to use."

If we as a profession are to "get past the tribalism and boosterism and have rational technical discussions", surely other languages/technicques like Pony, Haskell, Clojure, Kotlin, Scala/Java combined Akka etc. should be considered and discussed? The article reaches its conclusion much to easily.

With regards to expressiveness: Go is a lower level language and has fewer language constructs and abstractions than most other modern languages. This is by design, and many seem to appreciate that simplicity. I was simply stating a fact when I said Elixir was more expressive and did not intend to offend anyone. I seem to have done so regardless.

Implementing a 3D vector or quaternion library in Go feels like a really bad fit, mainly due to the lack of operator overloading (which can easily be abused, like >> in C++). But it is an example of a field where Go allows programmer to express their ideas in a less direct way.

I think Go is great, but I don't think describing parts of it as less expressive than some other languages is banal.

Expressiveness has a sweet spot, though. Too many keywords and constructs makes a language harder to learn, and makes it too easy for developers to build their own little weird worlds that discourages team work and lowers readability.

That exists, so we can look at at least one concrete attempt to evaluate the question. [https://github.com/go-gl/mathgl].

And right off the bat, the first thing a person notices is that there are two identical sub-libraries, mgl32 and mgl64, to work around the language's constraint that the core numeric type in the library cannot be parameterized at the language level without performance-losing reflection.

mgl64 is generated from mgl32 though [0], so no big deal, no? Who's hurt by this?

[0] https://github.com/go-gl/mathgl#contributing

Well, let me just do a quick text-based search for the Vec3 implementation and...

... oh. There's three. The one in mgl64, the one in mgl32, and the canonical one that a developer should edit to make changes. And they only all stay synchronized if the developer remembers to follow the contributor practice and run that gen script, which is not enforced by anything.

On a small project like this, not a big deal. But it's indicative of the over-arching problem of the approach go is necessitating here. There's noise here that a developer has to think around, and as a project scales up, that noise is going to become louder and trend towards intractable complexity.

Libraries are considerably better than Golang and more all encompassing because you have 20 years of Erlang libraries that you can just use.

Deployment is getting better and you can just great a release in a docker image and deploy that like you would anything else. Obviously it's no way near as small (or simple) as FROM scratch is with Golang binaries.

Tooling is fantastic in some ways and poor in others - for example you can get an interactive IEx terminal running onto your Elixir cluster to debug issues, although I'm not sure about the other parts. Dependancy management is fantastic and something Golang struggles with. Not sure about other tools for Golang though!

The final thing I'd say is once you have a runtime that has Supervision and restarting of processes you never want to go back to worrying about what to do in the cases you haven't considered.

"Libraries are considerably better than Golang and more all encompassing because you have 20 years of Erlang libraries that you can just use."

I'm wouldn't be sure of that anymore. For instance, Go has an official AWS SDK but Erlang does not. Go's been around for 8 years now and it is almost certainly significantly more popular than Erlang. It's been a while since I reached for a library for Go and couldn't find anything at all. (Though I have recently been in the "three libraries that all seem like 80% of the job is done with varying degrees of quality" situation. But you still get that in Erlang in similar places too, as far as I know.)

It's the whole importing packages is just a checkout from master that makes me concerned about package stability. Semver exists for a reason. I realise this is nearly fixed but it's very slow in coming.

To be honest I feel you really will struggle in Golang to make software that is as reliable as Erlang/Elixir simply because the language is immutable and allows for concurrency by using many serial processes (Actor model) and has supervision of processes (let it crash) and also worth noting once you have used compile time macros the way Elixir does it you never want to go back to repeating yourself the way Golang forces you to. In fact I should write up my proposal for macros being added to Golang as an alternative to Generics...

If you are building something like Docker I'd argue Golang is maybe a more suitable choice but for Web software and stable concurrency Elixir is miles ahead.

Deployment: super easy, highly maintained and ready tool that output fully instrumented and tooled tarball with start, stop and remote console script. Even come with configuration solved. Neex no dependencies outside of possible dynamically linked C one like openssl if you use it

Build: same, come fully ready out of the box.

Library: there is everything and you can use any erlang library for free. 35 years of production experience.

Tooling: see above. Everything to debug and instrument on the fly. Dynamic tracing for everything for free. Logger. Etc etc. Fully interoperable runtime dynamically for free. Advantage of using a runtime that has spent 35 years optimising for reliability in production.

So yeah. We could but then people would not understand. Erlang/Elixir have a decade of advance over Go for that kind of tooling and production-readiness