I don’t exactly know when it started. I always had this itch to learn more about the *BSD operating systems (at least one of the big three: FreeBSD, OpenBSD, and NetBSD), but it never actually materialized properly:

“Linux is basically the same thing, and it works just fine”

“I have been using Ubuntu and Debian derivatives for years, no need to change”

“Then something won’t work, and I will spend days trying to figure it out”

Things like that.

Then this happened:

I realize that some people really dislike AI, but this is an area where I’m willing to absolutely put my foot down as the top-level maintainer.

Linux is not one of those anti-AI projects, and if somebody has issues with that, they can do the open-source thing and fork it.

Or just walk away.

AI is a tool, just like other tools we use. And it’s clearly a useful one.

Typical, textbook Linus. It’s not the first time that he decided to put his foot down, and probably not the last. Still, openly allowing slop in the Linux kernel? That didn’t feel right. That felt definitely worse than GCC’s AI Policy which declines legally significant AI contributions (but allows them for test cases, go figure).

Over the past few months, I have been thinking a lot about AI, what it means for mankind in general, and the IT world in particular. And well, long story short, I came to the conclusion that the world would probably be better without it.

Needless to say, I didn’t feel comfortable using Linux anymore. And for the record, it does suck that I have to worry about the political implications of software, but I learnt from my fellow Mervfolk that sadly, there is no such thing as apolitical software: software, like everything else, has a political aspect to it, which must be taken into account.

I won’t lie: I work for a big multinational company which – like almost all multinational companies – ends up making questionable choices at times. But at least I felt that I could question what software and operating systems I use in my (very limited) free time: I recently purchased an EeePC that was manufactured in 2011, and I originally put AntiX Linux on it. Now, as far as Linux goes, that is probably the most anti-corporate, anti-fascist distros there is… but sadly, what’s the good of that if it is built on top of slopware?

(Net)BSD is the new Linux ⇈

I looked around, and I (re-)discovered that BSD-based operating systems (FreeBSD, NetBSD, and OpenBSD) are now one of the last true strongholds (at least operating system wise) of Free Software that is also taking an active stance against the rise of AI (NetBSD in particular).

So… well, long story short, I decided to install NetBSD on my old EeePC. I had used FreeBSD in the past (probably 20 years ago), but I felt it was more geared towards user-friendliness and Linux compatibility. I had never tried NetBSD or OpenBSD, so I decided to go for NetBSD for my EeePC.

The installation felt refreshingly low-tech (it’s fully text-baseed), and in less than half an hour I had a fully-functional NetBSD system running on my EeePC.

Of course it runs NetBSD – that’s one of the slogan of this popular BSD variant, and what made me choose it for my old 2011 hardware.

Of course it didn’t just work_™: WiFi didn’t, for example, and I had to dig up how to get wpa_supplicant to work and get me on the Internet. I knew about it from when I experimented with more bare-bones Linux distros in the ‘00s, so I got that working relatively quickly.

The one thing that struck me (in a good way) about NetBSD was how simple and bare-bones everything was: I had to manually edit the /etc/rc.conf file to configure services to run at startup, and I deliberately choose not to immediately switch to a graphical environment at boot: sometimes you just want to be productive with he command line, so I configured things so that I had to manually run startx if I wanted a graphical environment.

I also rediscovered the orderly pleasure of a very organized file system: an /etc directory for all configuration files, /usr for user-installed programs, /var for (mostly-)temporary system data, and so on. OK, they are on Linux as well, but on BSD this structure definitely felt more mandated and consistent, with the result that you would always know where to look for something.

For the first time in a good while, I felt I had full control over my operating system: I had the power to decide how it behaved, which window manager to use, and which application to use to browse the filesystem or the Internet: I was experiencing true personal compiting.

In the end, I chose JWM (Joe’s Window Manager) because it felt like a good compromise between an absolute bare-bones environment (like cwm) and fancier stuff like XFCE or Gnome: I had full control over what to put in my menus, and which widget to use to display battery usage, and which icon theme to go for. It turns out that I really love early ‘00s aesthetic (not surprising, being a Millennial myself), and the Tango icon set was enough for my needs.

In just a couple of days, I had a fully-functional, minimalist, utilitarian, NetBSD-powered desktop environment. And that only took a few hours of my precious free laptop time! And it was definitely time well-spent.

Back in the day, installing Slackware or Gentoo felt liberating. Now, I experienced exactly the same feeling installing NetBSD: in that way, I feel very much that BSD is the new Linux.

OpenBSD: a new era for my VPS ⇈

The other obvious Linux system I have been using for the last 10+ years was the Ubuntu LTS installed on my Digital Ocean VPS.

Ten years ago, Digital Ocean was the VPS provider to choose: it was (relatively) small, had wonderful documentation to get started, a good web UI to manage things like DNS and backups, they were cheap enough, and they were the hacker’s choice when it came to small VPSs.

Fast-forward to 2026, and the same company pivoted into becoming a mainstream cloud and AI provider. I always disliked The Cloud for my personal projects, nevermind AI! Still, I had been using the same droplet for over ten years, it was working well enough, and above all changing VPS would have meant spending a substantial amount of time migrating everything to a new host – not something I could have pulled it off now, with a full-time job, a wife, and two small children!

I tried not to log on too often from the now-redesigned, slopified, Digital Ocean home page, and carried on. Then… the final straw came when the same company I once trusted decided to pledge $3M to Omarchy, DHH’s latest questionable endeavor.

Quick recap: even though back in 2005 I admired David Heinemeier Hansson for creating Ruby on Rails, easily the most revolutionary web framework of the last thirthy years… it seems that he now suddenly turned fascist and expressed his own very questionable opinions on… ethnic cleansing in the UK. Like, for Heaven’s sake, you cannot trust anyone these days, can you?

So… with my newfound political awareness, I decided that this was enough for me, and just over a week ago signed up for a new VM at OpenBSD.Amsterdam.

I had heard literally only good things about this small, niche, opinionated, European hosting provider from my fellow Mervfolks, and I was itching to try it out, even though I had never used OpenBSD before. So one night, just after my little nine-month-old decided to wake me up at around 2am, I decided to impulsively sign up and request a 50GB disk, 2GB RAM machine for… huh… 81€/year! That was much cheaper than the 25€/month I was currently paying for Digital Ocean anyway.

When I woke up in the morning, I was surprised to find an email by this Misha guy in my personal inbox saying that I could just ssh into my new OpenBSD VM at a specific IP address. I was like oh f***! and I didn’t even pay for it yet!

So huh… well, I guess I did try to log on into the new machine using the SSH key I provided at sign up but… it didn’t work. Darn. That was embarrassing: I had this petulant voice in my head going I told you so, you can’t even manage to log in, nevermind migrating 18 domains, subdomains, and apps!

Well, there was no way around it: I just couldn’t log in with the key I provided, so I decided to reply to that automated response of that Misha guy providing the same public SSH key again, hoping to get some sort of assistance.

Sure enough, five minutes afterwards Misha emails me back saying that I originally had an extra space in the public key I provided, and that I could give it another try.

Well… what can I say? Surely a sleep-deprived father-of-two can make mistake and type the wrong key when copying and pasting from his phone in the middle of the night!

After the initial amazement derived from the fact that I had just received a mail from an actual, helpful human being, I managed to connect to the VM and started inspecting things: it seemed to be real!

Let’s recap a second: it’s 2026 and half the world is loosing their s***t (and money, and brains) for some sycophantic machines, and I get a mail from a real human being helping me, and giving me access to a real OpenBSD VM in Amsterdam, even if I didn’t even pay for it yet? That was pure insanity. But good insanity.

“Honey? Did they clone your card or are you really sending 80€ to some dude in Amsterdam?”

…That was my wife reacting to an alert on her phone (shared bank account… a blessing and a course!)

Well, I did pay that dude in Amsterdam. That turned out to be 81€ well-spent.

Down the rabbit hole ⇈

That was it: I had just paid for my new VPS for a year. My wife was happy as I told her this would have ultimately saved us money, and now I had no choice but… migrating all my stuff to OpenBSD Amsterdam.

Coming from a few days on NetBSD, OpenBSD felt like something slightly more polished and optimized for networking. I quickly learnt the joy (well, kinda) of having a lot of network stuff chrooted for improved security, but, after the initial shock, I managed to get the hang of it pretty quickly.

I made the deliberate choice not to replicate my former Linux VPS, except maybe for using Nginx instead of httpd (I have quite a lot of weird reverse-proxied stuff), and chose to stick to the official base system and packages as much as possible. The first thing I decided was to actually use vi for all the text editing. Yes, you read it right: that’s vi (actually nvi), not Vim, nit NeoVim: just the original editor from the 70s: no syntax highlighting, no visual mode, no huge .vimrc, and a backspace that works in the weirdest way (it turns out backspace in vi can only delete characters that you have typed yourself, not pre-existing characters) – but damn it felt nice: simple, but very powerful.

The next thing I tried was compiling some of my core ecosystem projects. Most of the stuff I use is built in Nim, and luckily, it runs just fine on OpenBSD: there’s even a package for Nim itself (although an older version)! I only had to make a few minimal changes to my code here and there, but everything worked smoothly. I then learnt to appreciate the simplicity of rcctl – it felt much simpler to manage than systemd for managing daemons.

After a few hours hacking away with this new operating system, I genuinely felt I could actually pull it off: I made a checklist of each app or web site to migrate (eighteen of them!), and started going through… Some of them, like my statically-generated sites, were straightforward enough, other things (like my NextCloud instance) were not, but in the end I managed fine: I was actually able to migrate everything, one vi-edited config file at a time, and most importantly I genuinely felt I was learning something new and useful in the process!

Back to basics ⇈

The two things that also scared me were 1) managing and migrating all the DNS configuration I had in Digital Ocean, and 2) managing my own backups. Digital Ocean spoiled me with their easy-to-use UI for these things, so I was a bit lost initially.

The DNS part turned out to be easy enough: Following @alderwick’s advice, I signed up for Hurricane Electric DNS, a free DNS provider, and slowly transcribed my entire DNS configuration, record by record. Soon I realized I could just change the DNS provider and point to the old DNS droplet, and then migrate a particular app or web site and change the DNS to point to the new VPS: zero downtime!

Backups took a little bit more of researching, but in the end I settled with Restic: it seems to be one of the easiest things to configure for this, and it works very well with the remote backup storage of 10GB that OpenBSD Amsterdam gives you with every VM.

Conclusion ⇈

For the first time in a good while, I feel like I am back in control: I understand how my system works, I can tweak it and tailor it to my needs.

After just over a week, I was able to turn off my Digital Ocean droplet and enjoy all my personal projects running from a human-friendly, European, VPS provider! And I am happy to report things are running much more smoothly, using less RAM and CPU.

I really hope that OpenBSD Amsterdam carries on their stellar work… I am extremely happy about my choice, and my only regret is that I didn’t do this sooner!

Over the past few months I have been thinking about changing a few things related to this web site and my projects. With the rise of AI slop and overwhelming bloat throughout the Internet, I have been longing for more simplicity and lightness in my digital life.

Eee… ⇈

So, for my last birthday, I bought myself a nice, fully functional, EeePC! It’s an 1001PXD model from 2011 with a nice 233GB SATA hard drive, a (32bit) Atom processor and (wow!) 2GB of RAM. That was for 40€ mind, including shipping. Not bad at all.

I immediately installed AntiX, which is an excellent Debian-based distro for older hardware. In retrospect, I could have installed something more adventurous like Arch or a BSD of some kind, but I wanted to keep things simple (at least for now), and went for something I knew I could setup and use with my eyes closed.

