Erlang's use in the telecom sphere has primarily been focused on switching, routing, and real time voice processing on the backend. Beyond just handling cellular traffic, many internet switches are written in Erlang too. It's only recently that Erlang has been used for more of the type of code that could run on the frontend. (The niceness of writing Elixir is a big part of that too.)
The primary blocker to running Erlang on mobile has been the lack of portability of the BEAM VM itself, which is why this project is so exciting!
I looked at using this for a client project a few months ago. We use Erlang and Elixir at work, and it's my go-to for anything serious.
Be aware that parts of their stack use a custom license for some components... but a large portion of it is OSS Apache 2.0, which is nice if you can stick to those parts!
In middle school, in an attempt to get around the school firewall, I copied the HTML code from that website to my own to play Minecraft at school. Since my domain wasn't on the blocklist, it worked! But when my friends started using it to play, even after they hadn't bought the game, I resolved to add a login wall.
I built a backend proxy in PHP that would POST their credentials to the Minecraft API to make sure they had purchased the game. I still think it's funny to think I had no ethical qualms about circumventing the school firewall, but piracy was where I drew the line.
This book is a fantastic introduction to Erlang in very approachable language. It introduces the reader to both language syntax and design decisions that led to Erlang's strengths as a highly reliable programming language for realtime applications.
If you're learning Elixir right now, I can't recommend enough to also learn a bit about Erlang. The OTP and BEAM VM sit underneath both systems, and learning about what's going on under the hood helps a ton when troubleshooting production issues!
Were you at all inspired by the work of Bartosz
Ciechanowski? My first thought was that you all might have hired him to do the visuals for this post :)
> OTP in Gleam is what took me the most effort to figure out. The hexdocs cover the basics but that wasn’t enough for me to get the concepts right, especially where they differed from their Erlang counterparts.
This was the biggest thing I noticed as well- core OTP concepts like gen_servers and supervision trees aren't covered in the language tour, the docs, or even the "Gleam for Erlang Users" page... it makes sense that it's missing if it's pre-1.0, but I was very confused when I didn't find anything about it at all.
Donald Bitzer was the first Computer Science professor I had in college. He taught a discrete mathematics course (boolean logic).
Though he was on the older side when I took his course, he still brought laughter and enthusiasm to his classes, and set the tone for the rest of my college career. He will be missed!
Same. It was my first CS class after transferring to NCSU in 2000. I was pretty lost at times but he was super kind and patient whenever I went to office hours. He was an older professor at that time and it was always cool to see was still teaching well beyond when I graduated.
Ditto, I took his discrete math course at NCSU in 1998. It was mainly taught by Tiffany Barnes day to day (who was also nice and a great explainer), but Bitzer was often present and always smiling and jovial.
I really regret having spent so little time interacting with my professors though. I was one of those kids that spent the least amount of time in class possible, almost never going to office hours, aiming to get the course work out of the way asap so I could "have a life". So much wisdom and life/industry experience was concentrated on that campus and at my fingertips, but I totally took it for granted. Seeing his obit amplifies this feeling; I wish I had cared enough at the time to meet and know the guy.
Yeah, there were some other older professors at NC State who had clearly aged out of knowing the state of the art, but Bitzer was an enthusastic teacher who cared about engaging students, and still knew his stuff.
People may "prefer" simply replacing containers, but as some siblings mention, some applications might require more reliability guarantees.
Erlang was originally designed for implementing telephony protocols, where interrupted phone calls were not an acceptable side effect of application updates.
FWIW as soon as you start using containers you should be able to handle those containers spinning up/down. Pretty much the whole point of containers. At which point you don’t need to bother with code hot swapping since you already have a mechanism for newer containers to spin up while older ones spin down.
The sibling post “that’s how they update without downtime” is super naive. It is absolutely not how they do it.
If we to wedge how Erlang does hot code swapping into a container metaphor, then to get what Erlang does, you'd need to have a container per function call.
Given that it would be absurdly wasteful to use OS processes in containers to clone Erlang's code reload system, AnotherGoodName might take ten minute to watch Erlang: The Movie to get a better sense of the capabilities of that system. The movie is available from many places, including archive.org.
>If we to wedge how Erlang does hot code swapping into a container metaphor, then to get what Erlang does, you'd need to have a container per function call.
You have a container that responds to HTPP requests sitting behind a load balancer, then you spawn a new container and tell load balancer to redirect calls to the new one. From the point of view of whoever is calling the load balancer you have hot swapping. You may even separate containers into logical groups and call it microservices architecture. Or you can define a process as something having qualified name and a mailbox and is sending messages to other processes.
Now reasonable people may disagree about what's wasteful, but the market seems to tolerate places where adding a checkbox to a form is a half a year process involving five different departments and the market can't be wrong.
Sure, you can shut down and restart your entire application. You could do that back in 1990 without containers, too.
The thing is that Erlang does hot reload at a per-function (or -according to Hebert- sometimes more-fine-grained) level, so nuking the entire program and paying the cost to start it up again is not at all the same thing as -say- using a not-absurdly-priced AWS Lambda [0] or similar to get per-function hot reloading.
By the way, have you read "A Pipeline Made of Airbags"? If not, you should give it a read: <https://ferd.ca/a-pipeline-made-of-airbags.html>. It might be old news to you, maybe, but maybe not.
I didn't read that one before, but I share the sentiment. We can't have cool things and it was all dumbed down, so the worst case become a default mode of operation. This didn't happen specifically with hot reload in erlang, it happens all the time at all levels.
Erlang does have a mechanism that allows a module to control when it moves from the "old version" to the "new version" of its own code. Calls to the module with the fully qualified name (e.g. `module:function()`) will invoke the "new code" once it's loaded, but calls within that module using only function names (just `function()`) will continue to invoke the "old code".
If the portion of the app you were hot upgrading was an OTP process like a GenServer, you could theoretically wait for some sort of atomic coordination mechanism to make that fully qualified function call after the new code has loaded, at least in theory.
We use hot code reloading at my work, but haven't had a reason to atomically sync the reload. Most of the time it's a tmux session with `synchronize-panes` and that suffices. If your application can handle upgrades within a module smoothly, it's rare to have a need for some sort of cluster-level coordination of a code change, at least one that's atomic.
The primary blocker to running Erlang on mobile has been the lack of portability of the BEAM VM itself, which is why this project is so exciting!