5 ms·
"Rust is still unstable, so it will therefore never be stable" "There were X new features in Rust's sixth year. I will now compare that to the count of new fea
by jbreckmckye 6y ago
"Rust is still unstable, so it will therefore never be stable"
"There were X new features in Rust's sixth year. I will now compare that to the count of new features in C's forty-eighth year"
"People who are using new tools are interested in 'shiny' things. I am using the word 'shiny' to suggest that their motives are cognitive weakness and neophilia. It cannot be that these developers have contexts and needs I have not yet reasoned about."
"I don't care about safety and segfaults, which means no-one should. I am never involved in safety critical software and therefore safety features are not useful."
And finally, if I may make a cheap shot:
"I would like to mount a robust defence of C based on its spec, well known for lack of Undefined Behaviour"
- santoshalper 6y agoYour first 3 points are collectively true and a fair rebuttal. That absolutely does not change the fact that the level of instability in Rust would make me very uncomfortable to use it for anything I want to last very long right now. I am not obligated to be fair to my tools when I choose them. C is profoundly stable, and that is a great asset for long-lived systems.
- derefr 6y agoRust has stable features, and unstable features. Code you wrote to target only the stable features is never going to have to change. There's a lot of Rust code in the wild (e.g. libraries) that targets unstable features. That adoption is necessary, just like drug trials are necessary: people need to actually use something, to figure out whether it's good, and/or what needs to be changed about it. Most of the time, though, an unstable feature that gets used a lot, is stabilized exactly as-is—both because the huge usage proves that people are happy with it working that way; and because there's now a lot of code in the wild depending on that feature, and it'd be a shame to break it all without an excellent justification. This means that these libraries that were "only usable on nightly" because they used a popular unstable feature, tend to become stable libraries, without having to do anything at all. And it's pretty easy to predict that this is the way things will go (just by looking at usage numbers), and so start using such libraries "early." There's very little risk of breakage introduced by doing so. It's not like there are features everyone begins depending on in Rust, that just suddenly disappear one day. Not even unstable ones. There are just (unstable) features that nobody likes or uses, and so they get changed or go away. But if nobody liked them (including you), then what does it matter whether they went away? You wouldn't have used those (again, unstable) features in the first place. Libraries wouldn't have used them either, so you wouldn't have used them even transitively. Such (unstable!) features just wouldn't exist/matter to you. If their going-away was a problem, that would mean somebody liked them enough to put them into something crucial... which means they weren't that unpopular after all, and shouldn't go away. (Or, at least, it means the author of a critical library is stubborn/malicious, and in need of either a stern talking-to or a project-fork.) It's basically the same as having pre-1.0 packages in a package ecosystem. The popular ones mature. The unpopular ones sometimes mature, and sometimes die. But the unpopular ones are unpopular, so it's very unlikely you were depending on them. (And if you were, you knew exactly what you were getting yourself into.) So what does it matter if they die?
- buzzkillington 6y agoIf I wanted stable and safe I'd use Ada. You're still not selling me on Rust.
- spider-mario 6y ago“Fearless concurrency means adding plenty of bugs.” Well actually, it’s made to be safer, that’s why it’s fearless. “I don’t care that it’s safer.” ???