I setup the usual stuff like git and similar everyday software. I decided to go for Vim Classic, a slop-free fork of Vim 8.x by Drew DeVault, and then… well, I kinda needed a browser. Now, go find a good, lightweight browser that can access 2026’s crappy version of the WWW for a 32bit processor. Most browsers simply don’t offer 32bit compatibility anymore, but luckily Basilisk Browser does! It’s a really lightweight Firefox fork, and that’s now my go-to browser for those web sites that require (ugh!) JavaScript.

For nice, Smolweb-friendly web-sites, Dillo is hands-down my favorite, but of course, web sites must be done in a certain way (more on that later on in this article).

BUT! There’s always a BUT. Even though technically Basilisk can render it just fine, GitHub.com doesn’t load. Or better, it probably does, eventually, if you close every other tab or program you may have open. That’s just not cool. At that point, I realized that there was only one solution…

Moving away from GitHub ⇈

This has been bothering me for a while, actually. GitHub, once the stronghold of open source software and the only place you’d ever need to be as a developer, is now, well, bad.

The solution? Easy: Sourcehut. I had been using it as a mirror for most of my projects for quite some time, but I was not ready to switch, mainly because of the possibility to create GitHub actions to cross-compile my programs so that I could distribute the binaries when I released a new version.

Actually, Sourcehut has an awesome build service targeting *nix systems, but it doesn’t offer a way to build for macOS or Windows. And for sure I always wanted to ship the binaries for my software for those platforms as well, right? Well, meh…

Truth is, I now have two kids and a full time job, I am the main user of my ecosystem of highly-opinionated tools and keeping all those actions running smoothly had become a second (or third) job. So I was like, you know what? No more binaries distributed for any release of my software! Ah, that felt really good, and gave me the final push to make the move official.

And it turns out, releases are overhyped. I was recently discussing with Devine about Kelvin Versioning, and while I like the idea of software aiming at becoming more stable, I just didn’t like the whole decreasing temperature thing, and the way dependencies are managed.

But I like the concept of software converging to ultimate stability, maturity, and dependability. Oh yes I did…

Convergent Versioning ⇈

What if I stopped stressing about preparing for a version 1.0 of a particular piece of software, and just focused on the level of completeness of that piece of software instead? That is the core philosophy behind Convergent Versioning, my own alternative to Semantic Versioning and Kelvin Versioning. After years trying to be a good citizen and trying to follow semantic versioning for all my projects, I realized that it would be much simpler and useful to think about my projects in terms of how complete they are rather than whether they break compatibility or not.

I am not expecting tons of people to embrace Convergent Versioning, but even if I will be the only user of this new alternative versioning system, at least it will make sense for me.

After finalizing a reasonable stable draft specification for Convergent Versioning, I decided to use it for all my active projects. Now when you look at any of my personal open source project, you will be able to tell the level of maturity and completeness of it. If you go through the changelog of each release, you will also be able to tell whether there have been breaking changes or not (and even derive the corresponding semantic version number for any given version!) – which I personally reasonably easy to reason about, in all its weirdness.

SubWeb ⇈

Alright. So within the last couple of months I managed to:

• Start using a 2011 EeePC laptop, and force myself to use simpler and more lightweight software
• Move all my active projects to Sourcehut from GitHub, and enjoy the simplicity of this new platform
• Adopt Convergent Versioning for all my active projects, and free myself from the pressure of releasing 1.0 or similar versions for my projects, to focus on what matters (dependability, stability, and maturity).

However… I felt that my own web site was not simple enough. Don’t get me wrong, I managed to simplify it considerably over the years, but it still relied on some fancy CSS for managing multiple themes, it used custom fonts, and linked to external resources in some cases.

I tried to imagine how the web (or at least the portion of the web comprised of traditional, personal web site, not apps) should be like. I had a look at the HTML subset proposed for Smolweb and while it was definitely an improvement over traditional HTML5, it was still way too rich and complex for my liking.

When I think about a web site I want to visit, ideally I would like it to render perfectly with the extremely lightweight Dillo browser. I basically was looking for something a little bit more complex than the Gemini protocol, something where you would still be able to build your very own, uniquely styles web site, but without all the complexity and multimedia support of HTML5.

That’s how SubWeb was born: I decided to come up with my very own subset of HTML and CSS, which:

• Allows simple, HTML4-like tags (no SECTION, ASIDE, or other fancy semantic stuff introduced by HTML5 – no reason to bother when you can just use DIVs with an appropriate class).
• No JavaScript.
• No objects or external content, for the matter. No video, no audio, obviously no WASM.
• Images are allowed (JPG, PNG, and GIF), but only if served from the same origin as the web site.

Too strict? Perhaps. But now H3RALD.com is nearly SubWeb-compliant (I still have to fix some external images), and I still don’t think I gave up that much! The branding and styling is still recognizable, but it is much more lightweight and considerably simpler. And of course, it renders in Dillo perfectly.

Where to go from here ⇈

Well, I am happy I finally did all this. I feel that finally my personal projects and web site reached the level of simplicity that I was searching for a long time.

Next… well, maintenance releases, sure, maybe some small features, maybe some improvements to my ConVer and SubWeb proposals… maybe I will eventually manage to recreate my whole ecosystem of tools in a single, cohesive ecosystem implemented in plain C, a-la Uxn. But again, full time job and family commitments take precedence.

Still, one can dream (and plan)…

I have a page on my personal wiki system (which is written in min with a h3 frontend, and still closed-source, unfortunately) titled Use cases for a new programming language. The first line I wrote is the following:

A new programming language should only be created if it helps addressing a specific, practical use case

Right. That was meant to dissuade me to embark in endless quests for creating yet another pointless little language that doesn’t really solve any practical purpose. I have a bunch of those lying around or even half-designed in my personal wiki, and of course min has been my go-to personal project for many years. I still enjoy tinkering with it from time to time.

But…

I still wanted to create a new language. The problem with min is that by emphasizing practicality more and more, it became more of a single-file, batteries-included programming language that can be used to create web servers, make HTTPS requests, process XML files, …“big” things like that.

The syntax also evolved quite a bit to support complex data types, it has sigils, and other oddities (bang-postfixed auto-popping symbols, anyone?). It is also not that small anymore: well over 1MB on some platforms (it statically links OpenSSL for Heaven’s sake).

And it is written in Nim. Because I forgot how to program in C after uni. Sometimes I wish I had invested the same amount of time in re-learning C rather than having picked a new, non-mainstream language to build my ecosystem with. But it’s fine, everything helps shaping up the future, I suppose.

Why hex? ⇈

I always wanted to create a programming language that:

• had a really minimalist syntax
• was small in size
• was cross-platform (compiling to WebAssembly and also αcτµαlly pδrταblε εxεcµταblε)
• was implemented in C (that was more of a personal thing than anything else, but C ain’t going anywhere, at least)
• was concatenative (I am still fascinated by the concatenative programming paradigm)
• was able to do basic operations on strings, numbers, I/O, files and delegate everything else to external programs
• could be used to create shell scripts, used as glue code, etc.
• had some quirks. Not many, but some, to make it interesting and fun to play with
• was easy to understand and useful to learn more about concatenative programming even for non-programmers

Then the name. It took me weeks to come up with a good name. I then finally went with hex because:

• It’s short and memorable
• It has not really been used for a popular programming language yet (go try find 1-3 letter words that are not already taken)
• It has something magical about it (besides thinking about hexadecimal numbers, it also means spell or curse)

MVPL (Minimum Viable Programming Language) ⇈

Another page of my personal wiki aims at defining what constitutes a minimum viable programming language.

Here’s a list of things that I consider mandatory:

• integers
• strings
• arrays
• execute external processes
• variables
• define functions
• flow control with conditionals and loops
• error handling
• standard input and output
• file input and output

…and here’s a list of things that I consider nice to have:

• floats
• objects
• booleans
• lexical scoping
• serialization/deserialization
• regex
• networking
• xml
• json

I hope that lexical scoping in the nice to have made you chuckle. I know it would be bad, but technically you wouldn’t really need lexical scoping, really, especially in case of a concatenative programming language where you don’t necessarily need variables.

I decided to put this into practice when designing hex. And that’s why, hex:

• supports only integers, strings, and lists (quotations). It doesn’t have floats or dictionaries, even.
• comes with 64 native symbol for basic stuff, and lets you define your own (global) symbols, to store data and also define the equivalent of functions.
• uses symbols applied on the stack for everything and I mean, literally everything from flow control to error handling and I/O.

And that’s it. It doesn’t implement any of the nice-to-haves (ok, maybe serialization/deserialization, but that comes for free in homoiconic languages). I am also planning of keeping the number of native symbols fixed to 64, and maybe implement a sort of standard library in hex itself.

Artificial Inception ⇈

But but but… last time I checked, I didn’t know how to program in C anymore, right? It’s not that I can magically start writing decent C code from a day to the next, certainly not enough to write a parser, and interpreter, and things like that.

Or, maybe…

OK, I cheated a little bit. Everyone is always talking about AI, how it is changing the world, how it can do X and how there won’t be a need for Y anymore. There is definitely an element of hype in all that, but undeniably Large Language Models have been quite a breakthrough. Now, it’s not that ChatGPT is really intelligent or 100% reliable, but I hadn’t been using it for a few weeks and I was surprised to notice the improvements.

I started off innocently, expecting just some pointers and some pseudocode:

Implement a simple parser for a really simple stack-based concatenative programming language an able to process integer numbers and common arithmetic operations, for example: 1 3 4 * + 2 - Should result in 11 being pushed on the stack.

It blurted out a Python implementation (no matter what, ChatGPT will always go to Python if you ask it to code something without specifying the language).

Provide a C implementation

And it did… I didn’t try the code, but continued asking it to add support for strings. And kept asking for more extensions. I was surprised that it could keep the context for as long as it did. Then it started hallucinating more frequently, but at the end of the day, I was left with a good enough implementation of a basic interpreted concatenative programming language. Which actually compiled and worked, for the most part!

→ hex’s artificial inception (ChatGPT chat)

I kept tinkering with it for a while, and then decided to create a new repo for it.

After a few days, I found myself reading a lot of C code. Timidly, I started writing more and more myself… when I didn’t remember something (memory allocation, pointer arithmetic), I decided to ask ChatGPT for explanations, summaries, cheat sheets… I was re-learning C!

Now, earlier I said that I cheated a little bit. Using AI to write code still feels a little bit like cheating, sure, but it is important to remember that, after all, it is nothing more than a tool.

There are plenty of issues with it, a lot of ethical ones as well, but at the end of the day, AI is here to stay, and we may as well get the most out of it.

I think getting my little project bootstrapped with AI was an interesting experience, and it was very useful for two things, mainly:

• Taking care of the boring, mechanical parts of the project
• Acting as a personal tutor for learning more about C programming

Again, not an infallible tutor, but still better than figuring stuff on my own or with just the Internet. And definitely faster and more efficient than skimming through a programming book or endless Stack Overflow questions.

Using AI for programming is not cheating, no more than using Stack Overflow or… Visual Studio Code is.

Anyhow, overall positive experience. The best thing I got out of it was a better knowledge of the C programming language: I am now more confident and I can actually program in C a bit, and understand it. Better than I did in a long time, anyway.

#DecemberAdventure ⇈

It took me about 15 days of sporadic ChatGPT interactions alternated with even more sporadic (and short) personal coding sessions to get the basics of the language implemented. At the beginning of December, I then decided to take part in #DecemberAdventure and work on hex of course! You can read more about it here.

The funny thing is that most of the design (and implementation) of the language was kinda there already, but I managed to create more of an ecosystem around it.

One thing I actually enjoy about creating new open source projects is that it is never only about the code: I love writing support material for my creations, creating web sites, things like that.

Today, hex:

• has its own web site at https://hex.2c.fyi, with its own browser-based playground, a tutorial, and even a specification.
• runs on different platforms, and can be compiled to WebAssembly to an αcτµαlly pδrταblε εxεcµταblε
• has a virtual machine, comprised of a simple but fully-functional bytecode compiler and interpreter

