I would like to share some experience and theories on Erlang scalability.
This will be in the form of a series of hints, which may or may not be accompanied with explanations as to why things are this way, or how they improve or reduce the scalability of a system. I will try to do my best to avoid giving falsehoods, even if that means a few things won’t be explained.
We will be adding atomic integer expressions to our language. These look as follow in Erlang:
42. And the result of this expression is of course 42.
We will be running this expression at compile time, since we don’t have the means to run code at runtime yet. This will of course result in no module being compiled, but that’s OK, it will allow us to discuss a few important things we’ll have to plan for later on.
Everything is an expression.
This sentence carries profound meaning. We will invoke it many times over the course of these articles.
If everything is an expression, then the language shouldn’t have any problem with me defining two modules in the same source file.
mod first_module begin end mod second_module begin end Likewise, it shouldn’t have any problem with me defining a module inside another module.
mod out_module begin mod in_module begin end end Of course, in the context of the Erlang VM, these two snippets are equivalent; there is nothing preventing you from calling the in_module module from any other module.
Let’s build a programming language. I call it Xerl: eXtended ERLang. It’ll be an occasion for us to learn a few things, especially me.
Unlike in Erlang, in this language, everything is an expression. This means that modules and functions are expression, and indeed that you can have more than one module per file.
We are just starting, so let’s no go ahead of ourselves here. We’ll begin with writing the code allowing us to compile an empty module.
Last week I was speaking at the London Erlang Factory Lite where I presented a live demonstration of building an FTP server using Ranch. As there was no slide, you should use this article as a reference instead.
The goal of this article is to showcase how to use Ranch for writing a network protocol implementation, how Ranch gets out of the way to let you write the code that matters, and the common techniques used when writing servers.
Everyone knows Tic Tac Toe, right?
Players choose either to be the Xs or the Os, then place their symbol on a 3x3 board one after another, trying to create a line of 3 of them.
Writing an algorithm to check for victory sounds easy, right? It’s easily tested, considering there’s only 8 possible winning rows (3 horizontal, 3 vertical and 2 diagonal).
In Erlang though, you probably wouldn’t want an algorithm.