My Road to Erlang (2008) | Hacker News Reader

My Road to Erlang (2008)

prog21.dadgum.com

152 pointstodsacerdoti24 comments

"relentlessly productive" really resonates with my view of Erlang/OTP. I do Elixir which sits on top of it but that remains.

I think Erlang is an uncommon language in that it seems to be foundationally constructed to build things. The FP isn't a philosophical experiment or a research project so much as a necessity to wrangle state reliably in distributed actors.

It is a language and probably most importantly a runtime/VM that was born out of industry and it has some very powerful properties.

I keep returning to this on beamrad.io, I'm impressed by the pragmatism in Erlang. And I think the also very pragmatic but much more marketing-savy and dev experience-focused Ruby culture feeding into Elixir is a pretty sweet mix.

> I think Erlang is an uncommon language in that it seems to be foundationally constructed to build things

I think both Scala and Clojure sit in this camp as well.

Parts of modern scala, maybe. The community used to be pretty bifurcated between those things you suggest, and the adamant academics over type theory so militant that it didn't even seem they cared if you could actually build something.

I had a similar experience to the author in evaluating various functional languages. It's clear that Erlang was designed to be a relentlessly productive language from the start. It has an excellent standard library, nice abstractions, many of the nice features from ML family languages like pattern matching and immutability (pattern matching for binary data was a revelation), and great documentation to boot.

That’s all well and good, I flirted with erlang for about 2 years, went to the conferences, got a few patches in here and there… but this was all as an individual developer, soon as I tried to introduce it anywhere it fell really flat on its face. The syntax and OTP are just too alien for most of the devs at least at the level I was working at then.

Shame, it’s good stuff.

Anyway, here’s to elixir ;)

Edit: I would say tho learning erlang made me a better developer, it changed my brain in some kind of irrevocable way and I would recommend it to anyone even if the skill itself isn’t so useful professionally

Re: your edit, I've heard people say similar things about Lisp. I wonder if that applies to functional languages in general?

Generally this is going to be true of newer experiences that offer a shift in perspectives.

I think probably yes. In Erlang world though you get so much for free with beam that it changes your worldview a bit. Say you're writing, I dunno, a spring boot api to expose some db records as a service and suddenly this api is getting hot on the network... Now you need more than one of them, so suddenly state comes into play, maybe sessions, and so on.. With Erlang, you can take your single node app and reasonably trivially make it run on 30 nodes.. There are gotchas, of course, but the quote is quite good: "Any sufficiently complicated server backend contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Erlang."

I think the key insight in Erlang/OTP is that it should be easy to make any part of your application asynchronous and highly concurrent. Not only can you spread an application trivially across many servers, but even within a single server boundary you can take a GenServer and make as many copies of it as you want. you can break up any application into a set of processes communicating with each other asynchronously with not very much effort, which can make breaking it up and scaling it onto more servers easier when you eventually need to. OTP makes highly concurrent applications a joy to write.

I'd say in 2021 it applies to anything except Javascript, C#, Java, Python and Go.

It applies to any language that differs significantly from the imperative programming model that many programmers are weaned on. You might try the book Seven Languages in Seven Weeks, or offhand I can recommend Racket, Erlang/Elixir, Smalltalk, APL, and Haskell or OCaml.

Prolog might also belong on that list as another "weird" paradigm to explore.

And Erlang syntax is very Prolog-y.

I think it applies to almost any programming language and certainly also to every programming paradigm.

Diving deep into the BEAM and OTP (via Elixir for me) had a similar effect. Completely changed the way I think about code and I notice so many headaches in other languages that I just never paid attention to before.

Pretty much exactly the same here but a little before Elixir came out (might have been easier via Elixir). Erlang itself serves a very niche purpose and occasionally people will try to misuse it. The principles behind its design, however, are readily applicable to a lot of problems related to reliability and scalability.

I believe pattern matching in Erlang comes from Prolog, on which Erlang was prototyped.

It has been 13 years. What is the author using now?

> the tutorials were self-absorbed in the accoutrements of functional programming

At least this has probably improved since then.

His point seems to have been that the tutorials were like that, because the languages were like that.

Functional languages born out of theoretical concerns and commentary tend to prioritise the art of the possible, not the art of the needed.

His point - and I've only ever dabbled with Erlang, so can't attest whether he's right or not - is that as a functional language born out of real industrial practice, Erlang prioritises other things that interest him more.

He makes a compelling case. Most Erlang programmers do. And unlike proponents of many other languages they can point to decades of industrial success.

Those tutorials of other languages can't. They exist because they can, and that's fine, but if you're building stuff salaries - maybe even lives - rely on, maybe those accoutrements are more distraction than essential feature.

It's part of the essential dichotomy of programming languages.

Pragmatic languages and theoretical languages (that may or may not be pragmatic).

As a "working" developer I've always preferred pragmatic languages (the more advanced Pascals back in the day, C#, TypeScript etc) over the theoretically "beautiful" languages.

Of course the barriers are permeable and we often get the useful parts from the theoretically beautiful languages eventually and that's great - I trust the creators of the pragmatic languages to apply taste to which features we eventually do get.

Well, as someone that really enjoys C++ despite the flaws inherited from C, that is how many conference talks feel like in a language with years of industrial practice.

Not "How I did this product in C++", rather how I mastered template meta-programming and SFINAE to build this gorgeous data structure that picks an element in under 5ms using 10KB max. /s.

So FP is not alone in this kind of stuff.

My road to Erlang passed through Elixir :-)

OT, but this article reminded me how back in the late 00's on HN the community would periodically flood it with Erlang articles. I believe it was to flush out some other unwanted content, but I forget the exact impetus.

Reply on news.ycombinator.com