Now that Cowboy 1.0 is out, I can spend some of my time thinking about Cowboy 2.0 that will be released soon after Erlang/OTP 18.0. This entry discusses the proposed changes to query string handling in Cowboy.
Cowboy 2.0 will respond to user wishes by simplifying the interface of the cowboy_req module. Users want two things: less juggling with the Req variable, and more maps. Maps is the only dynamic key/value data structure in Erlang that we can match directly to extract values, allowing users to greatly simplify their code as they don't need to call functions to do everything anymore.
Read More
I will now be regularly writing posts about project status, plans and hopes for the future.
Before that though, there's one important news to share.
Until a year ago all development was financed through consulting and development services. This worked alright but too much time was spent doing things that didn't benefit the open source projects. And that didn't make me happy at all. Because I like being happy I stopped that for the most part and spent the year figuring things out, experimenting and discussing with people about it.
Read More
This was a triumph! I'm making a note here: HUGE SUCCESS!!
It's hard to overstate my satisfaction. Thanks to everyone who made this possible.
If you have backed this fundraiser, and haven't provided your personal details yet, please do so quickly so that your rewards can be sent!
I am hoping that we will be able to make good use of all that money. The details of the expenses will be published regularly on the 2013 Fundraiser wiki page, giving you full disclosure as to how your money is used.
Read More
Building OTP releases has always been a difficult task. Tools like Reltool or Rebar have made this simpler, but it's no panacea. This article will show you an alternative and hopefully much simpler solution.
There is two steps to building a release. First you need to build the various OTP applications you want to include in the release. Once done, you need to create the release itself, by including the Erlang runtime system alongside the applications, a boot script to start the node and all its applications, and some configuration files.
Read More
Today we will start the work on the intermediate module that will be used to run the code for the expressions found in our file's body, replacing our interpreter.
This is what we want to have when all the work is done:
xerl -> tokens -> AST -> intermediate -> cerl Today we will perform this work only on the atomic integer expression however, so we will not build any module at the end.
Read More
As promised we are adding an expression separator this time. This will be short and easy.
In the tokenizer we only need to add a line recognizing the comma as a valid token.
, : {token, {',', TokenLine}}. Then we need to change the following lines in the parser:
exprs -> expr : ['$1']. exprs -> expr exprs : ['$1' | '$2']. And add a comma between the expressions on the second line:
Read More
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.
Read More
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.
Read More
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.
Read More
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.
Read More
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.
Read More
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.
Read More
