Colas.Nahaboo.net - go

gmail-to-fastmail: keep your Gmail labels in sync on Fastmail

2026-08-03T00:00:00+00:00

I moved to Fastmail some time ago, but like many of us I kept one foot in Gmail: Fastmail's "fetch" tool keeps duplicating my incoming Gmail into my Fastmail account — a backup, an escape plan, and a bridge for family members who are not quite ready to leave Gmail yet.

But there was a hole: the labels I add on Gmail after the initial migration (manually, or with my rules) were never reproduced on Fastmail. So I wrote gmail-to-fastmail, a single Go binary that incrementally syncs your Gmail labels to Fastmail.

How it works🔗

It reads your Gmail via IMAP (read-only, X-GM-LABELS), and applies the labels on Fastmail via JMAP (a more efficient variant of IMAP), in batches of 10 000. Progress is kept in a local SQLite database, so each run resumes where the last one stopped — once caught up, a run takes about 15 seconds. Perfect for cron.

What it does🔗

Labels mapped: your Gmail labels become Fastmail labels, created on demand, never deleted.
Categories: Gmail's system categories (Inbox, Updates, Social...) become underscore-prefixed labels _Inbox, _Updates, _Social...
Trash: emails deleted on Gmail are not deleted on Fastmail, just labelled _Trash — a backup of your deleted mail, with an easy way to "empty the bin".
Local cache: unchanged emails are skipped, so Fastmail's API is left in peace.
Mirror mode: -m/-M optionally imports emails missing on Fastmail, not just labels. There are more options, detailed on the GitGub repository.

Installation, Usage, and more info🔗

See the GitHub repository.

Why Go?🔗

Because it is a single self-contained binary with no runtime dependencies — you know my thing about that. No Python env, no node_modules, no nothing. Free (MIT).

Also, AI co-written: don't like, don't use.

Fanatic of the single self-contained executable

2026-07-31T00:00:00+00:00

I am becoming more and more a fanatic of the single self-contained executable, with no runtime dependencies, that Go provides: one binary, forever. No npm, virtualenv, docker, flatpak, snap... no version hell.

The qualities I lived with and took for granted during my years of coding in C and shell.

To the point that when I find now a python/node/java/ruby/php piece of software I would like to install, my first reflex is to just recode the darn thing in Go. I know, I know, rewriting a perfectly working piece of software just to avoid a dependency is bordering on insanity, but the result is so satisfying... A single file that will still run in 20 years, with no upgrades, no breakage, no maintenance.

And with AI, now, it is becoming less and less insane!

(Bluepost )

Suntimes, a small shell utility

2022-03-03T00:00:00+00:00

I just made a small command-line utility to display the sunrise and sunset times at a location. It can be quite useful in shell scripts.

It is a minimal Go wrapper around the nathan-osman/go-sunrise library

You can find it at my repository: GitHub - ColasNahaboo/suntimes

Completed the 2015 Advent of Code challenge in GO

2022-02-24T00:00:00+00:00

And I completed the 2015 challenge! (see my previous post). You can read my notes on it on my GitHub.

This was quite interesting, and I thing a great way to learn a language just after completing its tutorial, as this challenge as a feel of "real life" situations, and allow for a variety of solutions, so that you can put different approaches to the test.

I forced myself to not look at the solutions available on the net, except for two cases:

Using working code to generate more data to test against (random inputs + expected result number). I just ran the code of other solutions, without reading their source. I often used solutions by devjobe and schwern.
Once I had a working solution, browsing the source code of other solutions to compare with mine and see where I could improve, and discover cool tricks. I mostly used the reddit megathread.

I also tried to use only the standard Go packages, and not the ones available on the web. I am sure I will end up using 3rd party packages to replace the standard ones (the flag package to parse options for instance is really too primitive). And I also didn't create a separate module or package for my library of common useful functions. I will surely do it in the future, but I feel I should have more experience first.

Anyways, it has confirmed that Go was the language I have been waiting for all these years. On the one hand, I have a bit of regret not having jumped on it sooner, but on the other hand it was easier to just wait for my retirement (one year ago) to free myself from any work politics and constraints to be able to fully explore the programming language landscape with no strings attached.

I can see myself using 4 languages in the future:

bash for any "glue" tooling and scripts.
go for my main do-it-all language, and web backend.
javascript (and/or WebAssembly) for my web frontend, with pure modern HTML and CSS, but no framework, à la Vanilla JS.
and maybe a higher performance, specialized language, if I encounter such needs: E.g: zig as a replacement of C for tasks where Go could be unsuited (if I encounter any), or julia for math-specific things, etc...

Edit: I see that Neil Henning also enjoyed discovering a new language via AoC: A Review of the Zig Programming Language (using Advent of Code 2021)

Starting the 2015 Advent of Code challenge in GO

2022-02-09T00:00:00+00:00

I discovered the advent of code in 2021, and did it in bash for the challenge. But since I started learning GO, I decided to code the previous AoC years in GO as a mean to practice it. So, although my bash code can be useful to see some tricks of a seasoned bash programmer, these GO solutions must be considered as "student code".

So I started coding the 2015 year of AoC in GO, available on my GitHub: advent-of-code-my-solutions/go/2015

The code is in GO, with some housekeeping scripts in bash.