Yeah I think people like to match the values of a programming language to ourselves as people. (And by values I mean, correctness, speed, expressiveness, velocity, etc). Like, I’ll pick the values which I like the most and find languages which match the values I aspire towards. Eg maybe I like the idea of my programs being strongly typechecked without sacrificing speed - so I program in rust. Then I write clean rust code even when I’m doing a quick and dirty prototype.
The better & harder approach matches a language’s virtues to the problem at hand. Strict correctness doesn’t matter much for a hobby program like this - moving fast and having fun are probably more important here. Expressing that with your tools might mean using Zig, or using rust but being sloppy with allocations and .clone() because it’s fine. Or treating rust like C and using unsafe everywhere. “Making invalid states inexpressible” isn’t that important in a fun side project - unless maybe that’s fun for you!
The right question isn’t “What is my favourite tool?”. It’s “If this project had a soul, how would it want to express itself through code?”
> The right question isn’t “What is my favourite tool?”. It’s “If this project had a soul, how would it want to express itself through code?”
I somewhat disagree. What you're saying is basically "pick the right tool for the job", but more poetically (not a criticism, BTW, I like your phrasing).
But what I think this is missing is that the "right" tool is at least in part based on your favorite tools are.
Or to put it differently, using a tool that may be suboptimal for the job, but which you know extremely well, may be better than using a tool you don't know which is optimal for the job.
Of course, this is much less of an issue for hobby projects, and if one of your goals for a project is "learn new stuff" (a goal I often have for my own hobby projects), then picking the optimal language may be exactly the right choice. You get to learn a new thing while not fighting with the language.
I had a think about this and I agree. There’s some tension here - you want breadth, but you don’t have enough time to get good at every language and framework. Maybe the right approach is to have familiar ground in each domain you find yourself. Pick enough languages and frameworks so you have trails in any terrain you want to tread with your work. You don’t need to be an expert in both php and rails, in both Java and C#, or both unity and unreal. But you want enough scope that if you want to throw together a quick and dirty UI prototype, you have familiar tooling you can call your own.
For me, when I want to make a quick UI prototype I reach for JS and Svelte. Because I’m comfortable there, its not worth it to also be an expert at rails, and Php and SwiftUI and C#/WPF. But if the only tool in my toolbox was Rust, or C, or Unity or something, I’d be much worse at prototyping user interfaces. The inverse is also true - if I wanted to write a database but only knew JS, I’d be in for a rough time. You want a home base in each domain.
The better & harder approach matches a language’s virtues to the problem at hand. Strict correctness doesn’t matter much for a hobby program like this - moving fast and having fun are probably more important here. Expressing that with your tools might mean using Zig, or using rust but being sloppy with allocations and .clone() because it’s fine. Or treating rust like C and using unsafe everywhere. “Making invalid states inexpressible” isn’t that important in a fun side project - unless maybe that’s fun for you!
The right question isn’t “What is my favourite tool?”. It’s “If this project had a soul, how would it want to express itself through code?”