Recently I’ve been taking Gaeilge lessons at City Lit. It’s wonderful, but boy it is hard to remember everything.

One thing I’ve found fantastically useful is the app Anki. It’s a spaced-repetition flash-card app, similar to Duolingo, except you can make your own cards about anything you like, and it’s not trying to squeeze money out of you with a subscription. It works on both computers and on mobile. To use the iPhone version you have to buy it first, but all the other versions are completely free.

The app doesn’t come with any built-in content, you have to add that yourself. After each lesson at City Lit I’ve been making my own Anki cards from my notes, and using these to revise. Once I have a little free time I’ll clean them up and publish them for others to use too.

Anki also has an online library of decks made and kindly shared by other people, again free-of-charge. If you create an account and log-in you can download them and add them to your app. There’s decks for all manner of topics. Here’s some of my favourite Gaeilge decks that I have tried:

• Irish 1k, based on the classic soap opera Ros na Rún! It has audio for (almost) all the words, which is very helpful.
• Na hÉin (Birds in Irish/As Gaeilge), with which I’m learning English names for birds too.
• Na Plandaí (Plants in Irish/As Gaeilge), which is the same but for plants.
• Irish sentences bank (Pota Focal House Glossary).
• Irish CEFR B1 Phrases, Vocabulary, and Pronunciation, which has audio, so long as you have an internet connection. It also has a particularly egregious lime green background, for some reason.

My favourite is Irish 1k, for the audio pronunciation.

Tips

I like to add cards on my laptop and study on my phone, typically while on the train or such. If you’re logged in on multiple devices it’ll keep your notes and your progress in sync between them.

You can change how many never-before-seen cards it adds to your to-view pile each day. If it’s too easy or too hard you can turn this number up or down. If you’ve got totally overwhelmed by the workload you can “reset” cards to take them out pile altogether. For the deck I’ve made with my revision notes I keep the number very high, while for the decks from the internet I keep the number very low, and try to aim for 80-90% accuracy (which is visible in the “stats” tab of the app).

In Anki’s settings you can enable the “FSRS algorithm”. I don’t really understand how it works, but it changes how Anki decides how often to show you each card, supposedly to improve memorisation. It was recommended to me by someone from the Anki community online, and it does seem to help.

Ádh mór!

This is my nostalgic record of the tech stuff I’ve been using over the last year. Check out 2023’s post to see where I started the year. Alright, thumbs up, let’s do this.

My workstation

I’m still using the 2020 Macbook Air with 16GB RAM, hostnamed “Diglett”. It’s doing me well, though I’m somewhat hitting the limits of what it can handle. Streaming to Youtube and Twitch and also trying to compile Rust makes it overheat and throttle the CPU, at which point everything slows down a ton. My solution has largely been to not do Rust streams. Ah well.

I’ve upgraded my 1440p monitor to a 27 inch 5K LG display that I got a good deal on second hand. It has some issues with temporary image burn-in (is that the right term?) and a couple dead pixels, but it works and I enjoy the extra screen space, and it’s nice to give other people’s old electronics a new life that isn’t landfill.

Hey, so you know how Apple sells 5K displays? MacOS must have great 5K display support then! Scaling the UI appropriately rather than making everything unusably small, right? Yeah, turns out MacOS is terrible with 5K displays. Far worse than Windows or Linux. I had an absolutely miserable day fruitlessly trying to find a solution and thinking I’d wasted my money. In the end Magic Mike Marshall came to the rescue and recommended BetterDisplay. Thank you Mike!

I’m honestly stunned that MacOS is so bad at this. It’s supposed to be the “just works” operating system that puts loads of work and polish into their UI, and they’re selling 5K displays for it!

Oh, and I bought a pair of AirPods Pro 2, mostly motivated by their transparency mode where you can still hear the outside world wearing them. They’re a lot better than I expected, I’m rather fond of them now, and I use them for pretty much everything. Except the microphone, the microphone is pants.

I’ve continued to enjoy Neovim, but I’m growing irritated with the Lazyvim distribution. The maintainers have a different idea about backwards compatibility than I do, and multiple times in recent months I’ve turned on my computer to discover that they’ve radically changed something and completely broken my workflow. I’m in the process of making my own custom setup based off of kickstart.nvim and mini.nvim, but I’ve not found the time to figure out all the details. I’ve stubbornly been using kickstart as inspiration and writing my own config, but realistically I should probably just clone kickstart and use that as the start-point.

Oh, and I switched from Iterm2 to Ghostty after getting irritated with the silly AI stuff being added. I’d felt Iterm2 was a bit bloated and rubbish, so it was enough to prompt me to try alternatively. Ghostty is very nice! I like that it’s cross platform, so I can use it on Linux etc too.

Homelab

Last year I said I wanted to try replacing Google Photos with something else, and this year Google forced by hand by adding a bunch of adverts and constantly nagging me to buy more storage from them.

Side note: Irritation really does seem to be the most powerful motivator to me. I’ve grown less and less happy with how companies and such will just decide to change something that makes my life worse in some small irritating way. It may be that you get less polish making your own tools or using open source ones, but it’s predictable, you don’t need to worry about suits making changes motivated by their annual performance review, and you get that nice IKEA effect fuzzy feeling.

Anyway- I went for Immich which is an unabashed open source Google Photos clone. I really like it! The user experience is very slick and easily competes with products from large companies.

It’s engineered like some sort of enterprise product though, being a collection of microservices. I’ve no idea why, given it’s intended mostly for self-hosting. Luckily some folks made an all-in-one container image that I could deploy instead of managing multiple different ones, so I can mostly ignore the internal architecture now.

Compared to anything I was hosting previously it’s quite resource hungry. Idle it uses about a gig of memory between all the services and the two databases (why does a self-hosted application need two databases?), so my Raspberry Pi felt a bit underpowered. It especially wasn’t happy at all when running computer vision and transcoding newly uploaded media. I found a used 2021 N5105 Mini PC with 16GB RAM and 1.5 TB of storage in Cash Converters for a good price, so I’ve made that my new home server.

I decided to be bold and use not-Debian for the first time in a million years, and after a lot of shopping around I opted for OpenSUSE MicroOS, an immutable Linux distro with a transactional package management system. This means that to make changes it takes a btrfs snapshot and installs the updates into that snapshot instead of the live system, and then that gets used after the machine reboots. I love this design! No more do you have skew between the intended state of the system and the actual one, and if it doesn’t work you can rollback to the old one. I’ve got it updating and rebooting early Sunday morning, as I thought the default of daily wasn’t what I needed.

As for deploying software to the server, I decided to use containers this time, as I like how they keep everything nicely wrapped up and I don’t need to worry installing language runtimes and their dependencies. I was reluctantly considering using something like docker-compose, but then I discovered Quadlet, Podman’s systemd integration. I love it! It’s one of the nicest little bits of tech I’ve used in ages.

[Unit]
Description=Gleam Developer Survey container
After=local-fs.target

[Container]
Image=ghcr.io/gleam-lang/developer-survey:1.13.0
Volume=/mnt/data/gleam-developer-survey:/app/data:rw,z
PublishPort=8000:8000

