Ask HN: Is Erlang an albatross to Elixir adoption?

105 points by srevenant 4 years ago | 107 comments

I pose this question in all seriousness. An observation: after being an elixir developer for a few years now, and bringing new talent into the mix (no pun intended), is that it's a friction point for new devs learning 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.

The notion that to learn a language you also need to learn a second one is not great. Imagine people saying "cool, learn python, but oh, you also should brush up on cobol while you are at it, you know." It's just bizarre.

And before the vocal defenders kick in I want to clarify that the following response (which is what I usually hear) is NOT a valid response to the question being posed:

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

While this statement might be true, it doesn't address my point. That something is easy to do for one person is irrelevant to the fact it causes friction for new devs and may hinder adoption.

I think there are many amazing points to Elixir, and thanks to Erlang it has a lot of amazing roots. I know both communities are trying to make both co-exist well. But every time I come across an Erlang library, invariably the documentation is a nightmare (if it exists at all) and I have to read the code just to figure something out. This is true also of many system level things even in Erlang. The docs are horrific. Reading the code is NOT an answer.

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?

Flame away :) I ask the question because I'm curious how others feel about it, and I want to help promote more adoption of Elixir. (And hearing from ALL sides, not just defenders of the faith. What about people who've tried elixir and moved on?)

chrismccord 4 years ago |

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

_acco 4 years ago | |

Highlighting an important distinction Chris makes: there's a huge difference between needing to learn to read/understand the basic syntax of a language and needing to learn to write it.

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

Creating something functional from scratch in a language is 100x (1000x?) more challenging than learning how to roughly read it.

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.

linkdd 4 years ago | | |

This.

I was able to read Erlang before knowing the name of the language. I discovered this language by looking at the source code of RabbitMQ, and I was surprised at how I could read it, knowing nothing about the language.

At first I thought atoms were variables defined somewhere (and I did not care where it was defined, the names were explicit). When I learned that they are in fact values, it blew my mind.

It's only 6 months later I started coding in Erlang. Then 3 years ago I started writing Elixir. I did not have to learn Elixir in fact, it was just another syntax for what I already knew.

I always recommend learning Erlang first with https://learnyousomeerlang.com/ and then learning Elixir. Simply because this book does a far better job at explaining OTP than the Elixir docs.

Maybe there is some value in writing learnyousomeelixir.com?

SOLAR_FIELDS 4 years ago | | |

I can read C++ pretty well, I know how to build, compile, and run C++, but I probably couldn't write very good C++. I think it's like reading a book about how a machine gun is used in action and constructing one vs. given a machine gun with no hands-on training and trying to use it myself.

j4pe 4 years ago | |

Is it a bit of extra complexity? Yes.

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.

weatherlite 4 years ago | | |

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

Truth is most web devs don't care about concurrency - it's a thing left for the ops team and with today's tools (k8s) its getting more and more trivial by the minute and it's only gonna get simpler and cheaper.

I'm not saying there aren't any use cases for Elixir, I'm just saying they're not that obvious or common.

mgdev 4 years ago | |

Devil's advocate:

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.

jolux 4 years ago | | |

I had this same thought because I think Elixir and Erlang are actually similar enough that translating between them directly may be feasible and have decent results. I don’t really think forking is a good idea though. As I understand it most BEAM maintenance is actually done by Ericsson, and I’m not sure the Elixir community has the resources to sustain a project like that. It seems like it would also create bad blood with the Erlang community and risk breaking compatibility eventually, which would be a huge loss for users of libraries like Ranch and Hackney.

srevenant 4 years ago | | |

This is what I too have wondered.

I'm curious if there are more devs in elixir or erlang.

I'm also curious if it'd be easy enough to have elixir->erlang transpiling, so those wanting from elixir could pull it.

hauleth 4 years ago | | |

But what would be a point of doing that?

johnisgood 4 years ago | |

