Is Erlang an albatross to Elixir adoption?

As the creator of Phoenix, I've never written an Erlang program fwiw. That said, I frequent the Erlang docs and most seasoned Elixir developers will do the same because the standard library is a wealth of features, and the documentation while not 2022 polished, remains a remarkable resource.

> 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

I 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 completely.

It's especially visible when trying to use libraries used in the platform language.

FWIW, 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 the things in erlang — libraries and the like. I'd hoped I could avoid it myself, but it's too interdependent.

This hasn't been true in my experience. I'd be curious to hear which Erlang libraries the OP has been using.

Raw 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 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).

> "cool, learn python, but oh, you also should brush up on cobol while you are at it, you know." It's just bizarre.

It's more like learning python and also c. Depending on the library, python can smell a lot like the c underneath.

Sometimes you'd never know a python library is written in c, sometimes it's a manageable leak like the socket module, and sometimes it's opencv. Write enough python and you'll find C library wrappers so atrocious and/or badly documented that you just whip out ctypes and hack out a replacement wrapper yourself.

The reason you're hearing the answer you preemptively dismissed in the OP is that the distance between erlang and elixer is thin, much smaller than python and c. That's sorta the bed that elixir made itself.

If people believe elixir is held back by erlang, and that elixir should do it's best to hide erlang, then the the albatross is probably elixir around erlang's neck. Mindshare and time spent contributing (e.g. to documentation) should be further split between two very similar ecosystems? For what? Because it doesn't look enough like Ruby?

I've used Erlang and have been interested in Elixir but haven't used it. After a little getting used to, I've generally liked the Erlang docs. I have the impression that Elixir is just Erlang with different surface syntax so the main real differences are in the library culture (Elixir's are more Ruby-inspired, with Rails's inanities mostly cleaned up). From a Lisp background, all these languages are pretty much the same. Erlang/Elixir's concurrency story is far better than say Python's, but that's not really about the language per se.

I'd actually like a statically typed BEAM language. A few of these have been attempted, but I don't think any have gotten traction.

> 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 a different CSS theme.

C'mon, dude. This is very much a "coffeescript is held back by javascript" post. Yes, we know, Kotlin is really burnt by its Java roots, etc, etc.

The base language always lives. The descended language rarely does.

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 don't really hold the hand of developers of imperative languages who want to understand the paradigm of functional programming.

It took me an obscenely long amount of time for me to understand how a GenServer works, and how the entrypoints for an application work. This is a big pain point with learning Elixir and every time I come back to it I have to do this big mental overhead that IMO just isn't productive.

Chiming in with 6 years of professional Erlang experience. I'm somewhat familiar with Elixir, having worked on some Elixir codebases for a few months.

> The notion that to learn a language you also need to learn a second one is not great. [...] It's just bizarre.

I disagree. I don't think it's bizarre. I expect to sometimes have to poke around in C code when writing Erlang or Python. It's also fairly common for C/C++ developers to look at the assembly output of some piece of code using https://godbolt.org/.

> Reading the code is NOT an answer.

Again, I disagree, and I think this perspective is harmful to career development. Knowing how things work on a deep(er) level is a superpower. When you're writing Elixir, do you never open up a .ex file in the standard library to see how something is implemented? Are you not at all interested in what powers things like Phoenix.PubSub?

> 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.

I suspect that a library ecosystem that doesn't require Erlang would be a huge effort to implement and test, and would wind up pulling in all of the ideas from Erlang that you haven't learned/mastered yet. A better alternative would be to accept the fact that Elixir builds on top of Erlang, and understand that a deeper knowledge of Erlang is going to help you improve as an Elixir developer.

> And where there are critical systems that use an Erlang library, perhaps rebuilding it in Elixir is in order?

