9 ms·
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 languag
by vector_spaces 5y ago
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.
- cyberpunk 5y agoThat’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
- Karunamon 5y agoRe: your edit, I've heard people say similar things about Lisp. I wonder if that applies to functional languages in general?
- mononcqc 5y agoGenerally this is going to be true of newer experiences that offer a shift in perspectives.
- cyberpunk 5y agoI 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."
- jolux 5y agoI 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.
- LAC-Tech 5y agoI'd say in 2021 it applies to anything except Javascript, C#, Java, Python and Go.
- jolux 5y agoIt 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.
- ollran 5y agoI think it applies to almost any programming language and certainly also to every programming paradigm.
- brightball 5y agoDiving 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.
- R0b0t1 5y agoPretty 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.
- deleted 5y ago[deleted]
- tannhaeuser 5y agoI believe pattern matching in Erlang comes from Prolog, on which Erlang was prototyped.