The thing is… I have manage to achieve this levels of ecosystem completeness with min, never mind doing it in a really short time. But with hex I started (and remained) small, and that was the key.

Minimalism, distilled ⇈

Syntactically speaking, the language is very similar to min. I always quite liked min’s distinctive lispy flavor without actually being a lisp, its simple way of doing things without many special forms.

Take this program for example:

/bin/sh: chroma: not found

Sure, it is a bit verbose, but if i tell you that:

• ; is used to start line comments
• Things are pushed on the stack from left to right
• Things within parenthesis are quotations (lists) of other things
• Strings are delimited by double quotes
• Integers are prefixed with 0x
• Everything else is a symbol, and unlike other things, when they are not inside a quotation they disappear from the stack and manipulate it in some way

…you basically already know the language syntax and how it works.

You have literals that get pushed on the stack, or symbols that manipulate it, and that’s pretty much it.

You may want to know that the : symbol is used to define other symbols and that the # symbol destroys them, and that the cat symbol pops two strings from the stack and pushes back a concatenation of the two… sure, you can learn all of hex 64 native symbols, but as I mentioned earlier, there are no statements, or expressions, or special forms: everything is either a literal that gets pushed on the stack, or a symbol that manipulates it.

Well, there you have it. Yet another programming language that you’ll never use. Everyone is creating programming language these days, and now with AI even people that normally wouldn’t will be able to, imagine that.

Still, this has been, and it will continue to be, a very rewarding experience. And maybe, just maybe, this new little thing called hex can teach someone something new (concatenative programming) or even be used to write some very cryptic shell script.

And so it begins! This year I learnt about this #DecemberAdventure thing and decided to give it a go. I believe it started off last year as a sort of low-key alternative to Advent of Code… but last year I probably didn’t pay too much attention to it, or dismissed like yet another daily thing to do every day of the month in autumn, and I normally don’t bother with those things (I seldom write here these days, let alone do something every day!).

This year, when more and more fellow Mervellians started to post about it, I thought I’d give it a shot.

Truth is, this year I have a cool little project that just begs to be blogged about. I actually started working on it in mid-November, but the idea is to write a bit of code every day in December (which I have been doing), so that works too. The thing in question is hex, a new concatenative programming language of mine (yes, again).

The thing with this thing, hex, is that… well, it’s a little thing, you see. It’s low key. It doesn’t even get its own domain, just a subdomain, at most. And the site! A little site indeed. Call it minimalist, brutalist even. Very simple styling, simple colors (I am using CSS color names instead of RGB codes because most of it is being written by hand, and on my mobile phone!). It’s just perfect. For me at least, which is what matters the most, right? ;)

Good! Now that we are done with all the introductions and pledges, let’s get going already!

The first fortnight… ⇈

As I mentioned earlier, this project actually started on November 15th, 2024. Yes, I should have waited and posted bits about it everyday in December maybe, that may have been more interesting… or not, in a way. The thing is, this new language right is now more or less implemented, from a pure coding point of view, but a ton of stuff is missing that makes a project polished enough to be released. I am referring to things like:

• More extensive testing
• Comprehensive documentation
• A web site
• An online playground
• Automated builds for different platforms
• Blog posts about it
• A project page here on H3RALD.com

In the first fifteen days I concentrated on rough development, I implemented a way to process tokens, interpret them, I added all the necessary data structures to manage state… I did all this in C. C you say? But I somewhat recently (in June! That’s recent for this site) blurted about the fact that I didn’t actually know how to code C properly! So how the…

Well, AI.

WAIT! Before you metaphorically close this article and burn it, I didn’t mean that AI wrote the whole thing. I started off innocently as asking ChatGPT if it could build an interpreter for a small programming language able to process integers and do simple arithmetic, gave it the parameters, kept refining it, asked to add string support, caught some problems and got it to address them. For a while (0.6745 seconds) I thought this thing was actually able to understand my thoughts and that all developers were going to be out of a job, then… well, then the poor thing just couldn’t do it.

It did well, I gotta say. Let’s say that if you keep your code down to, say, 500 lines it can “remember it” more or less as a fairly dumb junior developer who’s really fast at stack-overflowing tasks… then it falls apart: forgets that we decided to change function names from camel case to snake case, forgets that freeing things in that way segfaulted, and then it started with names of functions that didn’t exist. Damn. Repeat after me:

LLMs ain’t smart, stop trusting them!

Before the hallucinations got out of hand, I did the right thing and took that code out of it and put it in a repo. It needed actual nourishment and care, it needed love. I took pity of that half-baked codebase, and tried to see if I could improve upon it.

One thing I realized was that by conversing with that… thing, and asking the right questions on how pointer work, and how memory is managed, I kinda brought my latent C programming skills from university back to life. I am no expert C programmer, but I believe this little digression helped me remember some of it, at least!

All satisfied with my newfound C wizardly skills, I kept iterating over the code till it got in semi-decent shape. I believe by the end of November most of the symbols I implemented worked properly, segmentation faults that plagued the thing are (mostly) gone, there are a bunch of tests as well and a couple of scripts written in hex, too. One for running the tests and one for generating the web site. Oh, and I almost learnt something about Makefiles, too!

Day #1 ⇈

Today I made some improvements to reporting parsing errors (I had line and column counters already there, why on Earth shouldn’t I use them for parsing errors?), and then focused on getting the playground to work. I read about WASM and Emscripten, and managed to actually compile with minor modifications but… it turns out that if you want to have something other than browser prompts to handle standard import, is a (nearly) impossible task.

Day #2 ⇈

I finally got STDIN to work properly, and you are now able to input into the hex REPL via a standard textbox that blends in with the rest of the pseudo-terminal I quickly hacked together.

Here’s a picture for posterity, in case the design changes:

How I did it, you ask? I basically had to implement an alternative fgets implementation using one of the (ugh!) Emscripten macros to actually call JavaScript code, and it works beautifully!

/bin/sh: chroma: not found

Erhm. Alright. It feels kinda ugly to have JS code in your C file but if that’s what it takes… this is the simplest option I found by far. Kudos to Tomasz Wisniewski.

Excited with this breakthrough (which happened at around 6am while still in bed, for the record), I tried to raise the stakes. Let’s see if I can get an αcτµαlly pδrταblε εxεcµταblε for hex…

/bin/sh: chroma: not found

BOOOM! It worked. I mean, of course it did, hex is not exactly complexity incarnate, but still, good going. One thing I needed to change was adding some extra instruction to flush stdout more often (some implementation of libc differ on this… like musl libc and cosmopolitan libc, some background here), but that was it.

Day #3 ⇈

Today I created a semi-decent about page for hex, improved the static site generator to include different html <title> tags for each page, and started refactoring the Makefile a little bit. Not sure I am getting the task dependencies to work correctly, i.e. when compiling to WASM etc. though.

Day #4 ⇈

I actually wrote this page. Up to here, to be precise, to catch up. And made the conscious decision to actually say that this is a #DecemberAdventure thing. So that’s quite a lot, and so very meta of me.

Day #5 ⇈

Implemented the Github workflow to be able to prebuild hex binaries for:

• Linux (x86_64)
• MacOS (ARM64)
• MacOS (x86_64)
• Windows (x86_64)
• αcτµαlly pδrταblε εxεcµταblε
• WebAssembly

I also created the /get page for the hex web site, which called for improving a little bit the bare-bones static site generator script that I wrote in hex itself. Essentially, I added a general way to replace tags like {{release}} or {{title}} with some values.

First, a helper symbol that expects a strings on the stack, and wraps it in double curly brackets:

/bin/sh: chroma: not found

Then, another symbol to do all the replacements; ; Replace tag ( "pt_repl" store "pt_tag" store "pt_content" store (pt_content pt_tag tag i index 0x0 >) (pt_content pt_tag tag i pt_repl replace "pt_content" store) while pt_content ) "process-tag" store

…this is then used in the main loop to process contents:

/bin/sh: chroma: not found

Not bad, even though it feels a bit verbose. I am actually considering using . instead of i to dequote quotations and maybe even : instead of store, although it may become less readable. At present, non-alphanumeric symbols are only used for well-known mathematical operators like > or +.

Oh, and I also fixed a buffer overflow issue in the read symbol.

Day #6 ⇈

I decided to give it a try, and changed a few commonly-used symbols to use a single non-alphanumeric character:

• store → :
• free → #
• i → .
• eval → !
• q → '

So yesterday’s code snippet becomes this:

/bin/sh: chroma: not found

Out of all, I am particularly fond of ., ', and :. The last two come straight from min, while the dot I shamelessly “borrowed” from Lobo’s kojote (thanks!).

Day #7 ⇈

Today I bashed my head against the wall trying to get hex to work properly when compiled to WASM and run via NodeJS.

The thing is, basically, because of NodeJS’s asynchronous nature, people have been doing all sort of things trying to get something like fgets to work. In the end I ended up re-using the em_fgets function I wrote on Day #2, and then have some NodeJS glue code to actually capture the input via readline’s on event, like this:

/bin/sh: chroma: not found

So… well that worked. Still, I was wondering why I couldn’t see my nice > character in my REPL’s prompt… Well, it turns out that it is basically impossible to get stdout flushing to work in Emscripten. Also calling process.stdout.write on print doesn’t work either so… Meh, there’s a quick fix, can’t be bothered anymore, for now:

/bin/sh: chroma: not found

Anyhow, for now I am going to mark the WASM build as experimental, and be done with it. In other news, I also added support for all platforms and for αcτµαlly pδrταblε εxεcµταblε in the CI workflow that builds hex and runs the tests.

Day #8 ⇈

Today I decided to enhance the comparison operators to support quotations as well. Not the most useful feature in the world, but for completeness' sake, we should also lexicographic comparison of quotations, also because == and != already supported quotations anyway.

Another thing I added was support for splitting a string by character by specifying a blank string as separator:

/bin/sh: chroma: not found

This feature is standard in most programming languages and could be quote useful to work on strings.

Last but not least, I also did some tidying in the repo and organized things neatly in sub-folders.

Day #9 ⇈

Today I added more tests and got past 100 (yay!). Checking for error conditions, mostly. I ended up changing the behavior of some of the symbols, like instead of having errors thrown in case of mismatching types, like in the following test:

/bin/sh: chroma: not found

I am now just returning 0x0 (false) and be done with it.

The other thing I did was updating the web.hex script to… generate the changelog based on files stored in a release folder. I am also generating a CHAGELOG.md file so that GitHub is happy and can preview it, even though it is, in fact, an HTML file…

Day #10 ⇈

And so… Colors! Time for some proper syntax highlighting for hex! I feel like I am kinda cheating a little bit, because having already implemented Vim and VSCode syntax highlighting for min, doing the same for hex was a piece of cake.

Here’s how hex syntax highlighting looks in Vim:

…and that’s how it looks in Visual Studio Code:

Beyond that, I also quickly added support for:

• Scheme-style block comments delimited by #| and #| (like in min)
• Support for handling hashbang if present on the first line

Day #11 ⇈

The spec is up! No, not quite: I just managed to add an outline and the signature of every native symbol. I also updated the web.hex script (the mini static site generator for the hex site) to handle placeholders like {{sym-puts}} and substitute them with links to the corresponding definition in the spec.

I also added more tests and fixed a problem with parsing escaped characters like backslashes and quotes in strings. Hopefully…

Day #12 ⇈

Today I decided to remove the slice and insert symbols (which are fairly complex and can be re-implemented with other symbols, if needed) and substituted them with ord and chr, to return the ASCII code or the character represented by an ASCII code respectively. I believe this functionality is totally missing from the language, and could potentially be used to implement advanced string matching (only of ASCII characters though, I’d like to keep things very simple!).

