I think the blog post is guilty of the same thing we're all sometimes guilty of when discussing something we like, but few other people seem to appreciate. It's this "no, it's great, you just don't understand it" mentality. We get it, they don't, and if we explain the genius of it one more time, the world is going to see the light.
Erlang has been around for a looong time (it's about as old as C++). It never rose to any real prominence, nor has it dominated any well-defined niche. Sometimes, outcomes like that are just a matter of bad timing. But sometimes, people just try your thing, don't like it, and the best response isn't "actually, you just don't get it" - it's to learn and iterate.
Then later, I found myself doing things in other languages … and I realized what I was trying was significantly less effort in Erlang and I was poorly reinventing ideas from OTP. That was when I pivoted my career to seek out teams that work with Elixir.
Some years later, when I finally got around to learning and using Node.js, I realized just how poor the async/await/promise design Node.js was (error-prone by design). But I highly doubt I would convince anyone to really give Elixir or Erlang a go.
In my case, it was certainly a case of "it's great but I just didn't understand it".
> Some years later, when I finally got around to learning and using Node.js, I realized just how poor the async/await/promise design Node.js was (error-prone by design). But I highly doubt I would convince anyone to really give Elixir or Erlang a go.
IIRC Elixir got a pretty big boost early on thanks to folks making the jump from Rails to Phoenix, so it could kinda be the case that most of the folks who *would* give it a shot *have already* given it a shot.
That being said, I have the impression that you'd have more success with folks using Node.js than you might think. I expect there would be more pushback from folks using, say, Golang and Java... if only because the wider dev community doesn't look down its collective nose at those languages quite so much. (Unless you're talking about generics or null values, respectively!)
I have tried with people using Nodejs. I didn’t really get much anywhere.
The wall I run into starts with, “what do you think of Typescript?”
I don’t try very hard though. At most, I put out feelers and see where it goes, because it is impractical for my team to switch to Nodejs. Due to the nature of the work, Python is a better choice for the team even if I think Elixir can still work better for me.
Golang/Java/C++/Javascript developer here. We do look down our collective nose.
I've tried to get into Erlang and I'm a big fan of Joe Armstrong.
Erlang incorporates great ideas, but using it for a project seems a bit risky, since it is quite different from other mainstream languages.
Go is more conservative, but less risky. It's just a C for today's world. I've had lots of success using it, even though I'm aware of its warts (especially when it comes to concurrency).
That said, I'm kind of excited about Gleam. Let's see how that works out.
> I realized just how poor the async/await/promise design Node.js was (error-prone by design)
It's so weird to me when people make statements like this and it makes me wonder how many times I've been swayed by someone's opinion online who doesn't understand the fundamentals of what they're talking about (or they do, and they just have horrible taste).
Node.js's asynchronicity is quite literally one of the, if not the, best part of Node.js.
“Node.js’s asynchronicity is quite literally one of the, if not the best part of Node.js”
That’s fine if that is your opinion. Here is my perspective on it:
- Node.js async model is not unique nor innovative. There has been several other platforms (such as Tcl/TK or 90s Windows programming). It runs into the same problem with any cooperative concurrency control, where a block of execution can freeze out everything else. In contrast, the Erlang/Elixir has a preemptive scheduler
- Nodejs’s async/await has an implicit queue of execution blocks. Erlang/Elixir, on the other hand, queues _messages_ recieved by a process. This allows not only transmission of data, but also control signals (such as suspend, stop, restart), which you cannot do with Nodejs promises alone. You have to use event emitters, whereas every Erlang/Elixir lightweight process can receive event messages.
- Nodejs promises can get lost. If it is not held and tracked somewhere, you can’t get to it. Erlang and Elixir has a first-class, PID literal. You can pull up any running process because the scheduler tracks them, which makes live debugging or mitigations possible in prod
- Because Nodejs queues execution instead of messages, it has to use callbacks. The problem with callbacks are not necessarily callback hell so much as tracking rejections and errors. Every single async call requires it, whereas in Erlang and Elixir, a running process is a natural error isolation boundary.
- Nodejs only occupies a single core of a processor, unless you use workers or fork. The BEAM runtime (these days) will use up as many of the cores as available unless you tell it not to. I can run a single BEAM os process, but have to jump extra hoops to take advantage of that for Nodejs.
Those are the main reasons why, from my perspective, Nodejs is error prone by design.
I'm surprised you think it's emotional. Seems pretty rational to me. I thought Node.js's selling point is the event loop and its non-blocking nature, and how convenient it is to be able to write both your backend and frontend code in a shared runtime. The arguments against that paradigm, mostly around callback hell and promise chaining, have gone away with async/await. So I stand by my assessment that these parts are probably the best parts of Node.js.
There are many other parts of Node.js which need work, but it's weird when the thing to call out is its asynchronicity when that part of the language is usually the thing people like.
In my experience, lots of stuff needs to scale massively, but (outside of the better tech companies I guess?) mainstream tools/stacks/approaches are hangovers from n-tier arch days and not really right for it, so the majority of distributed systems are tyre fires.
Ironically I think the original Facebook messaging did something similar, but they changed tech due to their inability to hire developers competent in the language.
> But sometimes, people just try your thing, don't like it, and the best response isn't "actually, you just don't get it" - it's to learn and iterate.
Elixir is Erlang with more sugar coating. The language and many of its associated projects (e.g. Phoenix) are regularly touted as some of the most productive development tools. You still don't see people flock toward them.
I used to think that large groups of people can't be wrong. Time and personal experience taught me otherwise. Now I know that sometimes it's possible that they actually just don't get it. But that's also fine.
Erlang wasn't opened sourced or released to the public until 1998.
The problem with not using Erlang and Elixir is that people are continually inventing a worse wheel. If you need a scalable system controlling many things robustly and reliably, anything built to solve that problem will be an approximation of the solution provided by Erlang/Elixir.
It’s popular enough; Simply making something massively popular rarely makes it better.
I think functional programming in general still has a lot to teach most programmers that are writing code in the most popular languages today. That doesn’t mean I think they should be using different languages primarily. It means I think they should make their own environments better by learning what others have figured out before them.
No. In fact, Erlang was open-sourced because Ericsson gave up on it. From wikipedia:
> In February 1998, Ericsson Radio Systems banned the in-house use of Erlang for new products, citing a preference for non-proprietary languages. The ban caused Armstrong and others to make plans to leave Ericsson. In March 1998 Ericsson announced the AXD301 switch, containing over a million lines of Erlang and reported to achieve a high availability of nine "9"s. In December 1998, the implementation of Erlang was open-sourced and most of the Erlang team resigned to form a new company Bluetail AB. Ericsson eventually relaxed the ban and re-hired Armstrong in 2004.
I know this seems like a black mark on Erlang. I think it just demonstrates the difficulty of carving a new niche. Training developers in a new language and paradigm is hard.
Or someone could read it as the Ericsson management not really understanding the capabilities of their own internal tools, and must've read something up on Java or .NET in an HBR article.
Not really - at least in my days in that industry, the bulk of telco equipment was running C/C++ or Java code. This included Ericsson gear. Ericsson and one or two other telco companies were definitely using it in production, but it wasn't dominant.
> But sometimes, people just try your thing, don't like it
People don't just try things. And they judge things they havent tried. They stick with what they know. They all got taught java in school, so thats what they use.
Erlang has been around for a looong time (it's about as old as C++). It never rose to any real prominence, nor has it dominated any well-defined niche. Sometimes, outcomes like that are just a matter of bad timing. But sometimes, people just try your thing, don't like it, and the best response isn't "actually, you just don't get it" - it's to learn and iterate.