Why start this Gleam Blog?

Jan 26, 2023   Kero van Gelder

Once upon a time there were Erlang and JavaScript...

I am always looking for better tools for programming. I really like the concept of processes as Erlang/BEAM has, with their local state and messages passing between them.

For a portable UI, there seems to be no way around the browser, with HTML, SVG, CSS and JavaScript. I would rather not program in JavaScript, though. That brought me to Elm a few years ago. Learned about TEA, it turned out that that is the way to do UIs, for me. Add a pattern-mapping, typed, pure functional language, and I was sold! Then I wanted to use a websocket, and found that Elm boundaries are rather hard to break out of.

I made a side-step to ReScript, but that language is tied too closely to JavaScript and likely to get even closer. I had too many exceptions.

... and then there was Gleam

The language Gleam compiles to both Erlang and JavaScript, promising to hold the model on both server and client side. A JSON codec is already available to pass data from server to client and back. Calling Erlang and JavaScript from Gleam is a breeze, compared to both Elm and ReScript.

Lustre provides me with TEA.

And let's not forget the wonderful, inclusive community.

What will I blog about?

If I have a Gleam model, but cannot export the lustre UI to Erlang, I need it in a separate package. This package then, must be used from my existing Erlang backend, and in the lustre UI project.

This blog, thus, has Gleam center stage, Erlang and the browser on the sides.