[Install]
WantedBy=multi-user.target default.target

Pop that in /etc/containers/systemd/gleam-developer-survey.container, run systemctl daemon-reload, and then you have a container as a systemd unit that works with systemctl start, etc. Delightful!

The Future

The next steps for me are to finish organising all my photos and moving them over to Immich. There’s an import script for Google Photos, but I’m taking the opportunity to sort through all the junk and categorise everything instead of replicating the same huge mess in a new place.

And also to figure out a new nvim config. Only time will tell if I finish this, or if I’ll give up and use kickstart. Either way it’ll be grand, I’m sure.

Happy new year folks. Best of luck to you in 2025, I’ll see you there. x

What is metaprogramming anyway?

The word “metaprogramming” is not like “parametric polymorphism” or “tail call optimisation”. It is not the name of a feature, it is the name of a family of features. Two people could both use the word “metaprogramming” and be talking about two entirely different features that behave very differently.

• A C++ programmer may think of template classes and template functions.
• An Elixir programmer may think of compile time code execution that manipulates code as data.
• A Java programmer may think of runtime reflection.
• A Ruby programmer may think of dynamic metaprogramming with #method_missing.
• A Zig programmer may think of comptime.

And more!

To meaningfully discuss any addition everyone has to have a shared understanding of precisely what the proposed addition is. Avoiding ambiguity and jargon is vital, and there may be a more useful word than “metaprogramming”.

Evolving a programming language

Language design is hard. One can’t evaluate a feature without taking into account the context of the rest of the language and the ecosystem around it. Every feature will interplay with every other feature in some way, and it could be that a seemingly straightforward change has dire consequences elsewhere. For example, if Gleam were to get an early-return feature with an explicit return keyword then its much-loved use feature would no longer work (as use depends on everything being an expression).

The impact on the users of the language needs to also be carefully considered. How could a programmer misunderstand a feature? How could a programmer misuse feature? What sort of a pickle could a programmer get themselves into with this feature when having an especially unlucky or stressful day? We’ve all had days where we look at the code we’ve written and regret the approach we’ve taken to a problem. That sucks. We want that to happen as infrequently as possible.

The more context, the better. Figure out the wider consequences of the feature are. See how it could change how Gleam is written, read, and learnt. Write a bunch of (uncompilable) programs using this future-Gleam and see how it feels to use. Update existing programs and libraries and see how it changes them.

Gleam aims to be predictable, reliable, easy to learn, and easy to read, so any change to the language should not work against these goals.

Putting the cart before the horse

Features are solutions to problems, and we cannot judge whether a solution is good if we don’t know what the problem being solved is.

Identity real problems and deficiencies with reading and writing Gleam today. Not predicted problems or suspected problems. Actual concrete pains that are present in real-world Gleam today. Persistent problems that cannot be reasonably solved with any of the options we have today in Gleam.

List the current approaches folks take to solve these problems and put into words why they are not enough. This will involve talking to other community members to discover how they’re approaching these problems, or even if they consider them problem at all. It may be that during this process you discover a satisfactory solution that you were not aware of!

And no, “I like this feature in this other language” and “it would be cool” are not valid problems! 😁

Compilers are just programs

If you want to add a feature to a program then you need to have an idea of how it would be implemented, and in that respect compilers are no different from any other program. Consider what the compiler is going to need to do when it encounters code using the new feature. How it will analyse the code? What information will it need to figure out? What code it will generate? Without answers to these questions a feature cannot be implemented, no matter how attractive and desirable it might be.

For example, if the feature is Lisp-style macros then the compiler is going to need a way to evaluate Gleam code at compiler time. Currently the compiler can’t do this, so how would that be added? There’s a great deal of complexity there, especially since we want compilation to be fast!

Make a proposal

Once you have done this research and design work then write it up into a document. Detail all of the above, along with what you see as the pros and cons of the design. Share it with the community for discussion, so they can evaluate it and find anything that can be improved or any roadblocks that you hadn’t discovered. If the proposal is good then there will likely be a lot of back-and-forth and iteration on the idea, so all the little details can be figured out.

Be aware that the likelihood of any particular proposal being accepted is slim, so try not to get too emotionally invested in any specific design. Even a proposal that did not make it into the language is valuable as it will influence and inform future work. This is especially true for the analysis of problems with current-day Gleam; It is from out shortcomings in which we have the most opportunity to learn and improve.

Thanks for reading 💖

I’m a sucker for nostalgia, and I enjoy talking and thinking about technology, so I’ve decided to join the /uses train and write about what tech I use and why. Let’s go!

My workstation

I use a 2020 Macbook Air with 16GB RAM, the hostname for which is Diglett. I name all my devices after Pokemon as I’m very mature and enjoy occasionally forgetting exactly which one is Bellsprout and which is one Chansey.

I’m rather indifferent to macOS and in may ways prefer Linux, but they’re reliable machines and I was quite excited to use an ARM processor. I think my ideal would be an ARM Linux laptop that’s design to be repairable and upgradable, but as I’ve got this I’m going to try and make it last as long as possible, to avoid creating electrical waste.

For years I’ve struggled with RSI. I’m largely OK these days, but it means I have to be mindful of how I use computers. I almost never use my laptop as a laptop, instead using it as a desktop computer. Perhaps an Apple mini desktop would have been better, but it’s nice to have a computer I can take with on the infrequent occasions I travel and might want to do some work.

My monitor is some cheap 1440p ultrawide AOC thing that a friend gave to me. I’m not in love with it, but I can’t afford a lovely 5k replacement, so it’ll do for now. My mouse is a Razer brand bluetooth mouse which works well enough for me.

My keyboard! I got into mechanical keyboards in part because of my RSI, but it has become something I really enjoy. I use an ortholinear 40% Planck v7 with a gorgeous green aluminium case and green Acute keycaps. I use Cherry MX Silent Red switches, which are linear and the quietest switches I’ve ever heard. They feel fab to me, and they’re much less antisocial than other switches I’ve used.

I’d really like to experiment with low profile split bluetooth keyboards like the GEIST TOTEM. You could do all sorts of intereting things with them like attach them to your thighs or mount them vertically on a desk, two positions which seem to fit the human body much more naturally than the standard horizontal keyboard position. It’s a lot of money for an experiment though, so it’ll have to wait.

Every desk chair ever seems to give me back ache, including the expensive ones everyone recommends. These days I’m using the rather bizarre looking Varier Variable Balans kneeling chair, which I bought second hand as an experiment. Most the time I kneel on it not the way it’s intended, but it’s working much better for me than a regular chair. I think part of that is that I move around on it so much and rotate through a bunch of different positions while using it.

The majority of the time I don’t sit on anything at all, thanks to my IKEA hand-cranked standing desk. This is maybe one the best things I’ve bought when it comes to my health, I’d recommend it to everyone, especially with how cheap the hand-cranked one is. Standing and moving around has made such a difference for me.