I also started writing the spec! All the 64 native symbols are now documented (could do with some examples but it’s better than nothing), and I also completed the syntax section.

Day #13 ⇈

The official hex specification is complete. Or better, at least the first draft of it is anyway. I also spent some time tweaking the CSS of the hex web site a little bit to make it more readable.

The other thing I decided to implement for fun was… a poor man’s syntax highlighting markup for hex syntax. Now, hex of course doesn’t have things like regular expressions, and creating a parser for the hex language in itself would be overkill maybe (although perhaps it could be done) so… well, I decided to go for a really crude (but working) method based on replacing unusual sequences of characters like $", or $$.

Here’s the code for it, that is part of the web.hex script (the irony is that the following code will not be highlighted on this site :P).

/bin/sh: chroma: not found

Right… so the idea is to wrap any hex token except for parenthesis with some $ signs, which will be replaced with the corresponding html <span> tags. So a simple example like the following:

/bin/sh: chroma: not found

…would have to be written as:

/bin/sh: chroma: not found

Yikes. Crude. I did say that, didn’t I? But it does save some keystrokes at least!

Day #14 ⇈

It’s out! I decided that it is finally time to release hex v0.1.0! You can go get it from the /get page.

Oh of course I also managed to finish the whole site today, and published an introductory tutorial on the language, which should hopefully help more folks get closer to the concatenative programming paradigm.

Day #15 ⇈

Today I spent more time with my family and took it easy a little bit. I did manage to add a project page for hex here on this side, and thought a little bit about the next steps:

• I will obviously write a proper blog post about thus new project of mine, and explain the reasoning behind it a little bit better.
• I am thinking about reorganizing the source code into multiple .c files and generate an “amalgamation” file for compilation.
• I wouldn’t mind implementing a simple virtual machine and a bytecode format for hex. I always wanted to do it, and this could be my chance as this project is simple enough.

Day #16 ⇈

I decided that I don’t want to manage a single .c file anymore, so it is finally time to split it. But! I still really like the idea that someone may find itt easier to embed if it’s a single file (I know I do for things like SQLite!), so I created my own simple amalgamation script in Bash to concatenate all the files and preserve the original filenames and line numbers. For simplicity’s sake I am using a single header file though (no need for more modular builds right now). Here goes:

/bin/sh: chroma: not found

This didn’t take long… then I started working on a simple virtual machine, decided the opcodes and the bytecode format, and started the implementation. I didn’t quite complete the generation part yet, but hopefully will be done soonish.

Day #17 ⇈

Perhaps I managed to implement a simple bytecode compiler for hex. It took a while, mostly due to my inexperience with C and pointers in particular, but I should have got the basics down.

Consider this example program that prints the numbers that can be divided by two:

/bin/sh: chroma: not found

It is actually pretty comprehensive as far as syntax goes: you have integers, strings, quotations (even nested), native and user symbols.

The corresponding bytecode I am able to generate is this:

Let’s break it down:

/bin/sh: chroma: not found

Phew… that’s the whole lot. Again, this is my very first attempt at something like this. It doesn’t look too bad: I am able to encode all types of tokens, and manage nested quotations, but there’s still room for improvements:

• Every time I need to declare a size, I am taking up the full four bytes of an uint32_t number. In most cases one would be enough… I should implement variable-length encoding of some sort, but can live with it for now.
• Similarly, integers take up four bytes always, and the MSB is the first of the four (making it little-endian), which is a bit counter-intuitive maybe? Or perhaps it’s fine.
• I am essentially encoding user symbols as strings. In similar cases, I noticed that folks tend to add a symbol table after the header for lookups.

Despite these little things, it feels promising. Of course the next step is going to be the interpreter… more fun to come!

Day #18 ⇈

I managed to refine the bytecode generation algorithm a little bit and implement an interpreter that seems to work as expected!

So, for now:

• I implemented variable-length code using the LEB128 algorithm for sizes, and this makes storing sizes and integers more compact.
• Because this algorithm uses little-endian, I have decided to store all integers as little-endians.

The resulting bytecode for yesterday’s example is now more compact:

And here’s the breakdown:

/bin/sh: chroma: not found

Not bad! Now I think I’ll try to implement a symbol table next.

Day #19 ⇈

And the symbol table is in! Now I think this can be documented as the first version of the hex bytecode. Essentially, I now introduced a way to map user-defined symbols to indexes in a “table” that gets saved right after the header and before the actual program.

The size of the table is encoded in the header itself, in two (little endian) bytes (allowing for a maximum of 65535 user-defined symbols, which is more than enough for anyone). Therefore, the length of the hbx (hex bytecode executable) file needs to be eight bytes instead of six, which is nice, in a way:

/bin/sh: chroma: not found

Then, the values of the symbols are stored as sequences of one byte for the size, and then the specified number of bytes for the identifiers. Simple enough!

The lookup operation was using the following sequence before:

/bin/sh: chroma: not found

Now, it becomes the following:

/bin/sh: chroma: not found

Basically, all symbol lookups are going to always take up three bytes now, which would shave some bytes if you use (and reuse) many user-defined symbols.

Therefore, taking the simple program we’ve been using for the last three days:

/bin/sh: chroma: not found

…this compiles to the following:

And here’s the breakdown:

/bin/sh: chroma: not found

The funny thing is that now the resulting bytecode is actually two bytes longer, but that’s because I am only using one symbol twice, and it’s only made up of two letters. Normally, there would be savings as far as bytecode size goes!

That was satisfying. I was so happy about all this byte-wrangling that I also implemented a seamless way to support reading and writing binary files using the existing read, write, and append symbols. Oh, and I extended the ! symbol to also evaluate an array of integers representing hex bytecode!

Day #20 ⇈

Today is chore day! I decided to go over all the error messages and debug messages and reformatted them making sure that are all consistent, and provide adequate context. I also squashed a few nasty bugs:

• Incorrect bytecode generation for negative integers… Values like 0xffffffff (-1) were incorrectly stored in 1 byte (0xff).
• Incorrect stack trace generation — now all symbols pushed on the stack get pushed on the stack trace as well.
• Incorrect handling of comments inside quotations (they were incorrectly counted as quotation elements).
• Warn the user that .hex source files must only contain ASCII characters to be converted to bytecode (not gonna bother handling encodings right now).

I also added information about the Hex Bytecode eXecutable format (HBX) to the specification.

At this point I thought it was actually a good time to release v0.2.0!

Day #21 ⇈

Finally I got around to writing a proper article about hex. How it came about, why I bothered… things like that!

Next I will start thinking about… a standard library for hex, and also maybe improve the playground to support entering longer programs.

Day #22 ⇈

I improved the playground a little bit. I added a button to “upload a file” by copying and pasting it into a textarea and evaluating it. I ended up increasing the STDIN buffer to 16kb and implement a way to strip hashbang, comments, and newlines before sending it through the REPL… kinda hacky, but it seems to work.

I have also been thinking about creating a new :: symbol to create operators (to avoid using . on all user symbols all the time) and also some possible modules for a hypothetical standard library.

Day #23 ⇈

I started working on a next branch because I am introducing some breaking changes. Because I am determined to keep the number of symbols fixed to 64, every time I add something new, I have to remove something else. The choice typically falls upon those symbols that can be implemented in hex more easily using other symbols, so right now, in the next release I am going to remove the following:

• filter
• clear
• each

And add the following:

• :: — Define a new operator, i.e. a symbol meant to modify the stack. This will be defined as an ordinary quotation, but that will be immediately dequoted when pushed on the stack, achieving an effect similar to native symbols.
• symbols — returns a quotation containing strings corresponding to all known symbols. Useful for introspection, memory management, etc.
• throw — Throw an error.

All of these symbols require some internal wizardry that cannot be implemented in hex itself, so, they should be native symbols.

At the same time, I also started working on a (currently untested) utils.hex defining a few utility symbols. The idea is to create a little standard library in hex itself.

Day #24 ⇈

Getting ready for the v0.3.0 release! I updated the spec to mention the new symbols and remove the old ones, I changed the example used for documenting the bytecode (a symbol to calculate the factorial of an integer), and also used the same one for the tutorial. The main driver for this change was to introduce the concept of operators and also to use an example that can be run on the playground, so that you can follow the tutorial without downloading anything.

All the tests are running fine and I also updated the web script to leverage operators (and use while instead of each). The idea is to have a Christmas release tomorrow, obviously.

Day #25 ⇈

hex v0.3.0 is out, Merry Christmas!

Day #26 → #31 ⇈

I had to stop my #DecemberAdventure rather abruptly as I got the flu, but I have continued working on hex on and off. Currently looking into:

• Refactoring to move storage to heap memory as much as possible
• Implementing a more efficient memory management strategy
• Reimplementing the registry as a hash table
• Ensure items are deep copied as needed

Overall, this has been a really positive experience! I really enjoyed working on hex a little bit every day, and build an ecosystem around it.

“Two espressos?”

“Sure, thanks!

That was my cousin, the barman. He always gives us a little discount or offers us coffee at least every time my wife, daughter and I go to his bar for a cocktail and an aperitivo.

Except that now I am writing this at 2am at night. Coffee almost never works the way it was intended for me, but when it does, it really does.

Apps as home-cooked meals, AI, and barriers ⇈

Anyhow, while I was trying to sleep I came across this article on home-cooked software and barefoot developers, which was presented at this year’s local-first conference in Berlin. It sparkled my interest because especially the first part focused on local-first software (which I agree on) and apps as home-cooked meals (which I firmly believe in).

But then it went off advocating leveraging LLMs as a way to empower more people (barefoot developers) to create their home-cooked apps, which made me cringe a little bit.

But I don’t want to talk about AI in this article, I want to focus on another passage from that article which talked about the command-line wall as the barrier that people who possess just-enough coding skills hit:

[…] But they never make it over what I call the command line wall.

They never end up in the terminal, because that is a huge jump in complexity, usability, and frustration from using something like Airtable or Notion.

I should write another post about this category of people… some of which (my boss included) I really admire, but that’s also not the point I want to make now.

The point is the command line wall. I immediately smiled when I read that. “Hah! I am so much smarter, I love the command line and use it every day!”

On not being smart, and knowing your limits ⇈

But am I, really?

Everyone has barriers. Some people can’t use a computer, others can’t use excel, indeed for some people the command line can be scary… but what are my barriers?

Let’s see.

• I can code, and I still do, more or less daily and at least weekly, even though these days I am (supposed to be) a Technical Product Manager
• I know a few programming languages like Nim and JavaScript
• I have built quite a few tools that are listed in the projects section of this site
• I maintain my own site on a VPS
• I implemented quite a few web apps that my family and I use every day, even if the rest of the world doesn’t know about them

Well, that felt good didn’t it? It did.

So no barriers? Not quite. Here’s some things don’t know or I cannot do:

• I can’t code in C or low-level programming languages. I did study it at uni but never really used in the real world, and forgot most of it.
• I am not able to do any manual memory management
• I never learnt assembly
• I can’t do do any desktop UI programming
• I was unable to learn uxn even if I really, really wanted to

And you know what hurts? That because of various extremely important reasons like lack of time due to family and work, I will probably never be able to achieve any of the above. Well, I shouldn’t say never, but at least not in the short or medium term.

And so where does that leave me? Even though I don’t think, like the author of that article, that LLMs can come to the rescue, I would like a magic way to overcome my barriers. I can somewhat relate to the way the author feels.

I think everyone has barriers. And I guess the secret of happiness, or rather, of feeling happy about ourselves is to find the right compromise to overcome them.

This also somewhat feels selfish doesn’t it? “Heh! He should shut up, he can code! Or even, he doesn’t even need to code for a living” some people may say.

Still, the pain of not being able to do something is very real, at very different levels, for all of us probably.

The selfdogfooding disease