Phoenix seems quite bloated. Is there any way to make it work without JavaScript, or do I have to rely on it? I really wanted a web framework where I can have routers, templates, sessions, and the usual stuff and no JavaScript, only if I write it myself into the template. :(

jolux 4 years ago | | |

There’s no JavaScript unless you write it into the template. If you want to use LiveView that needs JavaScript but plain old templates do not.

As for bloat I don’t really agree but I can see how it might appear that way. Phoenix is actually not monolithic, it is sort of just a set of conventions and macros (batteries) that make using Plug and Ecto and some other libraries together more cohesive and more like programming in Rails. If you don’t like that approach you can also just use Plug and Plug.Router directly, which is more of a microframework feel like Flask or Sinatra.

ricketycricket 4 years ago | | |

`mix phx.new foo --no-live` does that. LiveView is completely optional. Node/npm has been completely replaced by esbuild and even that is optional if you want to rip it out and handle assets another way.

adamors 4 years ago |

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.

ch4s3 4 years ago | |

> You can't really learn Elixir without also learning _some_ Erlang

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.

adamors 4 years ago | | |

If you use these superset languages day-to-day you will end up interfacing with the base/platform language at some point.

Just recently I had to figure out why the Elixir Kafka library didn't support something and I ended up using the wrapped Erlang library at the end. Without some Erlang knowledge I would have been completely lost.

ravi-delia 4 years ago | | |

Yeah Erlang idioms are what make Elixir so powerful, but you basically don't have to touch actual Erlang. I've messed around, just because I felt like I should have some appreciation for the work Erlang developers put in, but the Elixir wrappers are good enough it's almost never necessary. Even if you need an Erlang library, you're just calling the functions and the docs are usually pretty good.

cutler 4 years ago | |

I've been happily using Clojure for about 9 years and hardly ever have I needed to dip into any Java code. That's not to say I can't grok Java if I need to. Compared with the monstrosity that is Gradle deps.edn is a breath of fresh air.

scottmessinger 4 years ago |

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.

ch4s3 4 years ago | |

If nothing else you're likely to run into ETS, it's really nice and easy to use. But even still, the calls are pretty easy to make, and the docs are good. You don't really even need to understand any Erlang syntax, it's just built into OTP.

alberth 4 years ago |

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

dogleash 4 years ago |

> "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?

throwaway81523 4 years ago |

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.

JohnHaugeland 4 years ago |

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

dimgl 4 years ago |

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.

alberth 4 years ago | |

> I had to use libraries that had not been ported over to Elixir yet so I had to deal with Erlang

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

dimgl 4 years ago | | |

IIRC they don't, but as someone who doesn't know Erlang, the Erlang documentation was really hard to read and the APIs differed from other Elixir libraries.

freedomben 4 years ago | |

This last part is really important. If you don't already know what GenServer or Application or Supervisor are/do, finding out from just the docs or internet posts is extremely hard.

konfusinomicon 4 years ago | |

did you have an aha moment that finally made it all (genservers and entry points) make sense? if so, what was it?

rkallos 4 years ago |

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.

eric4smith 4 years ago |

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.

myth_drannon 4 years ago |

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.

lukaszkorecki 4 years ago | |

In my experience (7+ years of using Clojure) this is caused by the misunderstanding of what Clojure actually is: it's a LISP designed for the JVM, you cannot escape the host and pretend it's not there. In return you get access to one of the biggest software ecosystems and pull any library from Maven Central etc.

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.

ModernMech 4 years ago | | |

> It's a LISP designed for the JVM

Honestly, this should be the Clojure tagline. Would solve a lot of the confusion. To be truthful, I never pictured it that way, but to be fair I think Clojure sells itself as more than that.

handsaway 4 years ago | |

Well to be fair Elm runs on a completely different platform, it's just the compiler is written in Haskell. "Leveraging the Haskell ecosystem" isn't part of Elm's value prop.

aeturnum 4 years ago |

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.

malkosta 4 years ago |

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.

sa1 4 years ago |

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

The opposite: syntax's different, similar semantics.

atonse 4 years ago |

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.

jacquesm 4 years ago |

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.

dimgl 4 years ago | |

One of those is not like the other. JavaScript and TypeScript are almost interoperable. You don't have to relearn the semantics of the language to use a JavaScript library in TypeScript. It's is an extremely light superset compared to Clojure, Scala, Elixir, Kotlin, etc.

mikepurvis 4 years ago | | |

True, though I think part of this is also recognizing that the more the semantics diverge, the more potential upside there is.

Not that JavaScript-with-types isn't a compelling pitch for TypeScript— it totally is. But that's a benefit that is primarily geared toward scale and safety, whereas Clojure is a completely different kind of language from Java. Maybe I'm just arguing essentially the same point here, that Clojure is always going to be a niche, but the core of it is that if your problem domain demands using a Lisp, and you have other reasons to want to be on the JVM, then it's likely that the cost of having to pick up some Java is going to be well worth it.

jacquesm 4 years ago | | |

Typescript requires an intermediate step though.

We had the Typescript vs JS debate when starting out with pianojacq.com and I was pretty strongly committed to doing it in plain JS and not to have any tooling dependencies or build step. Which I think is the one thing that makes JS at least moderately interesting: that it is a language that in theory does not require any tooling beyond the browser. Of course, the day Typescript is supported natively by the browsers that argument will die. But for now that does not seem to be the case.

freedomben 4 years ago |

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.

jacquesm 4 years ago | |

> I don't think it's "an albatross" but it's certainly not ideal.

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.

freedomben 4 years ago | | |

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

well of course, if you're coming from an Erlang perspective, Elixir is a language that solved/solves a problem that doesn't exist. This is a valid view, but OP's thread is specifically asking as an Elixir dev with the perspective that Elixir solves a problem, rather than introduces one.

Recognizing that different perspectives exist isn't bad (and in many cases is very good), but it doesn't feel super constructive in a thread that precludes those perspectives. It seems a little like forum questions saying something like, "how do I do X on Windows?" and somebody replies, "Install OS X."

omgmajk 4 years ago |

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

salawat 4 years ago |

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.

elesbao 4 years ago |

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.

weatherlite 4 years ago |

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

udfalkso 4 years ago |

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.

yumraj 4 years ago |

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.

Communitivity 4 years ago |

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.

my69thaccount 4 years ago |

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.

sergiotapia 4 years ago |

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.

pera 4 years ago |

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

adolfont 4 years ago |

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.

johnisgood 4 years ago |

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.

fyzix 4 years ago |

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.

ithrow 4 years ago | |

F# has the same problem, you have to learn C#.

rramadass 4 years ago |

Absolutely not!

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

travisgriggs 4 years ago |

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?

josevalim 4 years ago | |

This is fantastic feedback. I always love reading posts like yours. Three quick notes to complement what you said:

* The formatter is always a balancing act. The behaviour you see is because people get really upset when we don't respect their line breaks (and, as you correctly said, we can't later know which newlines were introduced by us). You can try formatting more frequently to get feedback sooner (that's what I do: I usually type code with no indentation whatsoever and "collaborate" with the formatter as I go).

* I am thinking really hard about the struct problem and trying to find a balance between getting some of the guarantees of structs without having to hijack a whole module.

* Re namespaces, agreed they are not as powerful as namespaces in other languages, because they are not actual entities. However, you shouldn't run into issues. If you do recall what it was, feel free to reach out or post something in the forum. The dot notation can be useful in aliases (which a different separator would not help).

Have a good week!

travisgriggs 4 years ago | | |

People like José are why I like the Elixir community. So many others would have taken offense and become defensive.

sbrother 4 years ago | | |

+1 to the struct thing and very interested in your thoughts! I've personally taken to using protobufs instead with the excellent https://github.com/elixir-protobuf/protobuf library. They work beautifully but are obviously a lot more heavy weight. It would be nice to have more ergonomic native structs.

dpeck 4 years ago |

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