On my desk I’ve got a pair of comically named Sony WH-1000XM3 headphones. I bought them years back for when I worked in a noisy office, but they still get use for playing rave music letting me rapidly alternate between programming and dancing around the room like a nutter. Perhaps controversially, I don’t think they sound very good, and something without isolation (or with a pass-through feature) would be much better for me. ANC can be tiring on the ears, and I’ve missed the doorbell on a few occasions.

Software

I’ve been a Linux terminal person for longer than I’ve been a programmer, but in recent years I’ve been using Visual Studio Code, after being impressed with how easy it was to get going with. However, a week ago I tried my old love Neovim again after having not used it since before Lua support landed. Wow, the configuration and out-of-the-box experience is really good these days! I’ve been using the LazyVim starter template and I think Neovim is going to become my daily driver once again.

Some other software I use on my workstation:

• Firefox, a browser.
• Fish, a shell with excellent UX.
• Migadu and the Apple Mail app, for email.
• mpd with mpc and Persephone, a hacker’s music player.
• watchexec, for running commands when files change.
• xh, an ergonomic terminal HTTP client.
• yt-dlp, a video downloader.
• moreutils, some niche but useful scripts.
• zoxide, a fast directory jumper.
• asdf, a software version manager and installer.
• ripgrep, grep but a little easier to use.

Personal devices

Over the last few years I seem to have accumulated a lot of Apple stuff. I’m a little worried about how annoying it’ll be to move away from them, but that seems to be an unavoidable problem with any brand these days.

My phone is an iPhone Pro 13 Pro (named Machop), which I bought refurbished this year to replace a very broken Android phone. I quite like a lot about the iOS experience and lots of the built-in features and apps are very clever. It has made me much more interested in phones as a programming platform. This is immensely frustrating as the yearly fee you have to pay Apple to run your own software on the computer you bought from them is straight up robbery and should be illegal as far as I’m concerned. I’m very jealous of how Android users can run a full Linux development environment on their phones. A phone and a bluetooth keyboard would be an amazing portable setup and I could forget about laptops entirely!

I have an iPad Air 4 (named Hoothoot) which I mostly use for watching videos when cooking or in bed, and this year I splashed out on the cheapest Apple watch (named Kabuto) when I found one heavily discounted. It’s a too underpowered for most apps to be usable, but I’ve found the “rings” that nag you to exercise surprisingly motivating. It even got me to buy an Apple Fitness+ subscription, which I do make use of. Well done to the Apple marketing team I suppose!

Homelab

Now here’s some computing which brings me a lot joy! Since going full time on Gleam (rather than working 2 jobs at once as I have for many years) I’ve had time for engaging with technology as a hobby again. One thing I’ve been doing is winding down my use of proprietary services and instead running my own software. It has been tremendously enjoyable.

I may be slightly misusing the term “homelab” as my philosophy is quite different to what I see on homelab social media, but I’m not sure what else to call it. I really like trying to do as much as possible with as little as possible so big powerful computers running lots of docker containers of resource hungry programs isn’t very appealing to me. Inefficient software causes more polution, and it’s so much more fun to solve a problem when you have constraints! So many of these systems are designed for large enterprises, but I’m not a large enterprise, I’m some guy with a bad moustache.

I’ve a 4GB Raspberry Pi 4 (named Cubone) which is my server. It boots from an SSD connected via a USB cable, which is a bit silly but the novelty PlayStation case I found was so cute I completely abandoned any logical thinking and bought it immediately. It doesn’t have a place for an SSD inside.

I’ve used configuration management tools like Ansible and Chef a lot in the past, but I don’t enjoy using any of them. The idea behind them is great, but they’re all so slow and overly complex. For my personal stuff I just write some POSIX shell scripts which I scp to the server and run.

If you’re a comfortable programmer and have experience with Ansible or similar then I think using shell scripts will be easier to work with, and can can run in a couple seconds rather than possibly minutes. Give it a try!

VPN and backups

The server isn’t publicly accessible, so I use Tailscale to create a VPN for my devices. Tailscale rules. I love it. It makes a lot of boring stuff really easy.

Backing up and replicating data is really important! There’s few things I would be more upset about losing than family photos. I use Syncthing to replicate my personal data beteen the server and my laptop, and rclone to back it up to Backblaze B2 and my dad’s home server. I think I’d like to replace B2 and get an offline backup next year. I’m also curious about btrfs.

Media

The server has SFTP enabled and my phone pushes photos and videos to it over that. I’m using the app FTPManager, but it’ll probably get replaced as it doesn’t seem to support not pushing photos that have already been uploaded, even if they are no longer in the SFTP receive directory.

For a while I ran Plex, but it sucked! It used monstrous amounts of resources and was constantly nagging to give them money. I replaced it by enabling NTFS on the server and using the Android VLC app to stream videos from it on my TV. It uses pretty much no resources, and the only downside so far is that I have to navigate the file system rather than having some fancy UI. That’s fine, it’s my file system. I know where I put the video I want to watch.

Web

I slightly lied when I said the server isn’t publicly accessible. I’m using Cloudflare Tunnel to man in the middle attack myself proxy HTTP traffic from the public internet to the server. It gets received by Caddy, a fantastic web proxy that finally ended my many year relationship with Nginx.

I’ve got Caddy serving two directories of files, one public, one with HTTP basic authentication, as well as a couple static sites. I’ve also added a CGI module to Caddy and use it to run some scripts, presumably because I’m completely mad.

OK! Hear me out! CGI is good, actually!

It may be kinda slow and awkward, but CGI scripts only uses system resources when they are actually handling a request. There’s so many sites on the internet that serve practically no traffic, and so much energy and compute could be saved by not running those programs all the time, taking up space doing nothing. If we called it POSIX serverless or something I bet we could get some VC funding for it.

Monitoring

I have a handful of sites that I want to know about any outages for, and for this I use gatus. It’s a simple little program that will take a yaml file of URLs and periodically send them HTTP requests, and then sending you a notification if they fail however many times in a row.

It’s written in Go. I tend to opt for software written in Go as there’s a lot of it, it’s typically a single statically linked binary, and often these programs use relatively small amounts of resources. It’s not always the case, but Gatus ticks those boxes.

For notifications I use Pushover, which a service that lets you send a HTTP request to them and they’ll send a push notification to your phone. That’s it. Super straightforward. What’s even cooler is that it’s a single $5 purchase for the app, and then you can use it forever. I hope the developer is making enough money because it seems like a really generous deal to me.

The last bit of software I run is Goatcounter, a basic analytics service, again written in Go. Ideally I’d just parse access logs to get visitor numbers, but some of these sites are hosted on GitHub pages so I don’t have access to that data.

It’s an OK bit of software. The UI is nice, but by default it tracks more than I want (I don’t use their default JavaScript for this reason), and it has this really silly thing where you need to use a new DNS name for each site you want to track. I’m not going to duplicate a DNS record once per site, it’s not practical. I’m hacking around the problem by prepending the hostname to the path when registering events. It works, if unsatisfyingly.

All the alternatives seem to be more invasive or use more resources, so I’m sticking with it for now. Let me know if you have an alternative to suggest.

Networking

