IMO that’s true everywhere. Not going Elixir fanboy mode here but everywhere I was, be it a wage programmer, or consultant, or hired-for-a-project role, and no matter the language and stack, everybody was focused on delivering the next sprint or, in the best case scenario, mid-version release (say, going from 1.1.5 to 1.2.0). Strategic investments in tech blessed by the business people are as rare as flying unicorns.

There are no places like the original labs where UNIX, Plan-9 and a lot of other tech we use to this day were conceived. Too much short-term capitalism for those to ever see the light of day again.

I respectfully both agree and disagree.

• Java doesn’t have robust solutions per se. And where it has good solutions they are very rarely out of the box and painless. The ecosystem has 500 metric tons of crap and are riding the horse named “look how many companies are using us, we have to be doing things right, we are sure!” – while in truth the slogan should be “everybody is too damn scared to move away from us because nobody has an idea how their systems work anymore”. Sorry for being a cynic but for 8 years in the Java space (2003 - 2011) I’ve never, ever, seen one Java team that legitimately knew what they were doing. And I’ve never seen a team actually being on top of all their business logic and code. Maybe only a bunch of very bright young people in SAP Bulgaria where I contracted once. And that was because the project wasn’t big.

• Java has a lot of useful libraries for hundreds of protocols and integrations with many 3rd party APIs, I am not denying that – and that’s its main selling point in the last 7-8 years and is what maintains its momentum. But in terms of distributed computing Java is, to this day, worse off than Erlang/OTP and is almost on par with Go. Their only chance is their new functional constructs and producing a zero-fuss deployment of those to something like the cloud serverless functions or short-term specialized containers. But they can’t do that yet because the JVM takes a long time to start (there is a lightweight distribution though, so they might get there). Ad infinitum.

• Go is not much better but I still like its community much more than Java’s. Go programmers seem to be a very particular bunch and they don’t mind getting their hands dirty. And most of them are very well aware of the pros and cons of the language and the runtime and they mostly stick to highly specialized libraries, CLI tools or microservices. Go’s community is a really excellent example of programmers who are realists. That being said, goroutines and channels are very far away from the robustness of the OTP. Deadlocks usually don’t happen but a subclass of the multicore problems still apply. This is well documented over the net; try googling about for “goroutines deadlock” or “go panics channels” or along those lines, you will find some quite disheartening articles… Gotta say, these discoveries shook my faith in the language’s multicore story.

I will agree that this community is small. But you must not underestimate the core team. Many things that have to be reinvented in every Erlang project are being gradually added to Elixir (Task.async_stream, GenStage and Flow being pretty good examples). Lately there was a huge thread with tons of discussion about how to solve the compile-time / runtime / app-startup-time configuration and a lot of progress has been made in terms of the core team gaining better understanding of the shape and the area of the problem.

The vibe I am getting from Jose and the others is that they are well-aware of the current pain points but are gradually creating the building blocks of the solutions. The Elixir core team is very judicious before adding stuff and many of us are applauding them for that. When they do it, it will be done right.

That being said, nobody forces you to wait. By all means, use ZooKeeper or a particular Kubernetes setup in the meantime; we all have paid jobs to do after all and we cannot wait indefinitely.

Last but not least, distributed computing is one of the most stubborn and complex problems in this computing age. It would be unfair to judge Elixir by its inability to provide transparently and out of the box functionality that 99% of all others cannot provide even with a bunch of tooling attached.

I will still encourage people to actually go out and build things. Waiting around and expecting the core team to solve all problems isn’t going to work . The main goal of the core team is to maintain elixir itself - nothing more, nothing less. The language is designed to be extensible and it’s up to the community to leverage that and build libraries for solving problems they face. Relying on a handful of people does not scale.

Am I the only person who feels disappointed over-all in the maturity of this space? From the way some people describe Erlang it seems like these kind of solutions are the entire raison d’être yet the actual state of it is fragmented and largely of dubious production value. If I want to build a large distributed application today in Elixir and the scale outstrip the capabilities of :global (maybe 30-40 nodes) I feel like I’m on my own and honestly would probably base it on Zookeeper or Consul and grpc rather than using a native beam solution.