But there’s more! A normal person would just pick a tool or programming language and move on. Like I know if I really wanted to learn Uxn I probably could, and I could built some interesting things with it.

That’s not enough though, is it? That would be too easy. I suffer from a rare disease I call extreme self-dogfooding, i.e. I have to kinda… build my own ecosystem in order to be able to build my tools and apps. Like… I wanted to build my own web apps so I ended up building lower level programs to achieve that, like a JavaScript microframework for the frontend, a document store for the backend, but also a programming language in case I need more freedom, and then there’s the ancillary tools like a tech-doc oriented markdown compiler (software needs documentation right?) which could then be used to power a static-site generator… and the list goes on.

The problem? It’s never enough

I have spent a lot of precious free thinking time to try to come up with a new programming language or virtual machine to go even more low level. Like… I did implemented my own programming language, but I did so in Nim, which is kinda high-level and also ended up pulling in a lot of third-party libraries that made it quite big and probably very similar to plenty of other languages…

That’s when I hit the barriers. I would like to be smart enough to, say, implement my own system like Uxn using as little code as possible and build an ecosystem on top of it. Why? Probably just to feel accomplished, because objectively I have no practical reason to do so.

Until… until there’s an itch to scratch. Like implementing a todo list app that works just the way I want maybe, but is that a real need or just an excuse to accomplish something or be creative?

The right way to prepare a home-cooked meal ⇈

I feel we live in a world where if you think of a new piece of software, it probably already exists. Most of the time I end up figuring that out before I start a new project. Especially now that I can’t afford and shouldn’t really start new open source projects I know I cannot maintain.

Peer-pressure? Inferiority complex? Or just a need to be creative? Probably a bit of everything.

Is this constant need to overcome barriers healthy? Maybe not, but it is a very powerful force to unleash creativity, if properly (and carefully) channeled.

The point? I guess there is no “right way” to build your app-as-home-cooked-meal. You can use a high-level programming language, you can use a low-code tool, and (sigh) you can probably use LLMs if that works for you, and if you can achieve your goal.

Extra points if your goal is practical and useful to someone, like creating a budgeting app your spouse can use, or a video game your daughter can play someway, when she gets older.

Exactly twenty years ago today, on March 28th, 2004, I decided to purchase my first Internet domain.

The .com bubble had already burst years earlier, and I remember wondering which domain name I should go for. After a few minutes I decided for h3rald.com, the Internet handle I was using on a few web sites.

The origin of the name H3RALD is nothing too glamorous really: when I moved my first steps on the Internet a few years earlier (my parents were kind of against computers and we had our first one in 1998, when I was in high school) I came across the Hacker Manifesto, which was signed The Hobbit. I remember dreaming about writing something as impactful as that someday, and signing it with an equally cool pseudonym. At the time, I used to purchase the International Herald Tribune every so often from the local newsagent, mainly because it was one of the few foreign newspapers I could get here in Italy at the time, to practice my English.

Obviously, a handle like herald was taken on most web sites, so I decided to add a sparkle of 1337 speak to it, hence h3rald.

The early years ⇈

One thing is buying a domain, another thing is actually using it for something useful.

For the first year or so, the purpose of h3rald.com remained uncertain: I started off with a very simple HTML page with some interactive content mainly in the form of Java applets (news tickers and other pointless things like that) with a sprinkle of JavaScript. I barely knew how to program back then, and even though I was studying IT Engineering at the university here in Genoa, that doesn’t mean it was actually useful, for anything practical.

The first few versions of this web site were rather poor attempts at finding my niche. At one point I got so bold that I even tried to establish a web design studio (H3RALD Labs) with a very, very basic web site. I taught myself PHP, I started using early frameworks like Prado, and most importantly I kept learning new things.

I was doing all this on a 350MHz Pentium II machine that struggled to run Windows XP. When my parents first bought the thing back in ‘98 it felt much, much faster… I couldn’t believe that after only a few years it was becoming obsolete! But that didn’t stop me from discovering Linux (distributions like Mandrake, Slackware and Debian) and configuring it in dual boot (my dad was also using the computer, and I couldn’t really mess things up too much).

Now picture this, in 2004, at least in Italy: - There was no Facebook - MySpace was a thing, but geared at a younger audience - There were no iPhones, no apps - Mobile browsing meant largely accessing a bunch of crappy WAP sites - Dial-up was still the most common way to connect to the Internet - There was no StackOverflow. If you had questions about programming, you had to spend hours looking in specialized forums and communities

At the time, I was part of an online community called CyberArmy. The domain shifted a couple of times from cyberarmy.com (still up, but basically dead) to cyberarmy.net (long story…) and vice-versa, and no, it was nothing related to cyber terrorism, it was… well, just a bunch of people organized in groups (brigades) that aimed at learning more about the Internet and technology; a community of hackers in the original meaning of the word.

In the beginning, people in CyberArmy earned their rank by completing hacking challenges, and then the focus of the site shifted to contributing to brigades instead. At one time, I became the C/O of the group that was curating the community online magazine, zZine.org (domain is dead now). zZine was the first outlet for my articles, some of which I have re-published here.

Back then, I started writing about the things I was learning about, like easy-to-install server packages, or cutting-edge technologies like BluRay vs HD-DVD. Lightweight markup languages like markdown didn’t exist at the time, so all I wrote all those early articles using BBCode, before switching to textile.

A look back at early 2000s technologies and services ⇈

It is funny to look back and read those early 2000s articles now. Do you remember when social bookmarking services were a thing? Del.icio.us? Maybe. What about Spurl, Furl, Blinklist… ring a bell? No? It turns out I was very fond of ma.gnolia when it came out.

I reviewed a few Web 2.0-era services like NetVibes and JournoTwit, tools like Komodo Edit, web frameworks like Akelos or Lithium. Even really cool things like Wunderlist got acquired and eventually killed off.

But luckily some things were built to last:

• AJAX may not be called that anymore (and we may have most definitely dropped the XML part), but it laid the foundation of modern JavaScript.
• REST is alive and well.
• Git is now the de-facto version control system.
• SQLite is very widely-used and respected.

Browser War II ⇈

This topic deserves its own section. Nowadays, even though some would say that the wars are now over and Google Chrome won, the reality is that for good and for bad Google’s creation and all its Blink brothers have the lion share of the market. Sure, Firefox is alive and (mostly) well, but things are much easier for web developers and more pleasant for users now than they were in the early 2000s.

Trust me, I was there. I lived and fought what history now calls the second browser war and quite a few pages on this web site are a testament to those hard but glorious times when developing a web site meant trying it out in at least three or four different browsers (each with its own engine) to make sure it looked right.

Being a Windows XP user at the time, I took advantage of the beta period in which Microsoft let users test Internet Explorer 7. Yes, I did write a pre-review of IE7 in 2005. That thing introduced support for cutting edge features like tabs, transparent PNGs, and even partial CSS2 support!

Crazy stuff. IE was very prevalent back then also because, as a web developer, you could not afford to ignore it: if your site had to support IE (and a lot of sites sadly only supported IE), you kinda had to use it as well. Nonetheless, I remember spending a considerable amount of time looking for the perfect browser.

Firefox was Heaven though. I mean really, it was, compared to the competition. But most people didn’t understand, so I ended up putting myself in their shoes and wrote an IE lover’s guide to Firefox to educate the masses (including my family) that there was a better, faster, and more pleasant way to browse the web.

I even reviewed preliminary versions like the one that was codenamed Deer Park, i.e. version 1.1 of the popular Mozilla browser.

Fast-forward three years later, and I found myself deeply involved in the Firefox 3 release. SitePoint published a very in-depth article of mine that was also realesed as a 30-page PDF ebook: Firefox 3 revealed (you can now download right here if you want).

To this day, although largely insignificant in the grand scheme of things, I consider that mini book a personal jewel of mine, and the closest thing I ever had to get a book published (more on that later).

After the Firefox years, my attention slowly shifted to Opera (the real thing with its own browser engine, Presto, not the Chromium-based bad copy we have today) and I finally published a Firefox lover guide to Opera to get more people to switch.

But in the end Google did it. When the big G released Google Chrome in September 2008, it really felt like things were over. Like with all the greatest products of our time (when Steve Jobs released the first iPhone I had the exact same feeling), a company took an old idea (a browser with tabs) and an “old” engine (WebKit) and turned into something new and much better than the competition. A multi-process browser, something never done before.

I reported the birth of Chrome from my humble web site that day, still not quite sure if that was going to be just a phase, just another meteor of a product that was doomed to be forgotten. It was not.

CakePHP ⇈

But let’s go back to 2006 a second — we may as well: most of my articles are from before 2010 anyway.

In those years I had just taught myself PHP but Ruby on Rails was all the rage: imagine a web framework that let you create a blog in 15 minutes, with powerful command line tools, scaffolding, and a truly awesome (and elegant) programming language to go with it!

Too bad I had spent months learning PHP. But it turns out there was at least one PHP framework that wanted to be on Rails, and that was CakePHP. So I learnt more and more about it, played with it in a few personal projects, and even re-did my web site using it.

In the blink of an eye, I became one of the most well-known CakePHP bakers of the time. I started blogging about it, I wrote an extensive review, I was contacted by a few PHP magazines to write articles about it, and of course I wrote one for SitePoint, too.

I was then approached by not one but two different publishers to write a book! Eventually, I signed a book deal with Peachpit/New Riders/Pearson for what would have become the first, official book about CakePHP. Official because it was supposed to be co-authored with Larry E. Masters and Garret J. Woodworth, the creators of the framework, who were supposed to provide all the code snippets to go in the book.

The book is still currently not available right now on Amazon Italy, Amazon India, and Amazon Japan but no point in waiting because (after 18 years) it will never be released. It has a cover, an ISBN number and all… but it never happened.

To this day, people who happen to google my name eventually end up on one of those pages and then ask me about that book that I never wrote. What happened? Well, the CakePHP Foundation never hold up their part of the deal and never provided the code examples for the book. To this day, I would really like to go back in time and slap my cocky 23-year-old self real hard and scream write those damn code examples yourself and get it done, you idiot!

Talk about regrets. Having your name associated with a failed book is probably the worst thing that can happen to a wannabe published author. What’s worse, is that when the book was canceled, a lot of drama followed (I wrote not one, but two and then even three posts about it).

If I try to rationalize what went down now, nearly twenty years later, I’d say that both parties had other crap going on: I had just started my first permanent job at an important company, and Larry and Garret just had a brand new web framework to nurture, and one that was getting really popular really quickly.

One of the few good things that came out from that period was a popular article on my web site that got featured on the Digg homepage. What is Digg, you ask? Well, let’s see… Digg was something similar to Hacker News today, but worse. Ah, the fun times…

Anyhow, that failed book really left a scar: I was truly pissed. So pissed that I decided it was time to move on and learn that cool programming language everyone was raving about…

Ruby ⇈

Now talk about a healthier ecosystem with less drama! Kidding… but yes, I did enjoy my time with the Ruby community. I also felt I was learning a proper programming language, not something that was frowned upon like PHP.

With Ruby, I moved my very first steps in the world of open source software, by releasing a few (probably very mediocre) software projects into the wild. You can still find them in the projects sections, by the way: I am talking about RedBook, Rawline, and Concatenative.

The Ruby ecosystem was full of living legends at the time. Names like the godlike DHH, creator of Rails, Zed Shaw the rockstar developer, Obie Fernandez, and of course _why the lucky stiff. Ruby made me discover the true joy of programming, of feeling like you are creating something useful that behaves exactly like you want it.

I miss those days, I think younger generations are not as lucky. There’s too much pressure today, kids want to learn programming just to land a cool and hopefully high-paid job… back then it was all about the fun of creating and learning new things… or maybe I was just younger.

While I was developing little Ruby programs, I was also reading a lot of Ruby programming books. I reviewed a lot of them (most of them by Pearson Education, which at the time was the leading publisher for programming books on Ruby), such as:

• The Humble Little Ruby Book
• The Rails Way
• The Rails 3 Way

And also a few books on software development and agile practices.

The Personal Stuff ⇈

That’s all very well but… I introduced H3RALD.com as my personal web site. And it is, although I have never really posted a lot of really personal stuff: I blogged about my life, but I tried to stick to themes like technology and programming. However, there were a few occasions that called for really personal blog posts.

Probably one of the most emotional articles I have ever written is the one about my grandfather. I wrote it on the day after he passed away, in 2006, and I remember trying to put together my thoughts and try to remember all the stories that he told me about his life. Blogging wasn’t really a thing in the 1940s and 1950s, and he was never much into writing anyway, but he was an amazing storyteller. When I was a little boy, every time we started talking, he always ended up telling me about the war (he was a WWII pilot), about his plane… no matter what the topic was, it was always related to some anecdote about that period in his life. They say that old people live in the past, and it may be true, but the important thing is that when some old relative tells you a story, no matter how boring it sounds at the time, you should always listen to them. You should record them, if you can, in fact!

I tried to capture a few of the stories he used to tell me in that article… but there were so many more! I wish I could remember them all. If I could go back in time, I would like to tell my 20-something year old self to start a blog together with my grandfather. It would have been an amazing experience.

On a lighter note, another personal article that is not related to computing that I stumbled upon was my incomplete guide to London. Kinda funny reading it now, but I am glad I wrote it.

And of course I did write about the most wonderful day of my life, when I got married to my wife in 2009, and about our unforgettable Irish wedding.

The end of blogging and the Nim era ⇈

Among the most popular articles I wrote, I must definitely mention my roundup of ten emerging programming languages from 2008, and the follow-up article I decided to write exactly ten years later, in 2018. And yes, I should probably write another one in four years time, although these days I am only learning new programming languages for fun, not to make a career out of it.

Another really interesting episode of my life I am extremely glad I recorded on my blog is about my pizza with Randal Schwartz. At the time I was an avid FLOSS Weekly listener and Randal was hosting that podcast. Podcasts are weird… I remember listening to FLOSS Weekly and This week in Tech every week when driving down to my in-laws, and after a while I felt like I knew these people really well, I knew what they were up to, and meeting Randal in person when he came to Genoa because of one of his Geek Cruises felt weird but not, at the same time. He probably forgot about that evening, but for me it was like meeting a celebrity, and I was over the moon.

Then… well, there’s no other way to say it, I progressively stopped blogging and writing articles. I tried to rationalize it and even wrote about it, but the reasons boil down to realizing that:

• probably nobody really gives a crap about my blog
• I was having a hard time finding something to write about that was not already on someone else’s blog
• there are entire companies that make money out of writing blogs, you can’t compete with them
• I didn’t have time

You may find counter-arguments for each of the above, but the fact remains that I haven’t really spent much time writing in the last ten years.

I also remember realizing at the time that maybe I needed to create some cool pieces of software so that I could write about it on my site. And I did. I got progressively into command line applications and utilities (while progressively shifting to frontend development at work, that’s kinda funny), and I moved away from Ruby for mainly two reasons:

• You needed Ruby to run it, so your programs were only going to be used by people who had it installed on their machine
• It was slow for certain things

I obviously spent some time looking into different programming languages, and finally settled with Nim, or Nimrod, as it was called originally.

One of the first things I did was creating a documentation tool that I could use to write the technical docs for my software. Then I decided that I needed a sort of document store with full text search because I wanted to implement a search functionality for H3RALD.com (afterwards, I decided not to bother).

What I really wanted to create though, was a new programming language, and that’s how min came to life. Then, I figured I had all the building blocks to create a new static site generator that currently still powers this site…

See a pattern there? I was scratching my own itches. And that’s how great software gets made. That’s just a statement by the way, I am not implying that I am writing great software in an absolute sense, only that I am writing great (and useful!) software for me, and my specific use cases.

I also wrote a JavaScript micro framework which probably no one uses besides me, but it made it really simple to create the (closed source for now) personal wiki engine that powers nifty.tools (the backend is written in min) and 2c.fyi (the backend is powered by LiteStore).

Talk about selfdogfooding, huh?

Going forward ⇈

To the two or three people that made it this far (or that skipped right to this section), here are some key takeaways after twenty years of running a personal web site.

When in doubt, just write. Don’t over-think it. Don’t ask yourself if others already wrote something on the subject, don’t ask yourself if writing about something is worthwhile. It is always worthwhile. I wrote reviews about programs and services that have been dead for years, and it was still worthwhile. I was worthwhile because it made me laugh about it ten or twenty years later, it was worthwhile because I learnt something new while writing it, or just because it brought me joy.

A personal web site is mainly for you, not others. You have it because it makes you happy, because it’s an excuse to try out new technology and learn new things, because you need to write 10,000 words on a digital page just rambling about random stuff, because you can.

My web site is worth more than Facebook. Because I own it. I don’t own Facebook, or X, or Instagram, or TikTok, or Wikipedia. I own H3RALD.com, and that’s where my content goes. Since I moved my first steps on the Internet, I have never understood why the majority of people deliberately choose to donate their content to walled gardens, it just doesn’t make sense in my mind, and that’s why I have never really been into social networks. Sure, I may snoop (or ask my wife to) on friends and relatives through Facebook, put a like on LinkedIn when our head of product management posts something about our product, but if I have something to say, from me, it goes on my web site.

There is still hope for the World Wide Web. While the Internet may be lost to apps, video streaming services, and corporations that want your content for free to make them rich, the WWW as sir Tim intended is alive and well. It’s called smol web now, and it’s where people who care about artisan computing and apps as a home cooked meal live, it’s a few little towns in the Fediverse like Merveilles where some truly smart and really creative folks hang out.

Woah, this was long. But I needed it…

Here’s to another twenty years of pointless, but liberating writing and programming. Happy birthday H3RALD.com!

One of such assignment consisted in developing (surprise, surprise) a simple Todo List single-page application but without using any third-party library. Besides providing basic functionalities like adding/removing/completing todo items etc., you would get bonus points for things like support for data pagination, simple data persistence, and support for filtering todo items.

I found this quite a refreshing challenge, but I soon realized how tedious it was to operate on the DOM “in the old way” and how messy things could get really quickly.

I really, really wanted to use even something minimal like Mithril to carry out the assignment! And started wondering how hard it would be to implement a quick-and-dirty Virtual DOM to manage changes more efficiently and also a simple HyperScript implementation to speed-up the creation of HTML elements…

After a few minutes, I found myself deep in creating a reasonably efficient (virtual) DOM diffing and rendering algorithm and soon enough I was able to use my little microframework to create my Todo List. It was very basic and had quite a few bugs in it, but it did the job alright, and I quickly completed the assignement and sent it back to the company for review.

The reviewer seemed very happy about it but also started to point out that things weren’t quite right. He wanted me to improve the efficiency of the DOM diffing algorithm, he pointed out a few little bugs here and there… and told me to improve things. We kept doing back and forth with my code until he was (reasonably) satisfied with the result.

I then continued the interview process (one of the toughest but by far the most rewarding I’ve ever been through) and I got offered the job. Sadly I ended up not taking it for a few reasons that are well beyond the scope of this article, but the point is that I was left with the code of that assignment sitting in an abandoned repository…

…until a few weeks ago, when I decided to do something with it.

I remember using h3() as the HyperScript construtor as a sort of pun on the fact that typically you’d use h() but I wanted to be more personal to me so I decided to use the first two letters of the name of web site for it… Therefore, because what I lack in creativity I have in ego, I decided to create a new microframework based on it, and call it H3.

Why oh why another microframework you ask? For the same reason why I developed a web server, a NoSQL store, a Markdown processor, a static site generator, and even a programming language: BECAUSE I CAN.

I also wanted to be able to fully understand every single line of the UI framework I was using, and also be able to fully control it — something few people can honestly say about mainstream frameworks.

Most likely, I am gonna get a huge amount of very constructive critiques on Hacker News which I will treasure greatly, and hopefully some help on how to make my little creation actually useful to someone besides myself.

Well, here you have it, my very own microframework. It’s just seven methods and two read-only properties, go try it out if you are brave enough:

Oddly enough, the actual JavaScript source code (app.js file) of the site above (without H3 or the two third-party libraries I used for markdown processing and syntax highlighting) is under 100 lines, and it should give you a taste of how it feels like to create a SPA with H3:

/bin/sh: chroma: not found

Simple enough. Note that it’s all ES6, and no, there are no plans to provide neither a transpiled version to ES5 nor compatibility with (yuck!) IE11.

If you are a big corporation with customers that insists on using IE11 even though it’s 2020 and even Microsoft moved on then this is not for you, I am really sorry.

If you decide to try H3 out, consider using it as it is meant to be used – with an ES6 module script tag loading the entry point of your SPA:

/bin/sh: chroma: not found

Yes, you can do that. And no, you don’t need WebPack either. Let your JavaScript live free, untranspiled and unminified even! Yes OK you can minify it if you really really want to, but I won’t do it for you (plus you’d probably want to do it yourself within your toolchain anyway).

Sure, H3 will never become the next React and will never have legions of caffeine-driven developers pouring code into it… but just creating it taught me a lot about SPAs and frameworks, and perhaps you can learn something from it too!

At any rate, feel free to open issues and suggest (or even make) changes to the source if you want to.

It has been exactly 10 years today since I published my 10 programming languages worth checking out article on this web site.

Over the last 10 years I thought about writing another non-mainstream programming language roundup, but I never got around to it, until I looked at the date of the original article a few months ago, and I thought about publishing its sequel exactly 10 yearns afterwards.

The following 10 sections are devoted to 10 different programming languages. They are not numbered and they are presented in alphabetical order, because there’s no winner in this list. Also, the number of people actively using these languages varies quite a lot, but none of these can be considered, at the time of writing, a mainstream programming language like JavaScript, C, C++, Python or Ruby.

For each language, I included a brief overview, an example implementation of the FizzBuzz problem (in most cases adapted from RosettaCode), and a collection of links to get started.

Crystal ⇈

Fast as C, slick as Ruby — it pretty much sums it up. Crystal was first released in 2014, it is a Ruby-like programming that compiles to native code using LLVM, so it is faster than its popular, more-colorful ancestor.

If you already know Ruby and love its syntax, then you’ll fall in love with Crystal and its metaprogramming capabilities, but you’ll also like its dedicated syntax to integrate with native C code and the possibility to create standalone executable files just by running crystal build myprogram.cr

While no 1.0 version has been released yet, the language is quite popular. It comes with a web framework, it has been used to create games, and someone even calls it the most promising programming language of 2018. It is not backed by a big companies like some of the languages on this list, but this could be a good thing, after all.

Example FizzBuzz Implementation

/bin/sh: chroma: not found

To get you started…

• Official Web Site
• Official Forum
• Wikipedia Page
• Awesome Crystal
• Crystal Shards - a collection of awesome Crystal libraries

Elixir ⇈

Elixir came about in 2011 as an effort to bring more extensibility, metaprogramming and a more Ruby-esque syntax to the Erlang world. If you are already in love Ruby, but you’d like a little bit more oomph, you’ll love Elixir: it runs on top of the Erlang virtual machine but it looks and feels like Ruby.

Over the years Elixir steadily grew in popularity, reached a version 1.0, and it now provides really comprehensive documentation, a friendly community and a rich ecosystem of packages. Also, if you are looking for a Rails/Django/Express equivalent, the Phoenix framework has been used successfully in many projects.

Elixir is also considered a first-class citizen within the Erlang community: if you visit hex.pm, the title says the package manager for the Erlang ecosystem and it tells you right away how to specify dependencies with Elixir and Erlang.