Confession time: I don’t understand my home network well enough to explain it. When I moved into this flat I mentioned what I was aiming for to my dad and he turned up later with a bunch of stuff and installed it while giving me one of those “engineer with decades of experience in this field” explanations that’s just a bit too much to absorb in one go. He’s also more of a configure-things-with-interactive-tools than an configure-with-code kinda guy, so there’s a bit of a mismatch there too.

He knows his stuff and it’s been rock solid so I’ve largely ignored it, depriving myself of any opportunity to learn. Don’t worry, it’s there on my never-ending todo list. Somewhere…

The Future

I add to this little project every now and again as the mood takes me. Other than the additions mentioned above I’d like to try a minimalistic approach to Prometheus. It seems promising, didn’t use too much memory in my brief test, and it has Pushover support. Perhaps it could replace Gatus too.

PhotoPrism looks like very nice photo library software. I’m hoping Grist could break my Google Sheets dependence. I use Apple notes for Journaling and some basic data collection, I’d like to export that data and keep my own copy somehow. DNS that blocks adverts like AdGuard Home could be good for my phone’s battery life and surfing experience.

So yes, lots more fun to be had with this tiny little computer. :)

Happy new year folks. I hope you had a good 2023, and hope this next one is even better. x

What does that mean?

Just to make sure we’ll all on the same page: Gleam is a type safe functional programming language that runs on the Erlang virtual machine alongside languages like Erlang, Elixir, and LFE. It was created by me, Louis Pilfold, and is also maintained by the Gleam core team.

The Erlang Ecosystem Foundation is a non-profit organisation that supports the BEAM ecosystem, including all languages and techonologies built upon the BEAM.

Exercism is a delighful platform for learning and practicing programming languages, incorporating lessons, automated challenges, and the option of feedback from mentors who know the language well. It has tracks for 67 languages, including 4 BEAM languages: Erlang, Elixir, LFE, and Gleam. Exercism is also entirely free to use!

Tracks on Exercism comprise a series of exercises students can use to practice a language, however some tracks also have a syllabus of lessons teach the language. Each language concept is carefully introduced and explained in an order that builds upon previous lessons, and each lesson has a set of exercises to practice the concept, taking the student from beginner to proficient and ready to solve real world problems.

What did we build?

Elixir’s syllabus is largely regarded as the gold standard for Exercism tracks, and it is the yard-stick we used when building the Gleam syllabus. The goal was to create a syllabus that would be as good as Elixir’s, and I think we’ve done it.

Before we could start working on the educational content we had to create a custom Gleam test runner which implements version 2 of the Exercism test runner interface. The creation of this runner also produced a set of libraries and significant improvements to existing Gleam libraries, including:

• Glexer, a Gleam tokenizer
• Glance, a Gleam parser
• Gap, a diffing library
• Simplifile, a file system library
• gleam_erlang, bindings to standard Erlang APIs

Work has also begun two other static analysis tools for Gleam, which will be later incorporated into Exercism to provide further automated feedback. They would also make a strong foundation for a generic Gleam linter that can be used by software development teams using Gleam.

Afterwards the language was divided into a set of concepts, and the concepts arranged into dependency order such that each concept builds upon the previous. The existing exercises were then assigned to the concepts, depending on what language features the student would likely need to know to solve the exercise.

As each concept lesson was written a corresponding exercise would be created alongside it. This exercise would be especially focused on the concept being taught, and is intended to solidify the student’s understanding, while not being too time consuming to solve.

The initial set of 12 concepts and 12 accompanying exercises were launched on the 4th of July, alongside the existing 92 exercises. Further concepts and exercises were added over the following months with the final being merged this morning on the 28th of September, bringing the track up to 36 concepts and 122 exercises. Gleam is now one of the most comprehensive tracks on Exercism, standing alongside Elixir!

Throughout the development period I and the other Gleam mentors have been offering feedback to students on their exercise submissions, and we will continue to do so into the future.

How was it received?

I am rather fond of keeping some stats, so I wrote a small Gleam script that scrapes the Exercism website once a day and records how much activity there was on the track for that day. Here’s a couple of charts:

Number of students

When the first concepts were launched the track had 474 students, and today there are 627 students. The rate at which students joined the course increased after the first concepts were launched in late July.

Number of exercise submissions

The impact of the concepts exercise is much more striking when looking at the number of exercise submissions by Gleam students, the rate greatly increasing after the first concepts were launched. Students are much more engaged with the material than before, spending more time with the track. Since the first concepts were launched there have been 6,936 exercise submissions.

Testimonials

As well as quantitative data I have asked students for feedback on the track, here are some of their responses:

I’m working through [the syllabus] at the moment and I’ve personally found them incredibly helpful for helping me focus on solidifying my understanding of specific concepts. The use of multiple examples for each concept helps round out my understanding of how things work a lot better than just reading docs, and having guided exercises that are focused purely on learning a concept at a time helps me gain traction a lot better than coding blindly

Exercism’s Gleam track helps make the language concepts stick, and therefore complements the official documentation really well. I love the fact that I can practice at my own pace and make a bit of progress every day. Even though I’ve barely scratched the surface of Gleam and the BEAM in general, I love where this is heading.

I’ve solved all of the concept exercises, and they were very enjoyable. I like that they’re not too challenging, so I didn’t get stuck on tiny details, but solving them still required me to know specific aspects of the language. I think the Gleam Exercism track will be crucial in the adoption of the language, and will bring more people with different programming backgrounds to the BEAM ecosystem

And here are some comments from students on their mentoring sessions:

Thanks for being really friendly and helpful, and taking the time to write out some really great explanation.

Thanks gain Louis, Gleam has excellent documentation, an excellent Exercism course and… a special mentor!

Thank you for taking time too help out. It was really helpful and a good explanation as to why a particular operator worked as it did.

This was my first mentoring session on Exercism. It will have a special place in my heart having had the creator stopping by and leave a nice word! Thanks 💜

He helped me to understand the language’s idiomatic expressions look like, and recommended ways to rethink the problem to fit more naturally in Gleam.

Yeah… thanks a lot.. I’ll be applying my learnings to the other exercises. I think it was good for me to study a bigger code example to get a feel for gleam !

He pointed out where I could improve the solution with built-in functions that expressed the code’s intent perfectly. This is helping me learn Gleam’s toolkit.

All the feedback has been very positive, and I’m very happy to see so many folks learning and joining the BEAM community.

Thanks!

I would like to thank the Erlang Ecosystem Foundation for supporting me in this work, the Exercism team for their guidance and help, and all the contributors who helped build the Gleam track. And extra special thank you goes to Jeremie Gillet, Erik Schierboom, and Giacomo Cavalieri for their outstanding contributions.

If you appreciate Gleam or Exercism please consider supporting the projects. Both are open source, entirely free to use, and rely on community sponsorship to continue development. Thank you.

• Exercism’s donation page
• Exercism on GitHub sponsors
• Gleam on GitHub sponsors

I’m going to show you how to set these two up together, so you can try it too. :)

I’ll assume you already have Elixir and Gleam installed. If you’ve not check out the documentation for Elixir and Gleam respectively. I’m using Elixir 1.14.2, Gleam 0.25.3, and Phoenix 1.6.15. If you have issues with any later versions let me know and I’ll update this post.