I'm definitely biased, but I would be much less trusting of an Elixir copy of a 'critical' Erlang library. Many of the selling points of Elixir that lead to very concise code (read: macros, 'using', and others) are things that make it difficult for me to develop a deep understanding of a library. It's cool to use DSLs like Ecto and Plug, but I have a much harder time understanding those libraries as a result. Erlang's unambiguous syntax and its basic text-substitution-based macro system are much easier for me to understand, and while it takes more effort to write APIs and code that are as concise as what's available in Elixir, I know that I can open up an Erlang file and trust that much less is hidden from me.

I think we are just more used to Elixir docs.

The few times I've had to jump into Erlang docs, in truth, it has not been much of a problem. My main problems have always been the differences in string/binaries types between Erlang and Elixir.

It's the same way that the Java/JVM prevents Clojure being picked up more. To figure out Clojure's errors you need to be familiar with Java/JVM (most of time).

Elm is a great example of a language that doesn't suffer from being written in Haskell, you basically completely unaware of it and not required to dip your toes into Haskell's ecosystem.

The phenomenon you're talking about, imo, doesn't have anything to do with Erlang or Elixir.

All languages have limits to what you can do natively. There will always be some tasks where you will cross a language barrier from "your" language to another. To me, the question is: "Is the area that Elixir covers big enough to recommend?" and I think the answer is yes.

