Why I Never Learned Rust

Back to developer content. Midterm season is passing and now we're in the finals push, which Dartmouth gives me a lot of time for.

I have maybe thirty minutes of Rust experience. I could probably read it and understand it. But I never dived into it like I did with C.

I actually came close to learning it when I was making cmdfx. It would've been a lot easier, a lot simpler, a lot more "memory safe" to try and use it. But I never really decided that I liked it, felt I needed it, and felt I wanted to use it.

Limits of Learning

I have learned all of the programming languages I needed to learn.

That's a weird thing to say as an undergraduate freshman. I'm working on drupflare and gmux, both technologically ambitious and advanced projects that could probably benefit with some Rust or more system knowledge. But I already know C, and could probably scrape by with some intermediate C++. The easiest answer was that I never really needed to learn it, and when I had opportunities to learn it, I had already gotten some experience with trying to learn something else that would have arguably fit better.

I had known a little bit of C by the time I started my winter break project during junior year of high school to start cmdfx. I wanted to learn a lot about the intricate details of system work and terminal work, and work with a lot of low level functions; especially since I learned a lot from making Terminal Miner when I was 13. C had just survived its 50th anniversary when I started doing some toy system work in replit (back when it was good, im still mad that they trashed all of those middle school projects) and I took a liking to master it. And then I got pretty good at it, felt satisfied, and moved on.

Technical Decision-Making

My work now is increasingly AI-directed and assisted. This means that, despite being able to be like "claude, rewrite this in Rust," I wouldn't be able to investigate the low-level details about what exactly is going on. If gmux was implemented in Rust, how can I validate the code it's doing, make decisions when it asks me an architectural or design decision is needed, know how the compiler mechanism to WebAssembly works for the serverless imports, or anything unique to Rust that requires a technical decision?

That's what usually separates slop from something good, when it looks put together and by someone that has no idea what they're doing. Drupflare almost turned into that, until I realized it had a file that was 80k+ lines of code and I had it split it up and properly organize it and document it like a real project. I tell it to implement tests and integration gates in a very specific way. I never learned Rust because I never really needed to, and if I try to now, there isn't really a reason or purpose to do it, and it'd need to be adaptable to this process to sustain the sheer speed of which I continue releasing stuff.

For What?

I think all of my projects, at least at this stage, need to solve a problem, or at least, do something. Even Drift, which I made as my submission to KotlinConf 2027, has practicality in debugging a drangler CI issue that was rooted to a networking difference or something like that.

I guess I've never really come up with something that would specifically require Rust. I have Vue/Nuxt for websites, Kotlin for desktop, C for systems, and a bunch of other backups for these use cases like PHP, TypeScript, Kotlin/Native, or whatever else. So I never learned it because I just didn't need to, and I don't feel a need to anytime soon.