Hello, Joe!

First off we’re going to need a Phoenix application. You can use an existing one if you have one, but I’m going to create a new one.

# Create a new Phoenix app named `my_app`
mix archive.install hex phx_new
mix phx.new my_app

# Enter the project and setup the database
cd my_app
mix ecto.create

Next up we’re going to need a Gleam project too. In Phoenix projects the front end lives in the ./assets directory, so we’ll create it in there.

# Create a new Gleam project named `app`
gleam new assets/app

By default Gleam runs on the Erlang virtual machine, so we’ll need to tell it to compile to JavaScript instead.

Open up assets/app/gleam.toml and add target = "javascript".

name = "app"
version = "0.1.0"
target = "javascript" # <- Add this line

[dependencies]
gleam_stdlib = "~> 0.25"

[dev-dependencies]
gleeunit = "~> 0.7"

The entrypoint to the Gleam project is the main function in assets/app/src/app.gleam. It prints a greeting, which in this case will go to the browser’s developer console.

I’ve edited the greeting here to make it extra clear that the message is coming from the Gleam frontend.

import gleam/io

pub fn main() {
  io.println("Hello from the Gleam frontend!")
}

In a terminal window, run the Gleam build tool to compile Gleam code.

cd assets/app
gleam build
cd ../..

The Gleam code has been compiled to JavaScript, but unless it is included into the JavaScript bundle it won’t get run.

Open up the JavaScript file assets/js/app.js and at the bottom of the file import the compiled Gleam app module, calling its main function.

import { main } from "../app/build/dev/javascript/app/app.mjs";
main();

Now run the Phoenix server with mix phx.server and open up http://localhost:4000 in the browser. In the developer console there is the message “Hello from the Gleam frontend!”. Success! 💃

Automatic recompilation

We’ve got Gleam code now running in the browser, but having to manually run the compiler is annoying. What we really want is for the code to automatically be recompiled when edits are saved. To do this we’re going to take advantage of Phoenix’s development watchers feature.

By default Phoenix comes with one watcher that runs esbuild, a tool that bundles front end assets together for use in the browser. We’re going to add a second one that runs the Gleam compiler.

We’re going to need a way to detect when a Gleam file has changed, so add the file_system package to your mix.exs file.

  defp deps do
    [
      # ...other deps here...
      {:file_system, "~> 0.2", only: :dev}
    ]
  end

Add a new watcher for Gleam to config/dev.exs.

config :my_app, MyAppWeb.Endpoint,
  # ...other config here...
  watchers: [
    # ...other watchers here...
    gleam: {GleamBuilder, :start_link, []} # <- Add this entry
  ]

With this configuration when the application starts in dev mode Phoenix will call the start_link function on the GleamBuilder module, and that function will be responsible for building the Gleam code while the application is running.

Open up the lib/gleam_builder.ex file and enter the code below to define the new watcher.

# This watcher uses dev deps so let's only define it in dev to
# avoid warnings during compilation in production.
if Mix.env() == :dev do

  defmodule GleamBuilder do
    @gleam_dirs ["assets/app/src", "assets/app/test"]

    def start_link(_args \\ nil) do
      GenServer.start_link(__MODULE__, nil)
    end

    def init(_args) do
      # Watch for changes to Gleam files
      {:ok, pid} = FileSystem.start_link(dirs: @gleam_dirs)
      FileSystem.subscribe(pid)

      # Run the compiler once for the initial code
      run_gleam_compiler()
      {:ok, nil}
    end

    def handle_info({:file_event, _watcher, _event}, state) do
      # A Gleam file has changed, run the compiler
      run_gleam_compiler()
      {:noreply, state}
    end

    def run_gleam_compiler() do
      System.cmd("gleam", ["build"],
        cd: "assets/app",
        into: IO.stream(:stdio, :line),
        stderr_to_stdout: true
      )
    end
  end
end

Wow there’s a lot going on here!

The watcher is only used in :dev mode and uses development dependencies, so it would emit warnings if it were compiled in :prod mode. To avoid this we wrap the whole module definition in an if statement that checks the environment at compile time.

The watcher is an Elixir GenServer which is started by the start_link function.

In the init function it starts a FileSystem process for the Gleam code directories and then calls the FileSystem.subscribe/1 function in order to get notified with a message any time there are changes. It also runs the Gleam compiler once in init to build the code initially.

The handle_info function is called for each message from the FileSystem process. It runs the Gleam compiler again to rebuild the code with the just-saved changes.

And that’s it! If you start the Phoenix server again you’ll see the latest greeting get printed to the browser developer console each time you edit and save the assets/app/src/app.gleam file. Or any other Gleam file for that matter.

What’s next?

Now that the project is set up you probably want to start writing some Gleam code!

You could import and use some JavaScript DOM functions using Gleam’s external function feature, or you could build a more sophisticated React based front end using react-gleam or Lustre.

Whatever you do, have fun! Be sure to share anything cool that you make on the Gleam Discord server.

P.S. If you want to see all the changes I made to the Phoenix app check out this git commit.

Full disclosure, Fly.io are sponsoring my work on Gleam. I hadn’t used their platform prior to their sponsoring, but now that I have I believe that they have the best user experience of any deployment platform today, beating even my old favourite of Heroku.

I’ve already got Gleam, Erlang, and the Fly.io command line installed, logged in to Fly.io, and added a payment card to my Fly.io organisation. If you’re following along at home you’ll likely want to do these too.

Right. Let’s get started.

A Gleam web app

I’m going to need an application to deploy, so I’m going to quickly make a super basic one. First I create a new project and add the required dependencies.

gleam new pidgey
cd pidgey
gleam add mist gleam_http gleam_erlang

mist is a web server, and gleam_http and gleam_erlang provide helper types and functions for working with HTTP and the Erlang runtime respectively.

Next I’ll open up src/pidgey.gleam and write a tiny web application that always returns the body “Hello, Joe!”.

import mist
import gleam/io
import gleam/erlang
import gleam/bit_builder
import gleam/http/response.{Response}

pub fn main() {
  // Start the web server
  assert Ok(_) = mist.run_service(8080, web_service)

  // Put the main thread to sleep while the server works
  erlang.sleep_forever()
}

fn web_service(_request) {
  let body = bit_builder.from_string("Hello, Joe!")
  Response(200, [], body)
}

Now I can run it with gleam run, and test it out in another terminal with curl.

curl localhost:8080
# Hello, Joe!

Neat :)

Preparing to deploy

Fly.io has built in support for some languages but Gleam isn’t one of them, so I’ll have to use their docker support instead.

Within the Gleam project I create a file named Dockerfile with these contents.

FROM ghcr.io/gleam-lang/gleam:v0.22.0-erlang-alpine

# Add project code
COPY . /build/

# Compile the project
RUN cd /build \
  && gleam export erlang-shipment \
  && mv build/erlang-shipment /app \
  && rm -r /build

# Run the server
WORKDIR /app
ENTRYPOINT ["/app/entrypoint.sh"]
CMD ["run"]

