The Paradox of Learning Rust

This past weekend, I wanted to make a small toy project that just connects JavaScript to SDL3 with a simple API. The goal was for it to be quick and simple and fun, and once hello world worked, build on it as needed.

This comedic post documented my first attempts to get it working, an entire few days of trying various C++ setups, with every single one of them almost working, but each falling short in some spectacular way.

Somehow, using Rust just worked from every perspective, from the bundler working with every package I tried (including successfully using both rquickjs and v8), to the compile tools properly waiting for each other.

In other words, I was essentially forced to use Rust by the mere fact that nothing else worked, but also because Rust worked so seamlessly and immediately. I was so excited about it working that I soon after wrote this post requesting that people sponsor me continuing to work on it.

But it’s a very frustrating language, and I mean that in the most literal sense, that it frustrates all my plans with it. I took out this frustration in another comedic post. Apparently I deal with frustrations via highly niche humor?

The problem is that I don’t know the language, so lifetimes and borrow rules are new to me. Yet in writing a very complicted first program, one that requires lots of pointers and unsafe code, I’m forced to already be an expert at these things.

This implies that I should start with a smaller program, one that requires much less knowledge of these things, and allows me to add them to my code as needed, which would allow me to learn them organically, in the sense that I would feel the need first, then use the solution to solve the need, allowing me to fully internalize its rationale through direct first-hand experience. This technique has served me well in the past.

But that’s the problem. This was meant to be that project. You can’t get your feet wet with a project unless it’s fun. And when your fun project is already too big for a starter, you’re forced to find another project than the one you want, and learn the ropes there. But it’s already a last resort, it’s not the one that lit a fire under you. In other words, I just want this project to be that one, and I’m even willing to trade out v8 for rquickjs again, but I just don’t think it will truly solve the issue.

Rust feels like a very heavy language. Half the time, the syntax is mysteriously short. The rest of the time, it’s obscenely verbose. The rules around pointers and mutability feel complex. And I don’t even have a clue what lifetimes are yet.

People who know C++ very well will say it’s more complex. I’m sure it is. I’m not trying to dismiss any of that. But having fully read through Stroustrup’s own book on it, I feel like it has a much more managable learning curve. With Rust, it seems like a literal cliff you’re at the bottom of. With C++, it feels like hiking up a mountain. Hard but doable. And with that cliff, you’re given maybe a rope or gloves.

We all know that people think C++ is a bad prototyping language, and that they’re wrong, any language is fine for prototyping, as long as you know very thoroughly how to use that language. People used to say dynamic languages were better for lack of types, yet I would never prototype in JavaScript today, but TypeScript.

Some minor inconveniences in C like lack of closures don’t help, but creating a few static structs fully makes up for that. Remember, it’s a prototype! It doens’t need to be good code. I won’t argue with people who say prototypes may become real, so write them with the same quality code you’d write in prod. I just completely disagree. Throw the code away, keep the lessons.

But Rust does not even allow this sort of experimental coding. It’s actively hostile toward that style of coding entirely. Rust is not forgiving if you don’t have a complete mental model of the entire program flow up front. Not to mention threads! Things just won’t compile if your prototype isn’t prod-ready. C++ at least lets me compile and crash if I was wrong. I need that cycle of compile/crash/fix in order to prototype.

If it weren’t for the build tools, I’d 100% be using C++ for this. If I could get { VS Code + quickjs + SDL3 } working at all, I would immediately abandon Rust and go back to C++ for this. I can’t comfortably work outside VS Code anymore. I just can’t. And yes, I’m aware that VS has a VSC key map. But only sort of. The rest of it, I don’t care about. MSVC vs clang vs gcc, whatever. I don’t mind vendoring it, I even tried that with quickjs, no luck.

I think I’ll just clone tic80, rip all of it out but quickjs + SDL2, get SDL3 working in its place, and use that as my starting point. Or maybe try for a fifth time to get it all working in WSL2.