Why mimas?

mimas is a side project, and a young one. It isn’t trying to win you away from a language you already trust – those have communities, libraries, and years of polish mimas can’t pretend to match. This page is instead about why I keep building it, and the north star I steer by while I do. It centers around a trade I’m tired of making.

The trade

Plenty of projects end up wanting two languages. You build the serious part – the engine, the core, the thing that has to be fast and correct – in something strict and heavy. Then, when you want to move, to describe behavior, try an idea, change something and see it a second later, you reach for a scripting layer on top.

That second layer is where the trade lives. Scripting layers tend to commit hard to flexibility at the expense of saftey. They’re forgiving right up until they aren’t, when you slam into a runtime error from a trivial mistake.

This has been a constant headache throughout my career in game development, and one with real consequences; games have enormous performance demands while also needing to be remarkably robust. There isn’t much room to recover from an error mid-gameplay. You can wrap the unstable parts and pray, but catching an error you didn’t model is the same as throwing it out and hoping no broken state leaked to the surface as something far harder to trace. In the end, it feels as though I’m spending more time untangling cryptic crashes than I am actually making games.

mimas is my detox from those frusterations: a fun, snappy programming experience without gnashing my teeth at a crash from a typo the compiler absolutely should have been capable of warning me about.

Coach, not cop

The only path towards such a language is a series of calculated compromises. We’re not going to produce some magical language that lets us program with our eyes closed yet still fulfill a borrow checker – instead, each part of the language needs to weigh the ergonomics and the saftey. Will this frustrate me when I’m just trying to write something quick? Will this come back to haunt me at runtime? Each choice swings a little bit in one direction or the other, our ethos is to try to stay upright on that tightrope.

Ultimately, that has turned out to look a lot more like Rust than Python, just with certain pieces removed. Some are to increase flexibility (garbage collection instead of a borrow checker, no immutability beyond const decalartions). Others are to reduce complexity, both for the compiler and the programmer (no references or pointers, no lifetimes to annotate). We start from safety and walk only as far away as we must to reach the flexibility we expect, and to keep recompiling in the blink of an eye.

In 0.1.0 the ergonomics come first, and speed is a longer project. mimas is already in the right ballpark in its benchmarks, but there’s plenty of headroom left to chase as it grows.

A small, clear target

None of this is a new wish. Wanting expressiveness, safety, and a fast loop all at once is a familiar itch, and people wiser than me have spent whole careers reaching for pieces of it (Mun, in particular, has made terrific headway in this effort). That said, sitting with a question others have sat with doesn’t make it any less fun, and that’s reason enough.

mimas is named after one of Saturn’s smallest moons – which is, in turn, named after a giant from Greek mythology. If a little language tacking a big problem sounds like fun to you too, I’d be thrilled to have your stubborn thoughts and contributions along the way.