If we were deploying a very large application we might want to add some caching, and we should probably create a new Linux user for the application to run as, but this is good enough for now. There’s lots of resources online for docker best practices if you’d like to know more, and I’ll probably make a more detailed example for Gleam in future.

Ship it!

Now to host the web app on Fly.io by running flyctl launch.

flyctl launch
# Creating app in /tmp/pidgey
# Scanning source code
# Detected a Dockerfile app
# ? App Name (leave blank to use an auto-generated name): pidgey
# ? Select organization: Louis Pilfold (personal)
# ? Select region: lhr (London, United Kingdom)
# Created app pidgey in organization personal
# Wrote config file fly.toml
# ? Would you like to setup a Postgresql database now? No
# ? Would you like to deploy now? Yes
# Deploying pidgey

The command asks a few questions:

• What should the app be named?
• What organisation should it belong to?
• Which region should it be deployed to?
• Should a PostgreSQL database also be deployed?
• Should the app be deployed now?

After this it builds the application using the docker file, and within a minute the application is live! To open it in a web browser I run flyctl open.

To deploy future versions of the application I can run flyctl deploy after saving my changes.

And that’s it. I’m really impressed with Fly.io and I expect I’ll be using them to host all my Gleam web applications going forward. Give them a try, I think you’ll like their platform.

Happy hacking!

Big clouds like AWS and GCP are powerful but are also intimidating, and they provide many exciting new ways to blow your feet off and empty your bank account if you make a mistake.

I’m rather fond of more straightforward virtual server providers such as DigitalOcean and Linode, but setting up a deployment with just a Linux box and an SSH connection is a bit involved. I suspect most people don’t enjoy wrangling hacky little deployment scripts as much as I do.

This leaves us with the various different platform as a service offerings which promise to automated the entire deployment process. In the past I’ve used Heroku, Render, DigitalOcean Apps, and a few others that no longer exist, but none of them really stand out to me as the obvious choice. I need to try some more.

Rather serendipitously fly.io (a nifty looking platform as a service) has just started sponsoring Gleam, so that seems like a good place to start. In this blog I’ll take the tiny Gleam echo server example project and see how quickly I can get it running on fly.io. As I write this I’ve had a quick scan over the website, but otherwise I’m completely new to the platform.

Note- While I picked fly.io first because they started sponsoring Gleam, they’re not paying me to write this and I’m going to be honest with my experience. Although if it’s really bad I’ll probably just quietly delete this post rather than publishing it… But then you are reading this in the future after it has been published, so I guess it went ok!

Alright, let’s go.

Getting started

The homepage has a big “Get Started” button that takes me to a page showing me how to install their CLI and register with it. I’m using a mac computer here, but they’ve similar looking commands for Windows and Linux too.

brew install superfly/tap/flyctl
flyctl auth signup # This opens a browser tab...

I opt for GitHub single sign on (rather than username/password), it authenticates the CLI, and the browser tab takes me to a documentation page with links a few different first-steps options. One is “introduction”, which offers more background on the platform. One is “the speedrun”, for folks who are familiar with docker etc and wish to get going quickly, and one is a more “hands on” piece of step by step learning.

This choose-your-own adventure style onboarding seems rather clever, they don’t have to try and write one tutorial that works for everybody. I might have to keep this in mind when working on Gleam’s onboarding.

Right. I want to be a speedrunner. let’s see how that goes.

click

Whoa, they were not joking when they said get going fast. This is a page with 2 lines of text, a list of 6 steps, and a rather lovely picture of a hot air balloon. There’s not even a scroll-bar.

I’ve already done steps 1 and 2 (see above), and step 6 is “your app is now running”, so really it’s just 3 steps.

flyctl launch
flyctl info
flyctl open

Apparently if I’m familiar with docker this’ll be enough. I’m a little skeptical. Let’s see how I can mess this up.

I’ll start by adding a Dockerfile

I run flyctl launch and up pops a little multiple-choice quiz. It’s quite slick for a terminal program. It also prints this:

Could not find a Dockerfile, nor detect a runtime or framework from source code. Continuing with a blank app.

Gleam’s too new to have built-in support, so I better ctrl-c this quiz and add a Dockerfile.

FROM ghcr.io/gleam-lang/gleam:v0.19.0-erlang-alpine

# Create a group and user to run as
RUN addgroup -S echogroup && adduser -S echouser -G echogroup
USER echouser

# Add app code
WORKDIR /app/
COPY . ./

# Compile the app and set the entrypoint
RUN gleam build
CMD ["gleam", "run"]

That’ll do. It’s only a tiny app so no need to worry about caching or other fancier docker features.

On with the flyctl launch quiz.

1. Application name. “gleam-echo” will do.
2. Region. I pick London.

ERROR We need your payment information to continue!

That’s a reasonable requirement, but I feel that could have been mentioned earlier, and not with a sudden bright red error message.

I click the link in the error message, put my card details in the Stripe form that opens in a browser window, and try flyctl launch again.

1. Application name. “gleam-echo”.
2. Region. London.
3. Would you like to deploy now? You bet I do.

After a few seconds waiting it connects to a server somewhere and starts building the OCI image using the Dockerfile. I’m impressed! I was sure it was going to build locally and crash as it’s an amd64 image and I’m using an ARM computer.

It pushes the image to their image registry, deploys the app instance, and waits for health checks to pass. It seems to be hanging forever…

I guess the command flyctl logs and it works, I get the app logs, and I can see the application has started. That’s good, it’s not crashing, that makes me think it’s a configuration issue.

I open the documentation site and spot a page in the sidebar called “Run a Go App”. Go is easy to read, so hopefully I can spot anything I’m lacking there. Near the top of the page they have the source code for the tiny Go app.

package main

import (
    "embed"
    "html/template"
    "log"
    "net/http"
    "os"
)

//go:embed templates/*
var resources embed.FS

var t = template.Must(template.ParseFS(resources, "templates/*"))

func main() {
    port := os.Getenv("PORT")
    if port == "" {
        port = "8080"
    }

    http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
        data := map[string]string{
            "Region": os.Getenv("FLY_REGION"),
        }

        t.ExecuteTemplate(w, "index.html.tmpl", data)
    })

    log.Println("listening on", port)
    log.Fatal(http.ListenAndServe(":"+port, nil))
}

Can you see what I see?

  port := os.Getenv("PORT")
  if port == "" {
      port = "8080"
  }

My Gleam app doesn’t read the PORT environment variable. I better add that.

let port =
  os.get_env("PORT")
  |> result.then(int.parse)
  |> result.unwrap(3000)

Nope, no dice. It still hangs, and in the logs the app prints that it is using the same port 3000 as before, so that variable must not have been set.

I open the fly.toml file which has been written into the project by the flyctl launch command. It contains about 40 lines of configuration, including this:

[[services]]
  http_checks = []
  internal_port = 8080 # <-- Aha!
  processes = ["app"]
  protocol = "tcp"
  script_checks = []

This time it works! 52 seconds from start to deployment complete, including the time it took to build and upload the the OCI image. That’s a lot faster than my experiments with Heroku and DigitalOcean Apps.