If you always wanted to try out Erlang but never did because its syntax scared you, then Elixir can definitely help.

Example FizzBuzz Implementation

/bin/sh: chroma: not found

To get you started…

• Official Web Site
• Official Forum
• Wikipedia Page
• Awesome Elixir
• The hex package manager

Elm ⇈

Elm was the last language I picked last for this list. I wasn’t going to include it because it’s not as general purpose as the other languages, as it is focused solely on web development and it transpiles to JavaScript, and there are an awful lot of languages that do this nowadays.

The reason why I picked Elm in the end is because, unlike most of the languages that transpile to JavaScript (hey, I said most!), Elm has its own very distinct flavor and ecosystem. Also, it is very much a batteries-included solution to develop web applications: there’s no need for a JavaScript framework if you are using Elm, and if you embrace its philosophy and take full advantage of its extensive tooling, you won’t suffer from JavaScript Fatigue anymore.

Elm offers static typing, type inference, pattern matching, functors, applicative and monads. It kinda feels a bit like Haskell, but perhaps less daunting and more to-the-point: you are going to use it to build web applications after all.

Example FizzBuzz Implementation

/bin/sh: chroma: not found

To get you started…

• Official Web Site
• Official Forum
• Wikipedia Page
• Awesome Elm
• Elm packages

Go ⇈

One of the most significant trends in the last 10 years is big companies creating and sponsoring their own programming languages. In 2009, Google created Go as a more modern substitute to C and C++. It provides structural typing, memory safety, support for different programming paradigms, high performance and concurrency, and of course a friendlier syntax than C or C++.

One example of a successful application written in Go? Docker of course. Over the years Go has been used successfully to build almost anything, from web frameworks like Revel, data stores like InfluxDb and very popular static site generators like Hugo.

If you want a fairly stable and well-rounded programming language for your next project, Go is a safe and powerful choice.

Example FizzBuzz Implementation

/bin/sh: chroma: not found

To get you started…

• Official Web Site
• Official Forum
• Wikipedia Page
• Awesome Go
• dep - Dependency Management for Go

Julia ⇈

Julia started out in 2009 and reached its 1.0 release just a few months ago. It is written mainly in C except for its parser that is written in FemtoLisp, a Scheme implementation developed by Julia’s creator, Jeff Bezanson.

Perhaps among the most specialized programming languages in this list, Julia excels in scientific computing, data analysis and machine learning although it can still be used for more ordinary things like web development (thanks to its Genie framework). The first thing that comes to mind when people approach this language is why would you use it when Python and R already exist and are more mainstream (in the world of scientific computing). The answer seems to be predominantly performance, when compared to its direct competitors in the same space.

Sure, it’s less mature and tooling probably is not quite on-par with Python, but over the years it is slowly gaining some momentum, especially after its recent 1.0 release. Also, the fact that it has FFIs to C, Fortran, Python, R and Java could probably tempt more scientists into a more step-by-step adoption.

Example FizzBuzz Implementation

/bin/sh: chroma: not found

To get you started…

• Official Web Site
• Official Forum
• Wikipedia Page
• Awesome Julia
• Pkg - Julia Package Manager

Kotlin ⇈

Born in 2011, Kotlin was originally JetBrains' attempt to create a language with cool features like functional programming support, extension methods, etc. but still compile very quickly compared to other JVM languages like Scala. As a bonus, Kotlin can also be compiled to JavaScript code.

Quite a few high-profile Android apps have been migrated to Kotlin over the years, reporting various benefits ranging from being much more concise, safer and overall leading to more maintainable code than Java. Besides JetBrains, a few startups and companies are reportedly using Kotlin in production, such as Basecamp, Square, and Pinterest.

Although I have never been a big fan of the JVM, Kotlin is definitely one of the most innovative and trending languages running on it nowadays, and perhaps more well-known than its comparable contenders, like Ceylon and Xtend — the so-called second generation JVM languages.

Example FizzBuzz Implementation

/bin/sh: chroma: not found

To get you started…

• Official Web Site
• Official Forum
• Wikipedia Page
• Awesome Kotlin

Nim ⇈

Nim is the oldest language on this list, as it was born in 2008, so exactly 10 years ago, under the name of Nimrod. The intent of the author, Andreas Rumpf, was to name it after a biblical king, little did he know that in the US the word is also a synonym for idiot or similar, so the language was later renamed to Nim.

Anyhow, after 10 years, the Nim programming language hasn’t reached version 1.0 yet, but according to the core team we are apparently very close.

Currently at version 0.19.0, Nim is quite stable and can be used in production as quite an efficient system programming language that compiles to C, but it looks and feels like Python. You may want to watch out for deprecations between one release and the other, but I’ve been using it for the last… 10 years and it has been a remarkable experience. I use Nim in my spare time in quite a few pet projects, including the static site generator that currently powers this web site.

Want to know something else really cool written in Nim? The open source Nim forum engine which is based on the Karax SPA framework and the Jester web server, both also written in Nim.

Example FizzBuzz Implementation

/bin/sh: chroma: not found

To get you started…

• Official Web Site
• Official Forum
• Wikipedia Page
• Awesome Nim
• Nim Package Directory

Rust ⇈

Mozilla unveiled Rust in 2010, as an effort to create a high-performance system programming language comparable to C and C++ for performance, but easier to use and with more modern features common to high-level programming language.

After 8 years, portions of Firefox, Dropbox and Cloudflare are written in Rust, the Piston open source game engine is written in Rust, and of course Mozilla’s Servo, a new browser engine that will probably make its way into Firefox in the near future.

There are quite a few articles online comparing Rust to Nim and Go. These three language are somewhat in the same space, being all born as system programming languages and addressing similar concerns. If you read these articles you’ll see an almost equal percentage of wins and losses… there are pros and cons as in everything: Nim has the smallest community, Go probably the biggest; Nim syntax is practically Python, Go’s is pretty easy as well, while Rust seems syntactically the closes to C/C++, and also arguably the most complex. But again, your mileage may vary.

Example FizzBuzz Implementation

/bin/sh: chroma: not found

To get you started…

• Official Web Site
• Official Forum
• Wikipedia Page)
• Awesome Rust
• Crates - Rust Package Registry

Swift ⇈

Swift is Apple’s answer to the prayers of many iOS app developers complaining that Objective-C was too hard to program with. It was first released in 2014 and it became very popular especially among iOS developers… in fact I don’t believe it’s used for anything else really.

Similarly, it doesn’t run on Windows but only on Unixes (Darwin/Linux/FreeBSD), but typically 90% of its users are going to program in Swift using XCode on their macOS machine anyway.

While definitely a step up from Objective-C from a syntax and high-level features point of view, unlike most of the other languages on this list its niche is pretty much mobile apps, or better, iOS apps. If I were to develop an iOS app today, I’d probably pick Swift as well.

Example FizzBuzz Implementation

/bin/sh: chroma: not found

To get you started…

• Official Web Site
• Official Forum
• Wikipedia Page
• Awesome Swift

Zig ⇈

Zig was born in 2016 and it hit its 0.3.0 release just a few months ago. The language positions itself in the already-crowded space of the next generation system programming languages, but there’s a rationale for it.

It is essentially a much smaller, more minimalist alternative to Rust, C++, and D. Its syntax doesn’t look as user-friendly as other languages on this list, but Zig seems to have a particular focus on being safer than its competitors. It provides easy interoperability with C ([…] Compatible with C libraries with no wrapper necessary. Directly include C .h files and get access to the functions and symbols therein.) and aims at targeting as many platforms as possible.

Could this be the holy grail, the true replacement of C? Only time will tell. It’s way too soon to judge, but this new kid on the block is the last on this list, but one of the most promising.

Example FizzBuzz Implementation

/bin/sh: chroma: not found

(updated based on this Reddit comment)

To get you started…

• Official Web Site

Epilogue ⇈

…And that’s all, folks! Sorry if I missed your favorite language, I really am. But this is not really a competition, it’s just a very opinionated article.

The one thing to take away from this article, along with a bunch of hopefully useful links, is that none of these languages existed when I wrote the original article 10 years ago (except for Nim of course that already existed as Nimrod). This is remarkable. 10 years ago people were already going crazy on the then-just-launched Hacker News and Reddit every time a new programming language popped up.

Why bother? —They said. Why did you create X when Y and Z already do the same thing?

The answer is that creating a new programming language is sometimes the best strategy to solve a problem. Apple had a problem with Objective-C and created Swift, Mozilla needed something better than C++ to create their next generation browser, some people really loved Ruby but hated its inherent slowness and created Crystal and Elixir. All these extraordinary people and companies were bold enough to bet on something completely new and be (relatively) successful.

We are living a new Golden Age of programming language design, and we should be grateful for this diversity, not pissed off. Learning a new programming language may feel pointless sometimes, but it is always rewarding to some level… so pick one of these and try it out, you won’t be disappointed!

It has been over TWO years since my last article on this site. I have been pretty busy with work and all and well… same old, same old.

It’s not that I didn’t have time to write articles, it’s a mixture of different things:

• I’ve been neglecting this site, in favor of other projects.
• this site was running an old version of the Nanoc static site generator.
• …that in turn was running on an old version of Ruby.
• …and I am not really using Ruby anymore nowadays.

I’ve always been fascinated by the IndieWeb as a bold response to being subjugated by the proprietary web of Facebook, Google, Twitter et al. I am not a social user and I’ve never been one: I just can’t wrap my head around the concept of essentially giving my own creations (content, in this case) to a corporation for free, without proper credit.

I’ve owned my own web site since 2004, and I am a proud believer of essentially all the IndieWeb Principles. They make logical sense to me; in particular the one concerning selfdogfooding —a horrible term for a very noble cause.

So I decided to ditch Nanoc. There’s nothing inherently wrong with it, and it is also an open source project, but I really wanted to build my own tool to publish content on the web.

TL;DR ⇈

I ended up creating HastySite, a self-contained static site generator written in Nim that leverages on HastyScribe for markdown processing, on Moustachu for mustache templates, and on the min programming language for pretty much everything else.

Choosing a technology stack ⇈

I started programming with Turbo Pascal, then C, C++, Java, then I learnt PHP, then moved on to Ruby in the golden years of Ruby on Rails, meanwhile got briefly acquainted with Lisp, Scheme, Haskell, a bunch of esoteric programming languages like Io (see this article for more).

More recently, I started using Javascript (the new Javascript reborn in the 2010s, and more specifically its good parts) both in the browser and on the server, even at work.

I believe that Javascript is a very powerful and expressive language, but it has its shortcomings —both in terms of the language itself and its ecosystem. More specifically, I cannot believe we now consider normal juggling thousands of third-party NPM packages to build almost anything using today’s Javascript. People are getting more and more pissed off about this, and maybe someday the whole NPM ecosystem will implode in itself… But this is another story.

Let’s just say that I discarded Javascript for this endeavor, not because unsuitable for the task (there are dozens of pretty decent static site generators written in Javascript already), but because I wanted to build something simpler to manage, in terms of dependencies and… number of files.

That’s why I chose Nim. I have been using Nim on-and-off in my pet projects for years now: it is a very productive language, and it produces small, fast-as-C, self-contained executable files for many different platforms.

Functionality ⇈

So what are the key features a static site generator must have?

At the very least, the following:

• Generate HTML files from a lightweight markup language.
• Provide a way to manage content templates (and partial templates) for things like headers, footers, and so on.
• Provide a way to store page metadata, and ideally to build custom logic based on it.
• Providing an efficient way to manage assets, i.e. typically just copy them to the output folder.
• Provide ways to customize paths and content/asset routing.

This is the bare minimum. Then you may also want support for CSS preprocessors, themes, JavaScript minification, content reuse and more.

Markdown Processing

When it comes to picking a lightweight markup language, Markdown is a solid choice. It is readable and it comes in many flavors that provide just about anything you need to write an article or blog post.

