3 ms·
> I do not understand that if you are happy to have an invisible runtime run your programme why you do not want a garbage collector? Because a garbage collecto
by gwbas1c 2y ago
> I do not understand that if you are happy to have an invisible runtime run your programme why you do not want a garbage collector?
Because a garbage collector does not have an invisible runtime: The memory model is tightly coupled with the garbage collector. This is not zero-cost. All garbage collection comes with some cost; although for many kinds of programming it's so "worth it" that we don't need to consider alternatives.
As someone who's spent most of my career using garbage collected languages; I both appreciate the advantages that come with the tradeoffs of garbage collection; and the tradeoffs that come with Rust. Rust has no runtime memory management overhead, and no complicated framework to ship.
I still personally don't understand "why" async Rust is so hard. I struggled trying to use it, but at the time I was such a Rust novice that I "didn't know what I didn't know." Yes, async Rust would be easier if the language was garbage collected; but that defeats the point of Rust.
- gwbas1c 2y agoJust to follow up a bit: Rust excels at things like command-line utilities, or high-performance libraries (that don't require you to suck in a whole framework.) In these cases, the case for "async" isn't strong, because chances are there isn't enough concurrent IO to for async vs threaded to make a difference. If you're making a web application, chances are you're hosting it yourself. Thus, you don't have to "ship" your software and compel your users to load up whatever framework(s) you choose. IE, you can choose to use C# or Node.js, and decide that it's worth your time to spend more on hosting.