I run steps 5 and 6 from the speedrun guide.

flyctl info prints some basic information about the deployment. Release number, hostname, ports exposed, that sort of thing. Potentially useful but nothing overly exciting.

Running flyctl open opens a new browser tab with the app running. Pretty cool! And it feels very snappy and has TLS too on the hostname gleam-echo.fly.dev.

Lastly let’s teardown the application. In the output of flyctl --help I spot a destroy command, and running flyctl destroy gleam-echo deletes the deployment (after a quick “are you sure?” check).

First impressions

I’m impressed! There’s clearly some bits that are not as slick as they could be, but the level of polish otherwise gives me confidence that any rough patches will be worked out over time.

Even with the port problem it didn’t take me long to get it live, and I’ve certainly been more stressed trying to get an application running on Heroku using docker.

If I were to suggest some improvements they would be:

1. Mention at the start of the speedrun guide that you need to have a dockerfile or to be using one of the supported languages.
2. Ask for the credit card information earlier in the process rather than when you think the application is about to deploy, and don’t ask for it with big red ERROR text.
3. Ask what port the application is listening on during the flyctl launch quiz.

I think I’m going to have to test out fly.io a lot more ✨

Postscript: hitting a bug

For fun I tried the same thing again on a Linux box, but ran into a show-stopping bug where flyctl launch couldn’t connect to the build server. I think this is because the generated hostname of this Linux box I’m using has an underscore in it. I’ve reported this to fly.io, we’ll see how quickly it gets resolved.

Record update syntax

Previously when we wanted to update some of the fields on the record we would need to create a new instance and manually copy across the fields that have not changed.

pub fn level_up(pokemon: Pokemon) {
  let new_level = pokemon.level + 1
  let new_moves = moves_for(pokemon.species, new_level)
  Pokemon(
    level: new_level,
    moves: new_moves,
    name: pokemon.name,
    species: pokemon.species,
    item: pokemon.item,
  )
}

This is quite verbose! Worse, it’s error prone and annoying to type every time.

To remedy this problem Quinn Wilton has added the record update syntax to Gleam, so now we only need to specify the fields that change.

pub fn level_up(pokemon: Pokemon) {
  let new_level = pokemon.level + 1
  let new_moves = moves_for(pokemon.species, new_level)
  Pokemon(..pokemon, level: new_level, moves: new_moves)
}

All data in Gleam is immutable, so this syntax does not alter the values of the existing record, instead it creates a new record with the original values and the updated values.

Numbers

Tom Whatmore has added some new features to Gleam’s numbers.

There’s now syntaxes for binary, octal, and hexadecimal int literals.

// 4 ways of writing the int 15
let hexadecimal = 0xF
let decimal = 15
let octal = 0o17
let binary = 0b00001111

These might be handy in many situations such as when implementing a virtual machine or a game of tetris in Gleam.

Underscores can now be added to numbers, making larger numbers easier to read.

let billion = 1_000_000_000
let trillion_and_change = 1_000_000_000_000.57

Type holes

Type holes can be used to give partial annotations to values.

Here we’re saying that x is a List, but we’re not saying what type the list contains, leaving the compiler to infer it.

let x: List(_) = run()

This may be useful when adding annotations for documentation or to use a more restrictive type than would be inferred by the compiler, as you can leave out any parts of the annotation that are not important to you there.

Compiler improvements

The majority of the compiler work in this release has been improvements to existing features.

The formatter style has been improved in several ways, and the performance of the formatter has been improved. One popular change is to how it formats assignments that don’t fit on a single line.

// Before
assert Ok(
  tuple(user, session),
) = application_registry.get_session(request.user_id)

// Now
assert Ok(tuple(user, session)) =
  application_registry.get_session(request.user_id)

Much better!

Additionally several error messages have been improved to include more information on how to fix the problem, and a whole bunch of bug have been squashed. Please see the changelog for more detail.

HTTP

Outside of the compiler the big new thing in Gleam is the first release of Gleam HTTP. Inspired by existing libraries such as Ruby’s Rack, Elixir’s Raxx, and Haskell’s WAI, Gleam HTTP provides a single well-typed interface for creating web applications and clients while keeping the underlying HTTP client and server code modular.

In Gleam a HTTP service is a regular function that takes a HTTP request and returns a HTTP response, where request and response are types defined by the HTTP library.

Services

Here’s a simplistic service that echoes back any body sent to it.

import gleam/http.{Request}

pub fn echo_service(request: Request(_)) {
  http.response(200)
  |> http.set_resp_body(request.body)
}

As a normal Gleam function it is easy to test this service, no special test helpers or test server are required.

import gleam/should
import my_app

pub fn echo_test() {
  let response =
    http.default_req()
    |> http.set_req_body("Hello, world!")
    |> my_app.service

  response.status
  |> should.equal(200)

  response.body
  |> should.equal("Hello, world!")
}

Gleam’s HTTP library also provides middleware, which can be used to add additional functionality to a HTTP service.

import gleam/bit_builder
import gleam/http/middleware

pub fn service() {
  my_app.echo_service
  // Add a header
  |> middleware.prepend_resp_header("made-with", "Gleam")
  // Convert the response body type
  |> middleware.map_resp_body(bit_builder.from_bit_string)
  // Support PATCH, PUT, and DELETE from browsers
  |> middleware.method_override
}

Running a service

Once we have defined a service we want to run the service with a web server so that it can handle HTTP requests from the outside world. To do this we use a HTTP server adapter, such as one for the Elli Erlang web server.

import my_app
import gleam/http/elli

pub fn start() {
  elli.start(my_app.service, on_port: 4000)
}

Or one for the Cowboy Erlang web server.

import my_app
import gleam/http/cowboy

pub fn start() {
  cowboy.start(my_app.service, on_port: 4000)
}

Or even using the adapter for the Elixir’s Plug interface, so that a Gleam HTTP service can be mounted within an Elixir Phoenix web application.

defmodule MyAppWeb.UserController do
  use MyAppWeb, :controller

  def show(conn, params) do
    conn
    |> GleamPlug.call_service(params, &:my_app.service/1)
  end
end

A list of all available server adapters can be found in the Gleam HTTP project’s README.

If you would like to see more examples of Gleam HTTP being used to create a web application see the echo server on GitHub. It includes all the above as well as other concepts such as routing and logging.

HTTP clients

HTTP services are only half the story! We also can use the HTTP library to make out own requests.

import gleam/http
import gleam/httpc

pub fn get_my_ip() {
  try response =
    http.default_req()
    |> http.set_method(http.Get)
    |> http.set_host("api.ipify.org")
    |> httpc.send
  Ok(response.body)
}

Here we’ve build a HTTP request and sent it using the httpc client adapter, returning the response body if the request is successful.

A list of all available client adapters can be found in the Gleam HTTP project’s README.

Try it out

If you want to try out the new version of Gleam head over to the installation page. I’d love to hear how you find it and get your feedback so Gleam can continue to improve.

Want to view some existing Gleam projects? Head on over to the awesome-gleam list. Looking for something to build in Gleam? Check out the suggestions tracker.

Supporting Gleam

