Learning the syntax and libraries is one thing and there are any number of resources which can inform you and get you through getting those things under your fingers.
I would suggest that "getting" Erlang is more than that however and is important as code that does "something", but not necessarily in a good way, can be avoided by understanding the broader ideas you're dealing with. On that count I recommend Joe Armstrong's doctoral thesis: https://erlang.org/download/armstrong_thesis_2003.pdf. It's basically a detailed examination of what the language and runtime environment are trying to achieve: it answers "what?" and "why?". It's not a difficult or obscurely technical read and even though it's a couple hundred pages, you could probably get through it pretty easily in a couple of days depending on how fast you read.
I don't code Erlang myself, but I do a fair bit of Elixir work, and found it very enlightening for establishing the context from which all the details I do deal with using a BEAM language follow.
I always loved this one. https://learnyousomeerlang.com/
By the same author, for more advanced topics: https://www.erlang-in-anger.com
This is where I started with Erlang, learned it first then leaned Elixir. I really enjoyed working with Erlang/Elixir & OTP.
I’d agree with previous suggestions, either this book or Joe Armstrong’s.
+100! The whole book is online for free and I've found it explains things in a very plain and friendly way.
I also really love this book! I'd also add that Adopting Erlang[1] is a great resource.
+1 Fred's book is great -- I learned Erlang using it
Once you are familiar with either Erlang or Elixir I strongly recommend the book "Designing Elixir Systems with OTP" (the one with the bee and honeycomb on the front).
It's not a programming tutorial, but it shows how to structure real world programs to make best use of what you get with Beam+OTP+Er{lang,lixir}. It's written as an Elixir book, but it's talking about architectural concepts that map directly and easily to Erlang.
[summary of the book: write as much as you possibly can in pure functional code, mostly because it's so easy to test. Then use GenServers (etc.) at the boundary to hold the state at the top of your stack of pure code]
> [summary of the book: write as much as you possibly can in pure functional code, mostly because it's so easy to test. Then use GenServers (etc.) at the boundary to hold the state at the top of your stack of pure code]
In my experience this is a good idea in pretty much any language, see also https://www.destroyallsoftware.com/screencasts/catalog/funct...
Indeed - that is the exact architecture that the book is talking you through. It maps it well on to the specific tools you have available in Elixir. Unsurprisingly, Elixir is an extremely good fit for this architecture.
Elixir. It has the very same concepts (actually it IS a dialect of Erlang - it's just a different front-end for the same compiler), but with a saner syntax. After a while you do Elixir, you'll start grokking Erlang.
(Of course, if you need to deep dive into some Erlang code tomorrow, "Learn you some Erlang" or Joe's book. But do your Elixir.)
Also, https://ferd.ca/ , the guy behind Erlang in Anger and Learn you some Erlang, has a lot of very well thought-of contents.
"saner syntax" is a very, very subjective take. "More familiar" sure.
I'm with you for "subjective". Though "strings are UTF8 binaries" ain't that bad. Or first-class, MD documentation. Or the pipe operator. Or a number of other niceties. :-)
Well, Erlang has been picking up :)
- OTP27 added sigils[0], which allow you write UTF8 strings with just an additional tilde character
~"hallöchen" =:= <<"hallöchen"/utf8>>
I also miss the pipe operator, but there seems to be some opposition against it in Erlang-land (and it would need to be adjusted as Erlang's standard library doesn't put the "main" argument consistently in the first argument slot like Elixir does).
[0]: https://www.erlang.org/blog/highlights-otp-27/#sigils [1]: https://www.erlang.org/doc/readme.html [2]: https://hexdocs.pm/elixir/writing-documentation.html [3]: https://hexdocs.pm/rebar3_ex_doc/readme.html
“Oh no! How could anyone possibly learn to a sentence with a period?!”
Also second this. It might seem at first like an unnecessary lift, but it will be a great stepping stone. If you haven't used a functional language before, there are some differences you need to grok (such as immutability, looping) before you'll be able to kill it. Elixir's syntax will be a lot more familiar to you, but will get you used to all the data structures/types/patterns you'll need for erlang. At that point it's just learning some syntax differences.
If you're debugging an Erlang system, you might want to look at Erlang in Anger. [1] As I recall, it's got more information on debugging real systems.
Otherwise, the books and references will help you get the syntax and maybe some of the otp system libraries, but the learning part is coming to terms with the core concept of a process as something with a bit of state that reads its message queue and responds. Each process should be fairly simple as it only manages its state and processes one request at a time. Sometimes business requirements make that processing complex. Sometimes processing that request means gathering information from other processes --- this can get complex if there's ordering or consistency requirements; in that case, the least complex option is to make sure all the requests that need consistency among themselves are handled by the same process. If only one process accesses the data and it only processes one message at a time, transactional concerns are easy to manage.
ETS works a little different under the hood, but think of each table as a process, if you want to read a key, you send it essentially { self(), read, Key} and it replies with the data. Same deal for writes, etc.
Mnesia is processes that you send messages to, and then that process does what you asked and sends the result back.
The beauty of an Erlang system is you can get a shell on it, and inspect all sorts of stuff. You can get a list of all the processes, and see how long their message queues are. If something has a long message queue, you can get a copy of the queue and inspect it. If it's a gen_server and it's not totally stuck, you can get a copy of its state.
You can look at the ETS tables. You can look at the Mnesia tables. You can look at the ETS or DETS tables underneath the ETS tables.
But you do have to be a little careful sometimes. If you are low on memory, and you get a copy of a big message queue, you could exhaust your memory and kill the whole VM. Many of the old footguns have been disarmed, but Erlang still gives you plenty of ammo to shoot yourself in the foot.
Programming Erlang by Joe Armstrong. It’s written by one of the language’s creators and is very engaging and accessible. There are a few features that have been added to the language since the book was published but they are easy to learn later.
https://spawnedshelter.com/ is a great list of resources to get started
https://learnyousomeerlang.com/
Much better than Learn X in Y min
Erlang the language is pretty simple. What takes some grokking is first, the concurrency approach; and second, the OTP library. If you're used to Golang or using Python with threads communicating through Queues, Erlang works about the same way, with the additional feature that a process exiting also kills its parent unless the parent explicitly traps the exit signal. In OTP parlance, a process that traps exit is called a supervisor, since its usual function is to restart the crashed process.
Learn You Some Erlang has some useful discussion of OTP, and it was a big help to me to read through the OTP library source code. That of course will also get you more comfortable with Erlang itself.
I think Erlang's concurrency model is quite a bit different to the likes of Go (and probably most other languages). With Go you still have to worry about shared memory and have to manage that correctly when using Go routines. In Erlang, there is no shared memory with processes. Parallel processes are completely independent, they have their own stack and heap, and so the only way one process is able to share or access data to/from another process is through message passing.
I haven't used Go all that much, but in Python I try to write in a style that avoids any mutable objects accessed by more than one thread. All communication is through queues and I tend to have a simple RPC scheme sending callables through the queues. This has always worked pretty well for me.
I have used exercism for learning new programming languages in combination with doing Advent of Code. They have a learning track for Erlang (https://exercism.org/tracks/erlang) and you can get feedback for you implementations.
Heads up that exercism's finances are not looking good: https://exercism.org/blog/september-2024-restructure
I used an LLM tool to give me little exercises to do, then i'd show my work and it would give feedback, and references for more info. Specifically, https://www.phind.com
Edit* Look, it showed me this same Ask HN post as a reference:
https://www.phind.com/search?cache=avz73b8uy17qz70rfoto0x8t
Also, here is an Awesome list concerning Erlang:
https://github.com/drobakowski/awesome-erlang
And Elixir's HexDocs section on ETS:
here's a big video series on youtube (https://www.cs.kent.ac.uk/ErlangMasterClasses/ -- links to videos on the bottom)
The syntax of erlang, while a little weird, is very small. I struggled the most with immutability.
Regardless of the language, I found that the fastest (but not necessarily the least painful) way to learn a language is to join a project written in that language and try to contribute. This accomplishes multiple goals at the same time: seeing the usual tools and practices, seeing how larger projects are built, seeing where common problematic places are.
Some helpful things about understanding Erlang: having familiarity with Prolog. While languages work differently, on a syntactical level they have quite a few things in common. Knowing one helps to anticipate how things may work in the other in terms of syntax. You would also benefit from familiarity with persistent data types. Often the way data can be accessed defines more high-level decisions within application. Coming from the world of mutable data structures it's easy to get trapped in situations where you realize something is impossible to do the "usual" way. There are, well... "patterns" that emerged in Erlang that might be quite unique (eg. ports), but I wouldn't know about a source that accumulates and catalogues such patterns. Just know that Erlang has quite a few of those. Sometimes the word describing a function or a module wouldn't make sense to a new programmer, because the jargon has changed (eg. ports, again), pay attention to those case, they usually describe some "super-structure" in the code.
Finally, one more thing that I found that makes you understand the language better: writing native extensions. In this way you get very intimate and "first-hand" understanding of how some mechanisms work that cannot be properly exposed in the language itself.
Learn how projects are organized. What are applications and releases (releases is what we call 'distributions' in other ecosystems). Install rebar3, create a new release. Write a hello world inside this scaffolding. Learn how to run it, how to enter the shell. Learn what is OTP and gen_server. Write a simple gen_server app. Make it fall randomly each minute. Learn what is a supervisor, and how it can restart the failing app. Play with supervisor settings.
Write a highly parallel web scraper / downloader as your first project, with workers and supervisors, there are plenty of examples how to do this with Erlang.
Then, learn the rest of the language, now that you know its raison d'être.
I dug up a blog post of mine that's no longer on the net, from 2012. Some of the resources are likely still valid. The links did not come through, so you'll need to do some searching.
Top 10 Resources For Getting Started with Erlang
These are the top ten resources that helped me when I started learning Erlang. I've not ordered them within the list because they complement each other. Your mileage may vary. Other Erlangers opinions may differ. These helped me greatly though. I cannot stress enough that there is no substitute for making. The below will help you much more if you start out trying to solve with Erlang some problem you know about. Decompose it into very small pieces and take each piece one at a time. For some more info on that see the post introducing the concept of Deliberate Practice.
1. Learn You Some Erlang I started learning Erlang back in 2009 at about the same time Learn You Some Erlang chapters started being posted by Fred Trottier-Hebert. This is the first place I'd recommend someone go when they are learning Erlang, especially if they have good prior software writing experience. I found LYWSE easy to understand and packed with detail. Sometimes it goes into too advanced details for a beginner, but you can skip these and come back to them when you are ready.
2. Joe Armstrong's Thesis Reading this thesis is drinking direct from the source. Joe Armstrong is one of the three fathers of Erlang. The other two are Bjarne Da ̈cker and Robert Virding. Reading A History of Erlang (PDF) by Joe Armstrong won't teach you Erlang, but it's a very interesting read.
3. The Erlang Web Site Erlang.org has some good examples, the OTP Design Principles User Guide, the Erlang Reference Manual, the documentation for the Erlang OTP libraries (Erlang's stdlib), and an online self-paced course.
4. The Erlang-Questions Mailing List The people on this list are very helpful. Chances are that your question has been asked before, so search the archives first. As with any mailing list it can take time to get an answer, so I tend to just use the archive. The FAQ, a link to the archives and instructions for subscribing are on their web site: http://erlang.org/mailman/listinfo/erlang-questions.
5. Free E-Books and Other Web Resources The following books are good to use for times when you don't have time to get into the coding zone, or when you want to deep dive into a particular topic. Concurrent Programming in Erlang, Part 1 Erlang For Skeptics - An old, but still useful, e-book that you'll need to build yourself from this project site. It's worth it though. TryErlang.org - A free hands-on web tutorial for Erlang I remember going through some others, but it's been a long time and I don't remember them. If you read this and know of a good (and legal) e-book link then please post it in the comments and I'll add it below here, with credit.
6. Commercial Books and Podcasts I bought some of the books on this list, borrowed others. They are all recommended, but in this economy it's important to stress you don't need them to learn Erlang, but they will make your learning Erlang easier. Erlang in Practice by Kevin Smith - From all accounts a very good series of screencasts on Erlang Erlang Programming by Francesco Cesarini and Simon Thompson Erlang and OTP in Action by Martin Logan, Eric Merritt, and Richard Carlsson Building Web Applications with Erlang: Working with REST and Web Sockets on Yaws
7. Online Q&A sites If you have a question while learning Erlang the chances are someone else has had it as well. It's also good when you don't have a specific question but you have some time to spend on learning. When that happens go to one of these Q&A sites and search for unanswered Erlang questions, pick one, and then research it until you have an answer. Once you have an answer you can go back to the question and post your answer if there isn't one yet.
Stackoverflow is probably the best known Q&A site. It is a great source for detailed Erlang information in their Erlang questions. They also have a decent number of unanswered Erlang questions at any one time.
Another less well-known site is Quora (requires login via Twitter or Facebook). They are getting more popular and are more focused on social connections than score, whereas StackOverflow is focused more on the score. They a tag so you can find Erlang questions, but I've not found a link for unanswered questions, only for open Erlang questions.
8. Twitter Twitter is always a great source for information, and for a dialogue with people that may be able to answer your questions. Feel free to follow me and tweet me if you have a problem. I also try to retweet anything on Erlang that I find interesting. My Twitter id is BillBarnhill.
9. Source Code The best way to learn a language is by making useful software using that language. The second best way is to read good code, trace how it runs, and re-read until you understand what it does. Often this will lead into writing code to get the software to scratch a particular itch you have. The best source code to read in my opinion is the OTP sources, for the sole reason that they will be what you interact with the most. The second best is the Github account of Basho and the repos in it, because these folks know their stuff.
10. Erlang Projects I Recommend This one isn't a resource as much as some recommendations from me on projects to learn about byt looking at the materials the developers publish, the source code, and building.
Web servers and frameworks
For web serving I recommend Cowboy. I started out on Yaws, then switched to Misultin for most things, Mochiweb for some others. When Misultin went away I switched to Cowboy and haven't looked back. There's some caveats though. Riak uses Webmachine and Mochiweb, and if you want to use Erlang professionally you need to know Riak. So you need to at least be comfortable with WebMachine and Mochiweb. The web framework Nitrogen lets you use Mochiweb or Yaws, and you should learn Nitrogen. Once you learn Nitrogen I suggest you learn Zotonic, which is a Content Management System (CMS) like Drupal and is built on top of Nitrogen. If you are coming from Rails, or want something that feels similar, then I suggest checking out the Chicago Boss web framework
This one is probably worth adding to your list:
It may not have been a thing back in 2012. To be fair, I'm not sure how the forums and the mailing list compare/contrast in terms of what you can get/what's more popular/etc.
I haven’t updated this in a while, so it too probably has broken links.
I did not like Erlang.
The actor model is a good idea, functional programming is a good idea... but the Erlang tooling experience is awful and many essential tools are dated. Hiring for an Erlang team is hard. Erlang projects can be an actor spaghetti.
And many people in the Erlang community really have to check their ego. If you want to assert that Erlang is the best language, trying other languages first is a good starting point.
In recent years there has been some improvement with the available tooling with the likes of rebar3[1] and just a few months ago WhatsApp released ELP (Erlang Language Platform)[2] which integrates with your IDE as a language server that provides really nice support when working with Erlang.
I did not know about ELP! That’s great.
If you know Emacs, there’s a really good editor mode that’s included with Erlang. Shameless plug…I made a simple tool to make it easier to configure it…
I've had such a good experience with ELP, though did have some issues getting it working correctly with my emacs setup (that's probably somehow my fault). I will say though that for VSCode, it's a case of installing the extension, zero config and it just works!
Elixir is probably a better fit for you. You still get access to the best in class BEAM ecosystem with a more approachable and modern syntax and improved tooling.
The "best in class" you refer is behind the reality of most tech stacks 10 years ago.
Yes, the concurrency is great, but it is concurrency you would probably not need if the code executed faster in the first place. In most cases, you can do all the concurrency tricks you want but if you put the same code in Rust, it just goes brrrr, does what's supposed to do without the spaghetti actor mess and with a sane compiler that actually does work for me instead of the other way around.
The ecosystem is full of circular statements like "[Erlang|Elixir] is the best because [Erlang|Elixir] is the best". Maybe in the 90s the only realistic way to achieve concurrency without going insane was Erlang, I give you that. But it's 2024 and it's a different world now and the successful ideas in Erlang have influenced other tech stacks to some degree. Yes, Erlang is still unique in useful ways but the cost is using tooling from the paleolithic.
Let's use some common sense to try to find out if this is really true: If it is so great then why is it that almost nobody uses it? Who is claiming it is the best? The very few people that use it, who in their majority refuse to use anything else. That makes it look like a sad echo chamber at times.
I wish everyone over there the best but trying to make friends by claiming everyone else has no idea about what they're doing for years is not effective. Your company is not WhatsApp or a telecom company and most likely you don't need Erlang. If you have the specific problem where Erlang shines, by all means use it, but that's space is very narrow.
> In most cases, you can do all the concurrency tricks you want but if you put the same code in Rust, it just goes brrrr
If "just go brrrr" is your idea of concurrency then I agree, Erlang is not the right tool for you.
Concurrency can also be used for fault tolerance and high-availability. Erlang is known for its "just let it crash" philosophy of developing robust distributed systems that "run forever."
Along those lines Erlang provides a whole host of useful tools right out of the box, like being able to inspect and modify! a live system without any prior planning or instrumentation.
It's really an amazing language.
Yep, I think you'd be hard-pressed to find the actual Elixir code to be the bottleneck in a real-life application. But if you do encounter that, you can use something like Rustler[0] for the CPU-intensive bottleneck, as Discord did[1] while working on a data structure they needed. Slow DB queries are something else to look out for.
edit: Didn't see Rustler was already mentioned in a sibling thread, but hopefully the Discord tidbit will be interesting to others.
> Yes, the concurrency is great, but it is concurrency you would probably not need if the code executed faster in the first place.
If you're using Erlang concurrency for performance you're probably doing it wrong.
Well, it depends on the bottleneck. CPU-bound code, I would of course agree. For I/O bound though, especially network I/o with variable peers (which is the vast majority of code written nowadays) erlang's concurrency model is fantastic.
Also worth mentioning is that you can write CPU intensive code in rust and invoke it as NIFs[1]
it's not only telcos which have concurrency problems. you'll find they are quite frequent in programming
Just learn Elixir :) Tooling is so much better.
From OP's post:
> But my current project requires me to learn erlang
https://elixirschool.com/en/lessons/intermediate/erlang
https://gleam.run/frequently-asked-questions/
https://tour.gleam.run/advanced-features/externals/
Both Elixir and Gleam interop with Erlang
That's true, in fact there are a whole bunch of BEAM languages[1]. It's just if OP needs to learn Erlang for their current project, learning Elixir, Gleam, LFE etc... might not be the best use of time.
[1]: https://github.com/llaisdy/beam_languages?tab=readme-ov-file...