Yes, it absolutely is. The few times I did work with Elixir I came across a few instances where I had to use libraries that had not been ported over to Elixir yet so I had to deal with Erlang. It wasn't fun. That being said, I think it's only one of the issues affecting Elixir adoption. Elixir, while undoubtedly a great language, is not very easy to use. The docs have a huge focus on the language and its syntax, but…
Ask HN: Is Erlang an albatross to Elixir adoption?
21–30 of 109 posts
Re: Ask HN: Is Erlang an albatross to Elixir adoption?
#22IMHO, the low raw performance of Erlang is what's holding it back from mass adoption.
(Even marquee Erlang/Elixir users like Discord, still have to use Rust NIFs to overcome the slow Erlang runtime)
People have a hard time understanding how Erlang can have such: high concurrency, low latency & tight standard deviations ... when people are just accustom to looking at raw performance benchmarks (where Erlang does quite poorly).
While BeamASM (JIT) is very exciting, the reality is that the Erlang runtime has only speed up by ~25% over the last decade, where other languages like JS, Go, PHP have seen >150% speed ups (and Erlang was already considerably slower than these languages prior to their speed ups).
Re: Ask HN: Is Erlang an albatross to Elixir adoption?
#23> What about people who've tried elixir and moved on? I've tried it three times and it offered me nothing Erlang didn't. Erlang, on the other hand, offers me much that Elixir does not. In truth, I've never met anyone who likes Elixir except people who were already Ruby programmers. What's particularly weird is your attempt to dig at the Erlang docs. They're extracted the exact same way the Elixir ones are; it's just…
Elixir was a gateway to Erlang for me. I hadn't heard of Erlang before I started writing in Elixir, but all the discussion of why Elixir was so great revolved around Erlang and the BEAM. This lead me to Joe's distributed systems thesis and really changed how I approach writing code. The syntax takes a bit of getting used to, but I generally prefer the language. I haven't found anything that's a nice to work with for…
Edit: After reading the first bit of that I'm pretty confident that is was GP was referring to. It's a really good paper and worth reading to understand why Erlang/Elixir do many of the things they do.
Re: Ask HN: Is Erlang an albatross to Elixir adoption?
#24FWIW, I've been using Elixir in production since 2016 and haven't found I've needed to learn any erlang. For context, we use Elixir for our backend and serve around ~100/rps over websockets. We've integrated Elixir into Stripe, Segment, Google, and Xero and haven't found we've needed Erlang libraries for any of those integrations or any of the other parts of our code base. > Elixir when they invariably stumble across…
Re: Ask HN: Is Erlang an albatross to Elixir adoption?
#25I feel like this is an issue with all superset languages or however you want to call them and should be taken into account by anyone learning one of these. You can't really learn Elixir without also learning _some_ Erlang, you can't really learn TypeScript without learning some Javascript, you can't really learn Clojure without picking up some Java. The platform/base language is abstracted away to some extent but not…
I'd argue that you end up learning a good bit about OTP, Erlang's standard library, and some stuff about the VM but very little Erlang in practice. Although if you know about BEAM, and some of the standard library there isn't much "Erlang" to learn after that. It doesn't seem to leak into Elixir the way Java does in Clojure, and the surface area of Erlang is smaller than Java anyway.
Re: Ask HN: Is Erlang an albatross to Elixir adoption?
#26Re: Ask HN: Is Erlang an albatross to Elixir adoption?
#27Re: Ask HN: Is Erlang an albatross to Elixir adoption?
#28If you are building a Phoenix web app, you can go many years and never run into non-trivial/non-obvious Erlang (excepting perhaps a small thing here or there, although many of those have Elixir wrappers now). I've also heard similar regarding Nerves apps.
On the other hand if you're writing a non-trivial CLI or app that doesn't use any sort of "framework" and you have to dig into OTP more than just the standard well-documented-in-elixir functions, then you will most likely run into the problem described in the question.
I don't think it's "an albatross" but it's certainly not ideal. Now that real apps/companies are using Elixir and it's not just the hobbiest/early adopters, it's an important question to ask and I'm glad to see it!
I wonder how much we can solve this by improving the Elixir docs. If we better document the areas where people end up digging into Erlang, it seems like it would help. I'm hesitant to accept the "to be a Sr Elixir dev you might just need to learn a little Erlang" but that's also worth considering.
Re: Ask HN: Is Erlang an albatross to Elixir adoption?
#29> I don't know what a solution is, but perhaps a concerted effort to create a documentation and library ecosystem that never links back to Erlang would help. And where there are critical systems that use an Erlang library, perhaps rebuilding it in Elixir is in order?
This would not be helpful. Erlang has over three decades of features, heritage, and libraries. Elixir helped usher in first class documentation as a core language feature, but that doesn't make rock solid Erlang libraries somehow things that should be avoided. Rewriting for rewriting sake is also not a good idea. One of the benefits of bootstrapping off an already amazing platform is exactly because you don't have to invent the universe. See Clojure and Java.
In fact, Elixir has helped Erlang up its documentation game, and there is already work done to help the ecosystems share documentation tools. Both ecosystems work by rising together, not masking one or the other. We see this in tools like `telemetry`, documentation generators, and recently the Erlang Ecosystem Foundation: https://erlef.org
Re: Ask HN: Is Erlang an albatross to Elixir adoption?
#30Raw performance is the actual albatross. IMHO, the low raw performance of Erlang is what's holding it back from mass adoption. (Even marquee Erlang/Elixir users like Discord, still have to use Rust NIFs to overcome the slow Erlang runtime) People have a hard time understanding how Erlang can have such: high concurrency, low latency & tight standard deviations ... when people are just accustom to looking at raw perfor…
The biggest issue from what I know about how Erlang works internally is not so much the fact that Erlang could not in principle be made fast (and indeed, BeamASM will if it makes it to mainstream become a good step in the right direction), but that the whole way in which Erlang schedules its threads is super ineffecient in terms of cache use and besides the byte code interpreter relies on its ability to keep track of the number of reductions that it has done to determine when a thread has had enough cycles and we need to move on.
This means there will always be a fairly hard upper limit as to how far you can optimize Erlang byte code, it is at its core a cooperative multi tasking operating system inside a user process.
One of the more elegant ways to do such interop is to isolate your number crunching code to a separate process group working their way through a queue one unit of work at the time that way you can use all of the Erlang goodies and still get very good performance.