Launching Gleam Galaxy

Published: 2024-02-12

The challenge and beauty of a clean sheet is you can do things the right way without worrying about the legacy of the past, but still leverage and learn from what has been done before.

— RJ Scaringe

Every now and then, something new comes along. It promises to be different, and it asks you to take a step outside your comfort zone to try something new. And that’s what I did when I tried the Gleam programming language. Like many others, I came across Gleam when it lit up social media following its 1.0 release. While I prefer the comfort of Python and SQL, in this case, I felt beckoned into the unknown. I had seen the popularity of Elixir which peaked my curiousity in functional languages, but I just couldn’t get hooked on Elixir’s Ruby-like syntax. Gleam however felt more natural and in its own words, “Gleam is a programming language that tries to make your job as a writer and maintainer of software systems as predictable, stress-free, and enjoyable as possible”.

So I decided I’d give it a try, and being that it is a relatively new ecosystem I thought it would be fun to build an app that would track its growth over time. Using ClickPy, one of my favorite Python ecosystem websites, as inspiration I set out to build Gleam Galaxy. Gleam Galaxy is an app that tracks stats on Gleam packages.

Architecture

The web app itself consists of a few main pieces. The frontend is built with Sveltekit, but there is the Lustre framework for those interested in using Gleam for the frontend too. The backend consists of three main parts. The first is a Wisp server which handles all the backend APIs. The second is a periodic job written in Gleam which collects package updates from Hex, using the gleam_hexpm package and drawing on Gleam’s official package site, and stores them in the database. The job runs a few times a day and grabs package-level information as well as daily download stats. Finally, all of that is stored in Tinybird which is built on the same underlying database as ClickPy, Clickhouse.

Thoughts on Gleam Language

Through building Gleam Galaxy I learned a ton about the language and got an initial feel for a functional language. I was quite surprised and enjoyed a lot of aspects of the language.

The absolute best is the pipe operator, |>, and while not exclusive to Gleam it is a must-have for a functional language. This operator works by piping the previous result as an argument to the following function. When chained across multiple lines you get an easy-to-read and syntactically satisfying piece of code to read.

import gleam/io
import gleam/string

pub fn main() {
  // Without the pipe operator
  io.debug(string.drop_left(string.drop_right("Hello, Joe!", 1), 7))

  // With the pipe operator
  "Hello, Mike!"
  |> string.drop_right(1)
  |> string.drop_left(7)
  |> io.debug

  // Changing order with function capturing
  "1"
  |> string.append("2")
  |> string.append("3", _)
  |> io.debug
}

Here is an example from the Gleam Language Tour. Python function chaining has always felt a bit imperfect and Gleam has reinforced that view for me (I also now know there are some libraries that add the Pipe operator to Python).

There are many other wonderful parts of Gleam such as the community, the tooling, Erlang/Beam, result (error) types, pattern matching, and more but I won’t cover all of that in-depth here (you should go try yourself).

One spot I did get a bit tripped up on is Gleam’s use expression, but I think the Language Tour provides a great example.

Other Random Thoughts

I ran into some classic CORS mistakes with Sveltekit, if you ever have those issues just follow the Sveltekit docs.

JSON encoding/decoding is a bit tedious, but this new decode library looks to be a lot cleaner.

Gleam’s mascot Lucy is the best programming language mascot, and also has a great taste in icecream

Blasting Off

I hope you check out Gleam Galaxy and the Gleam Programming language!

I'm on Twitter if you want to follow for more updates. Cheers!