If you would like to help make strongly typed programming on the Erlang virtual machine a production-ready reality please consider sponsoring Gleam via the GitHub Sponsors program.

This release would not have been possible without the support of all the people who have sponsored and contributed to it, so a huge thank you to them.

Lastly, a huge thank you to the contributors to and sponsors of Gleam since last release!

• Adam Bowen
• Adam Mokan
• Ahmad Sattar
• Al Dee
• Arian Daneshvar
• Arno Dirlam
• Ben Myles
• Bruno Dusausoy
• Bruno Michel
• Bryan Paxton
• Chris Young
• Christian Meunier
• Christian Wesselhoeft
• Connor Schembor
• Dave Lucia
• David McKay
• delucks
• Eric Meadows-Jönsson
• Erik Terpstra
• Gary Rennie
• Graeme Coupar
• Guilherme Pasqualino
• Hasan YILDIZ
• Hendrik Richter
• Herdy Handoko
• Ingmar Gagen
• Ivar Vong
• James MacAulay
• Jechol Lee
• John Palgut
• José Valim
• Clever Bunny LTD
• Lars Lillo Ulvestad
• Lars Wikman
• Leandro Cesquini Pereira
• Mario Vellandi
• mario
• Markus
• Matthew Cheely
• Michael Jones
• Mike Roach
• Milad
• ontofractal
• Parker Selbert
• Peter Saxton
• Quinn Wilton
• Raphael Megzari
• Robin Mattheussen
• Sam Aaron
• Santi Lertsumran
• Sasan Hezarkhani
• Sascha Wolf
• Saša Jurić
• Sean Jensen-Grey
• Sebastian Porto
• Shane Sveller
• Shritesh Bhattarai
• Simone Vittori
• Tim Buchwaldt
• Tom Whatmore
• Tristan Sloughter
• Tyler Wilcock
• Wojtek Mach

Thanks for reading! Have fun! 💜

Module constants

Sometimes we want to use a certain fixed value in multiple places in our project. Until now we’ve had two options. The first option was to copy and paste the value into multiple places in our code.

pub fn is_before(year: Int) -> Bool {
  year < 2101
}

pub fn is_during(year: Int) -> Bool {
  2101 <= year && year <= 2111
}

Duplication of values like this is error prone, especially if we want to update the values later, as we’ll need to find every place it’s used in order to change it.

Another option is to wrap the value in a function.

pub fn start_year() -> Int {
  2101
}

pub fn end_year() -> Int {
  2111
}

pub fn is_before(year: Int) -> Bool {
  year < start_year()
}

pub fn is_during(year: Int) -> Bool {
  start_year() <= year && year <= end_year()
}

This is better than copying the value in our code, but isn’t yet ideal. A function can perform any amount of computation (with side effects!) when it is called, so we have to read the definition of the function to be sure what it does.

To make matters worse Gleam’s case clause guards don’t support calling of functions within them, so this code will be rejected by the compiler:

pub describe(year: Int) -> String {
  case year {
    year if year < start_year() -> "Before"
    year if year > end_year() -> "After"
    _ -> "During"
  }
}

To solve all these problems Gleam now has module constants. They are always inlined by the compiler, and can be used in case clause guards.

Using them the above code can be rewritten like so:

pub const start_year: Int = 2101
pub const end_year: Int = 2111

pub fn is_before(year: Int) -> Bool {
  year < start_year
}

pub fn is_during(year: Int) -> Bool {
  start_year <= year && year <= end_year
}

pub describe(year: Int) -> String {
  case year {
    year if year < start_year -> "Before"
    year if year > end_year -> "After"
    _ -> "During"
  }
}

Much better! Module constants are going to provide the basis of some exciting new features in future, so watch this space. 🚀

Thanks to Ahmad Sattar for taking the lead in the implementation of this feature.

Bit string syntax

One of great things about Erlang is how easy it is to work with raw bits and bytes using the bit string literal syntax. Starting with this release Gleam supports this too!

Explaining all the things one can do with the bit string syntax would take longer than I have now, but in short they give a declarative way of constructing and parsing raw data of any format. What’s more the Erlang VM is highly optimised for this, so bit syntax is highly efficient too!

For example, if I wanted to create a 32 bit unsigned little endian integer with the value of 100 I could do so using bit syntax like this:

let my_integer = <<100:unsigned-little-int-size(32)>>

Or if I wanted to extract the title, artist, album, year, and comment from an MP3 music file’s ID3 tags I could pattern match on it like this:

pub fn get_metadata(id3: BitString) -> Result(Metadata, String) {
  case id3 {
    <<
      "TAG":utf8,
      title:binary-size(30),
      artist:binary-size(30),
      album:binary-size(30),
      year:binary-size(4),
      comment:binary-size(30),
      _rest:binary,
    >> -> Ok(Metadata(title, artist, album, year, comment))

    _ -> Error("Not a valid ID3 tag")
  }
}

Thanks to Benjamin Tan’s blog post for this example.

For another example of bit syntax in action check out this very serious base64 encoding alternative which converts arbitrary data into emojis!

As part of this new feature we have introduced BitString and UtfCodepoint types into the prelude, and split the standard library Iodata type into StringBuilder and BitBuilder types, which are for efficiently constructing strings and bit strings respectively.

Thanks to Tom Whatmore for taking the lead in the implementation of this feature.

The rest

There are many more new additions, improvements, and bug fixes to the compiler and the standard library, including but not limited to support for regex expressions (implemented by Erik Terpstra) and environment variables (implemented by Peter Saxton).

For information on the rest in this release please check out the Gleam changelog and the standard library changelog.

Supporting Gleam

If you would like to help make strongly typed programming on the Erlang virtual machine a production-ready reality please consider sponsoring Gleam via the GitHub Sponsors program.

This release would not have been possible without the support of all the people who have sponsored and contributed to it, so a huge thank you to them.

• Adelar da Silva Queiróz
• Ahmad Sattar
• Al Dee
• Arian Daneshvar
• Arno Dirlam
• Ben Myles
• Bruno Dusausoy
• Bruno Michel
• Bryan Paxton
• Chris Young
• Christian Meunier
• Christian Wesselhoeft
• Clever Bunny LTD
• Dave Lucia
• David McKay
• Dym Sohin
• Erik Terpstra
• Gustavo Martins
• Hasan YILDIZ
• Hendrik Richter
• hindenbug
• Hécate
• James MacAulay
• Jan-Erik Rediger
• John Palgut
• José Valim
• Kasim Tuman
• Lars Wikman
• Leandro Cesquini Pereira
• Mario Vellandi
• mario
• Michael Jones
• Mike Roach
• ontofractal
• Parker Selbert
• Peter Saxton
• Quinn Wilton
• Robin Mattheussen
• Sasan Hezarkhani
• Sascha Wolf
• Sasha
• Saša Jurić
• Sean Jensen-Grey
• Sebastian Porto
• Shayne Tremblay
• Shritesh Bhattarai
• Simone Vittori
• Tom Whatmore
• Tristan Sloughter
• Tyler Wilcock
• Wojtek Mach

Thanks for reading! Have fun! 💜