A while back I created HastyScribe, a fast Markdown processor based on Discount. It may not be the most standard flavor of Markdown, but it is one of the most feature-rich. Besides standard Markdown features and what is already supported by Discount, HastyScribe also provides support for:

• Content snippets
• Transclusion of other Markdown files
• Simple substitution macros
• Custom fields

Those features provide a very high degree of content reuse; not everyone needs them, but they are very useful for certain types of web sites and when authoring technical reference documentation.

HastyScribe is also written in Nim, which makes it ideal for this project.

Mustache Template Engine ⇈

Like with lightweight markup languages, there are tons of different template engines out there. Mustache is one of the oldest logic-less template engines, often emulated and improved upon. There are several implementations of Mustache in different languages, and luckily there’s also one for Nim: Moustachu.

Moustachu supports the following key basic features that are essential for the management of static web sites:

• Variables – Essentially placeholders for text, wrapped in double curly braces.
• Sections – Used for managing blocks of conditional text as well as lists of items.
• Partials – Used to render a mustache template within another mustache template (and inheriting its context). This is essential to support proper layout management with reusable portions of code such as headers, footers, and so on.

Rules and Custom Scripts

Although logic-less templates are great for keeping things simple and making you focus on content and layout, they are not enough to create a whole site. You’d always need something to drive the generation flow, collect and expose (meta)data, copy and process files.

I briefly considered the possibility of providing a big fat YAML or JSON file to configure every single aspect of a site and its generation process, from its name to the way content is processed, and routing. Luckily, I soon realized that this approach would not be enough if this new static site generator were meant to become extensible rather than just configurable, so I started looking into DSLs and small scripting languages to embed in the main Nim program – Nim, being a compiled language, cannot be used for this purpose.

I could have picked something like duktape and be done with it, but in the interests of selfdogfooding I decided to use my own. While working on this project, I was also implementing a new, minimalist concatenative programming language called min.

Now, min is written in Nim (pun intended), and provides the bare minimum to qualify as a systems programming language: work with files, environment variables, execute external processes etc. Being concatenative and also functional, it seemed a good candidate to be used as the backbone for the building pipeline of a static site generator, while also providing a high-level way to extend the program.

Introducing HastySite

After a few months of experimenting and tinkering with the above-mentioned technologies, I released HastySite, a fully-functional static site generator built around the HastyScribe markdown processor.

HastySite is a single, self-contained executable file available for all major platforms that allows you create a brand new static site or blog in a matter of seconds – if you choose to stick with the defaults and not customize anything, that is. Otherwise… you can go through the documentation on the site (also available as a standalone, printable HTML file), learn how everything works, and customize/extend whatever you want, from the CSS styles to use to the way you are copying files to the output folder (which can of course be something different than output).

If you just want to play with it, just download the executable and run hastysite init. This is actually the only command provided by HastySite that cannot be customized (where customized in this case means rewritten from scratch), simply because it creates the default web site structure.

This command will also dump some CSS files and fonts in your asset folder, just enough to create a web site as ugly as HastySite’s —the idea is of course that you remove those and place your own there. Similarly, you will also have some default templates and some commands you can use to create content and build the site —you’ll probably want to keep those, or maybe just change them just a little bit at least until you become comfortable with the min language.

So, to sum up, with HastySite you get:

• Enhanced Markdown support for all your content, powered by HastyScribe.
• Mustache templates support.
• A bare-bones but fully-functional responsive site theme based on HastyScribe’s stylesheet.
• Default scripts to build and clean your site, as well as creating pages and blog posts.
• Support for arbitrary metadata processing in content files, so that you can implement your own custom logic to process content.
• Support for customizing and extending the way the program works almost in any way, using the min programming language.
• Very fast and optimized (write a file in output only if it is new or modified) content processing.

…and of course it’s 100% open source, MIT-licensed software.

Conclusion ⇈

There are an awful lot static site generators out there, implemented in almost any programming language and offering varying degrees of customizability. I decided to build my own because over the years I never found any that was both minimal (as in simple, self-contained, and without a ton of dependencies) and highly extensible. Plus, I really wanted to reuse what I already implemented in HastyScribe: a powerful markdown processor with support for content-reuse features like snippets and macros.

HastySite may never become as popular as Jekyll or Nanoc, but at least it is something that fits my needs perfectly, which is what matters the most right now. At present, I use HastyScribe to power the following web sites:

• https://h3rald.com
• https://hastysite.h3rald.com
• https://min-lang.org

If you want to build something similar, or if you —like me— didn’t find a static site generator that fitted your needs, you should definitely give HastySite a try!

Lately I have become more and more interested in client-side single-page applications. Nowadays you can write your web apps in Javascript using your favorite framework, without any server-side logic, but you obviously still need:

• some web service to retrieve and persist your application data.
• a web server to serve the source code and the static assets of your web application.

NodeJS is probably one of the easiest backend to setup for prototyping SPAs. It is very easy to create a simple web server in Node and to implement a simple REST API using Express or a similar framework, but you still need to install node and write some code to wire up your backend.

I wanted something even more lazy then that. I wanted a fully self-contained program able to:

• Serve static files
• Act as a simple JSON document store
• Provide a simple REST API to work with
• (bonus!) provide a way to pack web apps for easy distribution

…and that’s how I ended up developing LiteStore.

LiteStore is a lightweight, self-contained, RESTful, searchable, multi-format, NoSQL document store and web server. That sounds pretentious, but it is essentially an accurate description of what LiteStore is and does.

It is built using the Nim programming language and its Administration App (see below) is built using Mithril, two relatively less-known projects, both of which I highly recommend if you want to take a break from more mainstream programming languages like C# or Java and Javascript frameworks like AngularJS or React.

Downloading LiteStore ⇈

The easiest way to understand what LiteStore does, is to try it out. Simply download a release package from the GitHub repo (or from here for your convenience) that is suitable for your operating system and architecture.

The release package contains the following files:

• litestore / litestore.exe — The LiteStore executable.
• LiteStore_UserGuide.html — The official user guide describing the program, its usage, architecture, API, etc.
• data.db — The default data store file, containing the LiteStore Administration App.

That’s all. No libraries to download, no installers, just an executable file. I love self-contained programs.

Running LiteStore ⇈

To start a LiteStore server with the default settings:

1. Open a command prompt in the directory containing the LiteStore executable and the data.db data store file.
2. Enter litestore in the command prompt.

or (on Windows):

1. Double-click litestore.exe

You should get a message similar to the following:

2015-09-20 @ 05:03:36 INFO: LiteStore v1.0.0 started on 127.0.0.1:9500.

…meaning that LiteStore is running on the specified address.

If you open a browser and type http://localhost:9500 you should get the following JSON response:

/bin/sh: chroma: not found

Congrats, LiteStore is up and running!

Digging Deeper… ⇈

LiteStore is, first and foremost, a RESTful document store. Think CouchDb or MongoDb, but smaller, much smaller. Here’s basically what happens when you run the litestore command:

1. LiteStore checks for a file named data.db within the current directory and creates one if it doesn’t exists.
2. LiteStore assumes that such file is a properly-formatted LiteStore data store file and tries to connect to it.
3. If all goes well, LiteStore starts a simple HTTP server on port 9500, ready to receive HTTP requests.

(The path of the data store file, the port, etc. are all configurable settings — run litestore -h for more details)

Now, if you access http://localhost:9500 while LiteStore is running, you’ll get JSON response listing some stats about the currently-loaded data store file, and some information on stored documents and tags, if any. The data.db file that ships with LiteStore already contains some documents. Well, actually it contains a web application to administer LiteStore itself.

The LiteStore Administration App ⇈

Now try accessing the following URL:

http://localhost:9500/docs/admin/index.html

If all goes well, you should see the following page:

You are now viewing the LiteStore Administration App, a simple single-page application implemented on top of the Mithril Javascript framework. The cool part is that this application is stored within the data.db file and is being served by LiteStore itself.

The LiteStore Administration App is an example of single-page application developed for LiteStore: it uses pretty much all LiteStore functionalities that are exposes by the LiteStore REST API.

On the home page you can see the same stats displayed on LiteStore root URL (http://localhost:9500), but you can also click any of the tag links to view documents by tag:

…and clicking a document title will display the document content and tags:

Note that it is also possible to create, upload, edit or delete documents and manage tags:

But perhaps the best feature of this web app (and of LiteStore itself) is the full-text search capability:

By leveraging LiteStore search API (which in turn leverages SQLite exceptional FTS4 extension), it is pretty easy to build fast search-oriented web applications.

Under the Hood ⇈

By now you are probably wonder how this whole thing can work. This is best explained with a simple exercise: let’s export and re-import the Administration App!

First of all, stop the LiteStore instance by pressing CTRL+C within the prompt window.

Now execute the following command, from the same directory where you started LiteStore:

LiteStore will create a directory called admin. If you browse its contents, you will find the full source code and assets of the LiteStore Administration App (also available in the LiteStore Github repo).

Now delete the data.db file. Don’t worry, you can always get a new one from a release package, at worst.

Run LiteStore again, with no parameters:

If you access http://localhost:9500 in your browser, you’ll get the following response:

/bin/sh: chroma: not found

This is basically saying that the datastore file is empty. And indeed LiteStore just created a new data.db file. If you try accessing the URL of the Administration App (http://localhost:9500/docs/admin/index.html) you won’t go very far:

/bin/sh: chroma: not found

As expected, because the datastore file is empty.

Now stop LiteStore and execute the following command:

This command will import the contents of the admin folder into the datastore file, creating documents and tags automatically.

If you run LiteStore again, you’ll see that everything is back in order, and you can access the Administration App again.

The HTTP REST API ⇈

The HTTP REST API exposed by LiteStore allows you to retrieve documents in their original content type, so for example:

• http://localhost:9500/docs/admin/index.html retrieves the contents of the admin/index.html document in HTML format.
• http://localhost:9500/docs/admin/index.html?raw=true retrieves the admin/index.html document in raw (JSON) format.

This is why when you access the first URL you are able to see the app.

Queries that return a list of documents, on the other hand, always return a JSON response. For example, http://localhost:9500/docs?tags=$subtype:css&contents=false returns all the documents whose subtype is set to css (without displaying their contents in this case):

/bin/sh: chroma: not found

For all the details on the HTTP REST API, see the guide.

Conclusion ⇈

LiteStore does not aim to be the next big thing in the NoSQL document store landscape, but it shines when used as a simple and smart way to prototype single-page applications, or implement personal apps like a local Wiki.

Personally, I use it whenever I have to prepare a quick demo for a proof-of-concept SPA, and I don’t want to have to worry about the backend. The Administration App is a great starting point to see how to use the LiteStore API to build an application. Even if you don’t have any experience with the Mithril framework (neither did I until I built this!), you can have a look at the models.js file to see how to access pretty much every functionality exposed by the API. I also managed to wire up a quick and dirty AngularJS service to do something similar, and it wasn’t too hard.

I hope some of you will find LiteStore useful and will give it a shot. If you want to contribute, feel free to fork the repo and send me a pull request. It would be great to have some Mithril or Nim expert to have a look at this and improve it!

Credits ⇈

Special thanks to the following individuals, communities and organizations that made LiteStore possible:

• Dwayne Richard Hipp and all the contributors to SQLite, the true gem that powers LiteStore.
• Andreas Rumpf and all the contributors to the Nim Programming Language, used to develop LiteStore.
• Leo Horie, for creating the Mithril Javascript Framework, used to develop the LiteStore Administration App.
• The creators and contributors to the Bootstrap CSS and Javascript framework, used by the LiteStore Administration App.
• The creators and contributors to the Ace Editor, used by the LiteStore Administration App.
• Cristopher Jeffrey and all the contributors to the Marked Javascript Library used by the LiteStore Administration App.