Pondering hobby stacks for 2025

· Michael Dingler


Right now I’ve got less time1 for side projects than I want to, but that’s probably going to change soon. I’m being pulled in two directions, and if that ends I’m either not programming at all for work (which hasn’t happened for 20 years now), or I’m just doing some enterprisey Go/Typescript, where I’d need a more “humane” alternative.

A while ago, I wrote the following on IZZZI:

Speaking of which, “tech stacks” I want to try out before I settle on something for a side project in 2025:

  • GUIs in Qt and very old-fashioned Objective-C

  • Gamedev with SBCL/Raylib and DragonRuby

  • non-work-alike webdev with Ruby & Elixir

All those are oriented towards something I don’t have at work, and all quite less statically typed. I still have rose-tinted memories of not having all those problems others fight with category theory, Rust and Haskell, let’s see if that’s really the case.

GUIs #

I like desktop GUIs a lot. Or at least those of the past. Apple’s OS X Human Interface Guidelines still are the gold standard, with almost perfect proportions and whitespace. Compared to that, today’s mobile-influenced desktops are empty wastelands and full of mystery meat (or in other words, “UX” got a lot worse since we had the term “UX”).

But it’s not all over, so this isn’t purely retrocomputing yet. The tech stack should produce something that might actually be interesting for others, and not just run on ancient platforms or require huge runtimes.

I quite like Tcl and Tk, but ruled out purely scripted languages. I also don’t care for immediate-mode frameworks like Dear ImgUI, as they tend to be rather unpolished, more suited for game GUIs or something that only programmers could love. There’s a decent Rust/Fltk combination, but that would be Linux only, and currently I’m not in the mood for Rust, either.

I feel pretty settled here, as there currently aren’t any interesting alternatives.

Gamedev #

I last did some semi-serious game development in the 90s, which meant replicating bad 3D engine stuff that’s now generations out of date and fully done by engines. I can’t compete with that, I can’t even do decent 2D pixel art. So this will definitely be a more exploratory hobby project, not likely to enchant the masses.

And thus I opted for more “weird” tech stacks. I’ve got a DragonRuby license since forever, probably because of some itch.io charity bundle. I liked Ruby a lot in the past, and this seems like a quick enough 2D gamekit with a good developer experience.

Raylib is a very common game development library, more for rolling your own than with “batteries included”. But that would be enough for a 2D game. The good thing about it is its plethora of language bindings. Steel Bank Common Lisp is a very professional Common Lisp compiler and interpreter, and I’ve always wanted to do more with that language.

This is a field with soo many options, and I need a decent game idea before I start (thinking about a Ultima-like RPG right now). This leaves a lot of room for distracting alternative engines, from complete ones like Godot to more languages for 2D bindings.

Webdev #

I do that for work, but it’s a good way to provide some small utilities for personal or “world-wide” usage, with a much shorter development cycle than a proper desktop application. But I don’t want to repeat the same kind of things I’m doing at work. But again, sooo many options.

What I picked here, was basically the first two things that came to mind right when I wrote the IZZZI post:

Right now it looks like Ruby is going to make it, but I’m going to give Elixir/Phoenix a short try. If that has a really well done development speed, it might be worth having to learn a new language.

This is more about getting something usable done, and I’ve got more ideas about web apps than other items on this list. Thus practicality might overrule those choices. Now that I’m doing Go at work, a very simple Java approach (Javalin?) might even work, as the tooling is quite excellent. Who knows, even old steadfast Perl could be an option2.


I’m mostly writing this down for my own future reference, and to further force me to stick with those choices I made already. There’s still too much wiggle room, but that’s modern development.

If you want to suggest your favorite stack for one of those areas, feel free to contact me.


  1. And, to be fair, discipline. ↩︎

  2. But definitely no Javascript. It’s not just the language, but also the frontend/backend split. This way I don’t have to context switch all the time and can have a more “messy” endpoint setup. ↩︎

last updated: