Ask HN: Is Erlang an albatross to Elixir adoption?

Genuinly curious. Like what?

I felt the same way as topic starter, and I invested couple months to make several tools Elixir-native -- the project was cancelled with the layoff.

I think, this is a compromise. I strongly dislike Erlang abstraction leak, but I understand the desire to deliver the language, and iterate on cleaning up toolchain & libraries later.

I am one who came not from Ruby, btw. My roots come from a variety of things including Smalltalk, C, C++, Perl (dare I admit), Java, Javascript and Python, among those most influential on my life (and in that order).

I'm really happy w/Elixir, finally getting back to a better true object oriented system (for those who know the roots of such).

Also, I'm not a Ruby developer but still found Elixir to be nicer than Erlang in small but important ways. The documentation part does hold true IMO, as the official Elixir docs are fantastic, which goes beyond just a different CSS theme.

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 web app development in Erlang, though; I do think the tooling around Phoenix is nicely polished.

This was the purpose of the language (or if not an explicit purpose, the primary effect.) Elixir created an environment that attracted Rails people (and other people repulsed by languages that don't look like C/Algol), and behind the Rails people (Rails been long established as a safe choice but aging and scaling badly) comes management of safe companies and consultancies, and with that comes a sure way of making a living for people who love Erlang and are willing to play the Elixir game.

Elixir is the same as Erlang, except with bad syntax and loaded with various ways to make your programs indecipherable, and with a cleaned up standard library and lots of nice little affordances/templates to help with processes and OTP. While Elixir (in my experience) takes a lot more debugging due to the weird javascripty syntax and pseudo-mutable variables, it's the same thing in my book (and the error messages are great.)

Happy to do the one that provides the most work, and thankful that they created it.

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.

Coming from Ruby/Go/JS to Clojure was definitely harder than I expected but rather than fighting "this stupid JVM" it made more sense to buy into the idea of how Clojure is built and used.

Why do these libraries need to be ported to Elixir at all?

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.

Yes... because perf hasn't really been a focus for Erlang until about 1.5 years ago. Various (usually academic) third parties have contributed big performance-enhancing patchsets (the earlier JIT; Dialyzer and then HiPE based on Dialyzer analysis; etc.) but these have then languished, with attempts to further development on them slowing to a crawl over time. The patchsets were just "too big to be digested properly"† by a team of core maintainers who 1. didn't write the code, and don't fully understand it, and 2. who aren't CS academics themselves.

Each of these indigestible patchsets was eventually dropped, throwing away any follow-on in-tree work done to it, and dropping perf back to where it was before said patchset was introduced.

The new work is in-tree, done ground-up by the core maintainers themselves, and so is actually showing linear improvements in speed. This not only includes runtime speed, but also the batteries-included addition of long-ignored performance-oriented features, like atomic counters and fast global readonly modules (and the runtime itself being gradually rewritten in terms of these!)

† This is exactly why, in the Linux kernel, big patchsets aren't accepted as-is, but rather are required to be broken down into small changes that 1. can add value on their own, and 2. can be molded to fit the design philosophy of the kernel on their own. This is why e.g. the "containers" patch from OpenVZ was never pulled in; but instead, each bit of it was gradually reworked into the cgroups + namespaces code that powers Linux containers today.

Then what is the albatross?

I think it is complexity. Erlang, and OTP, is not simple to understand. There are a lot of footguns. It is beautifully designed and fit for purpose, given it's history and heritage. However, the learning time for creating a real app in Erlang is high. To flip it around, I think the reason Ruby caught on so fast was that it was so easy to learn Rails and create a web app with it.

You could perhaps convert Elixir to be based on top of Rust, but there are many concepts that don't map, or don't map well.

When writing Elixir, yes, you'll be exposed to Erlang syntax/docs sooner or later. But you're not writing Erlang, so you never need to learn how to:

  - Compile more than a couple lines of Erlang into a function
  - Create an Erlang module/file
  - Learn Erlang's build tooling
  - Cold recall its syntax

I've been programming full-time in Elixir for a couple years. All told, I think I spent 3-5 hours one afternoon learning the basics of Erlang's syntax so I could better read the docs. Haven't had to think about it consciously since.

What would it take to programmatically port/transpile the core of Erlang's ecosystem to Elixir?

Pick the killer app to serve as the root node (Phoenix?) and walk back to the leaves (OTP, popular libraries, etc). Do a 1-time cutover of literally everything. Fork/port ERTS (incl BEAM) to make Elixir-native and rebrand it. Etc.

While I generally agree that "rewriting as bad" there is something to be said about the importance of _ease_ when bootstrapping and scaling an ecosystem. You're either stealing mindshare from an established ecosystem, or you're capturing new minds as they come in.

IMO Elixir/OTP is too radically different from other very-large ecosystems to benefit from transfer learning for junior/mid-level people (great similarity w/other smaller fringe ones, like Ruby, Clojure, etc, but that won't get us there), and the most senior people fall into the "it's all the same at the end of the day" trap and don't put in the energy absent some strong business driver. So you really need to reduce even the shallowest cognitive bumps to get escape velocity.

Does it cause friction for new devs? No - I can't think of any mainstream Elixir use cases that require Erlang libraries, with the exception of math operators like `:math.sqrt/1`. Chris' comment here is the golden example of this.

And anyway, what does the user get in exchange for that extra layer of complexity? A unique high-concurrency VM with easy-to-use primitives that would require huge gobs of code and lots of added dependencies in other languages.

It's a small tradeoff. My own experience is that the benefits far outweigh the complexity cost.

It sounds like OP mostly objects to the oldschool textfile documentation aesthetic of a lot of Erlang core and libraries, which is fine, but the overwhelming majority of new Elixir devs doing web applications and data processing will never encounter this.

I find the whole framing problematic. To call the foundation that you are building on and that you seek to displace an albatross is missing the option that it could easily be seen as being the other way around.