Comment by netbioserror
9 months ago
I use Nim at work. It is a joy. I replaced a prototype Rust application which was confirmedly not a joy. None of Rust's highly opinionated safety semantics necessarily imply a better end product, and often make delivering an end product much more difficult. Rust has use cases, but it is a specialized hammer for a specific domain of nails. It is not the cure-all everyone wants it to be.
If you're asking if you should use Rust and you don't have a highly specific embedded use case, you should probably just use a language with decent RC or GC. As an additional bonus, 99.9% of the code you write in a GC language never has to be about memory at all. Business logic, clean and bare.
> As an additional bonus, 99.9% of the code you write in a GC language never has to be about memory at all.
This is a bit of an oversimplification. If you are sloppy with "memory management" (unnecessary object lifetimes, unnecessary duplication, etc) even in a GC language, it is possible to have noticeable performance impacts. I'm not saying these languages aren't the right tool for the job, but it is not a free pass to ignore hardware limitations.
Yes, but that's only true for long-running applications. Most gigantic monolithic web server applications, for example, do not need to be gigantic monolithic web server applications.
My Nim CLI application does a subset of common tasks, outputs to stdout, and is invoked by our PHP server for each task. It (and the Rust and C programs it replaced) can barely blip a fraction of a percent amount of system memory in the worst case. Why did it need to be in C or Rust? It was never necessary, and I've been able to load it with features they never had but always wanted, in astoundingly short order.
Architecting these sorts of services properly can assist in making tool choices that drastically boost maintainability and feature delivery, especially for small teams; meanwhile, entire classes of problems melt away.
> Architecting these sorts of services properly can assist in making tool choices that drastically boost maintainability and feature delivery, especially for small teams
I hate hearing this argument, because it glosses over the hard realities of building products, even if it sounds good on paper. Companies don't often have the resources to hire people that can do this early on, or the time to do this early on even if they do have the talent. And it might not be correct to do so when you have uncertain future requirements.
If that talent is you, you might not even be trusted to make those kinds of decisions until a year or two of tenure. And you might have junior (or even 'senior') devs on the side making changes that make this harder to do, without anyone realizing it.
So the reality is that you can't expect systems to be "architected properly" and you get what you get. It's an incremental process.
2 replies →