I do not think most programmers need to learn Erlang to use Elixir - but I think programmers will often encounter Erlang and can decide to learn it (or look for a different library that's pure Elixir). I am sure that there are individual programmers who would learn pure Elixir, but get 'scared away' by Erlang...but I doubt they are hurting the language ecosystem in a meaningful way. Focusing on this would both be optimizing something that does not, in general, matter - and would be trying to achieve an impossible goal.

I work in a company along with dozens of Elixir engineers. It's pretty rare that anybody needs to read/write any Erlang code. It's a bit rare that anybody has to read Erlang documentation. And when that happens, it isn't a burden.

> "Erlang is easy, it's just semantics that are different"

The opposite: syntax's different, similar semantics.

I've used Elixir in production since 2016 and I have only had to deeply introspect erlang code exactly once, when I had to implement OIDC using Ueberauth and it used the underlying oidcc erlang library (which was extremely cryptic and wasted days of my life with absolutely useless error messages).

And then I remembered why erlang never picked up. It was a huge pain in the butt to try to read the erlang. Didn't like it at all.

Apart from that, we've done tons and tons of work in elixir and never had to touch Erlang, and for that I'm eternally grateful.

This is why I've always just settled for the 'root' language and try to stay away from derivatives even if those offer a lot of goodies the 'root' does not offer. So no Typescript, Clojure or Elixir for me. I also think that the main attraction of an eco system is how long term stable it is and usually the second layer is less long term stable than the foundation.

And usually such a 'derivative' language only serves to fragment the eco system (community, contributions) of the 'root', not to enhance it.

I think it's important to differentiate between groups, because it is definitely possible (and normal) in some situations not to ever need to understand Erlang or know anything about it.

If 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.

The analogy ~"learning python but also cobol" is not quite correct. It's more "learning kotlin but you also have to learn a bit of java".

I want to point something out from an information tgeoretic point of view.

Can you say you know what is going on if you don't read the implementation code? I'm even fine with extending that to executable code.

You must read code. Code use sans understanding is dangerous. You can do immense harm without even realizing you're doing it. Look at Log4Shell, or MCAS.

The majority of your time as a computing professional should be spent reading code you'll be using. Abstraction is nice. Until it isn't.

I'll never understand the I shouldn't have to read code school of thinking. It's like saying you should never have to learn arithmetic.

Now there's a case to be made that in development communities that value convention, yes, you can get to a point you don't have to read as much code in that community, given everyone plays by the rules.

Colors.js or node-ipc is what happens when they don't. So even then, don't read at your own peril.

Tackling a new language over BEAM and integrating with Erlang is as big as Clojure with JVM - The thing is that Elixir used to be more erlang-y than it is now and does a decent job hiding the hardcore functional/process comm/OTP plumbing. I don't see our team writing too much Erlang but we know that a full distributed Elixir production setup will incur the same operational load as in Erlang. W.r.t documentation, I found Francesco Cesare book (and the original Erlang programming book by Joe Armstrong) pretty good to help where the doc was too terse. Maybe you are looking for documentation on frameworks ? My main block was to be used to read http or database framework docs and jump straight into functional programming and pure language documentation... just an idea.

Elixir has a reputation for being relatively complicated and this (having to understand Erlang when developing in Elixir) is one of the reasons. Many CTO's don't want to touch it due to extra complexity, lack of devs etc etc. If concurrency is that important (it usually isn't but lets say it is) they can go with k8s - Node, Go etc (it doesn't really matter - k8s will quite easily scale just about any stack). There are just many easier paths of less resistance than Elixir in most cases.

Also - Elixir is functional or close to functional so it is quite a big mind shift so another hurdle to onboard newcomers.

Anyway, trying to increase a language's adoption is very very hard..

I've built quite a lot with Elixir at this point, and I love it, and I haven't written any erlang at all (other than maybe a couple of very simple function calls). I don't think this is a real problem, except for those building very complex applications.

Perhaps.

My parallel example would be the Play Framework. Play 1.x was written in Java, but supported both Java and Scala, and was fantastic, easy to use and one of the most productive and performant full-stack framework for web development.

Then, they created Play 2.x, where the core was written in Scala and if I remember correctly even used Scala for its HTML template. Even though it supported Java, and obviously Scala, there was a definite drop in its usage and I believe it majorly impacted its adoption.

Personally I think if they'd stayed with the Play 1.x model, it would have been extremely successful.

I learned Elixir early on, and then had other tasks and languages I needed to devote my time to. So I haven't kept up with it. I remember though that learning Erlang first well (including how BEAM worked) was a huge help to me in learning Elixir. It lets you understand what is going on under the hood. That said, I've used the analogy of Elixir is to Erlang the way Java is to JVM byte code. That means you can master Elixir without ever coding Erlang, but I think you'll have a harder time of it.

This is just a result of your own context and background. If you were an Erlang developer then Elixir would come naturally. If you started to learn Python as an Erlang developer and had to understand its C implementation details (via SciPy etc, which operations are implemented in Python or natively) you would make this same post in reverse. But you're taking that for granted because you are already coming from that position.

Been using Elixir since 2016 and I don't know anything about Erlang beyond "it uses BEAM". You don't need Erlang to use Elixir.

> The notion that to learn a language you also need to learn a second one is not great

It depends on how far you're trying to go maybe? You could argue that, for any given programming language, there is always a point where you will have to learn some intermediate representation language to achieve certain tasks; I personally don't think this is unique to Elixir.

You are right. However I believe that, after some time, beginner Elixir developers become intermediate Elixir developers and they get to used to having a little bit of Erlang here and there.

I love Erlang. Elixir seems to go away from the philosophy of Erlang, and they are pushy about it, they try to make Erlang worse in that regard. Leave Erlang alone, and stick to Elixir, please.

I must say that having to learn Erlang killed my desire to learn gleam. I just wanted to explore a functional language and having to do 2 at once wasn't worth it. I chose f# in the end.

Absolutely not!

Elixir is to Erlang AS C++ is to C; you cannot understand the former without understanding the latter.

My N00b take on Elixir in general (were N00B = Have my first app, an MQTT/API bridge written and deployed running on Ubuntu employing Bandit, Finch, Tortoise, OpenAPISpex, and Jason).

The immediate answer would be no. I would say 5%-15% of my questions asked on the Slack channel have ended up in Erlang land. The first time someone answered with "you want :binary.bin_to_list()", I was completely confused. "What is :binary?" It took me a minute for the lightbulbs to say "remember, you read Erlang syntax is upside down from Elixir and maybe that'a an Erlang thing?" The erlang docs are not bad, but they are structured and navigated very differently than the Elixir ones. And the notation differs. It can look almost like BNF some times.

I find it inconvenient and annoying that this is so, but never felt like it was an albatross. It's a weird split, because many common things ARE in both systems. But then, some things don't make the cut. And experienced people just "know". Hopefully, you're around one of those people either directly or virtually. I've asked why not just transcode the entire erlang library over. If the languages are nearly associative, just make a process that (mostly) automates a conversion. I asked about this in the Slack channel, but the sentiment seemed to be "decent idea, but not worth the work."

I wish I had opportunity to do more Elixir/Erlang. I have a goal to see if I can't learn some LiveView stuff. In my short journey I've worked up my list of "love this/wish this were better." This issue would be a cool thing to improve, but it wouldn't make my top 10.

My loves?

* I love the straightforward simplicity of the language, it reminds me of Smalltalk that way

* I really like pattern matching, and recursion. I realized how much time I spend in other languages writing code that describes where the code goes next. Pattern matching and recursion I really like

* The Slack community is great. Better than just about any other "open source" community I've gotten help from in the past few years.

* The key players (José, Chris, etc) are accessible and really nice guys. Submitting a documentation clarification PR was super nice because of José.

* I love piping. I'm told newbies overdo this. I'm still loving overdoing it. I wish the syntax were a little less difficult to type; I should figure out how to do some hotkey thing I guess.

* Binary. Wow. Parsing binary data streams in Elixir just rocks.

* I like OTP more and more; often the community seems at odds with it. It's not "purely functional". This may be the area the author was originally barking at.

Things that disappoint me (so far, but I am open/hopeful to coming round in some cases):

* VSCode is OK. But a language like this really wants a decent IDE. I want to work on functions, not files.

* I love/hate the formatter. I love that there is one and I get consistency. But it's not associative. A formatter should format my code, not just kind of format it. If it made a 3 lines out of one of my long lines, but then I shorten the code, so that it can now fit on one line, it should do that. It can't because it doesn't know the difference between extra new lines I put in and one's it added. The reality is, I want it to format the whole file, not just the horizontal space. The fact that newlines are part of the syntax in some cases makes this even more of a problem. IMO syntax either own newlines completely (python) or leave it as a presentation character and design the syntax so the whole program could go on one line if it needed to.

* To date, I have found the defstruct story unfulfilling. The syntax is a bit weighty to type %SomeStruct{foo: 1, bar: 13} requires me to do a lot of slow reaching shifts and it always feels like it slows me down. One defstruct per module hasn't scaled well for me. When I switch back to Python/Kotlin/Swift, the struct/dataclass just works better for "modelling" up data.

* "Namespaces are a honking good idea - we should do more of them!" Elixir looks like it has namespaces with Dotted.Module.Names. But only barely. In fact, since there are edge cases where nesting modules creates issues, I took to never nesting them, even when using Similiar.Dotted.Prefixes to "group" them. Eventually, you realize you could just use _ or pretty much any separator. The dot's have very little value. I wish the namespace story was more like Python's (but not the shadow binding nonsense).

* Macros are awesome. BUT, sometimes it can get really confusing what's going on. I don't love the quote/unquote thing. What I have sorely missed with some macro heavy libraries is the ability in the IDE to see what the code turns into. Kind of like running just the C Preprocessor on macro heavy C code to see what's really going on.

* I do not love do/end. We have punctuating characters in romanized languages for a reason. They structure and organize the words and phrases we use inside of them. When we use alphabetic words to do this, the brain has to parse more to separate the structuring elements from the content.

* I think I've come to appreciate the "batteries included" language approach more. There's a balance of course. Python has some stuff in it that just seems silly to be in the base library. But a lot of things is just there ready to be used. In Elixir, I'm left guessing what extra modules to use. It's hard to know what's being actively supported. And discovery is yuck. I wish for more ItDoesThis boring names rather than cute/clever plays on words for package names. For example, would the lay reader be able to guess what my Bandit, Tortoise, and Finch modules actually do?

https://en.m.wikipedia.org/wiki/Betteridge's_law_of_headline...