There's a constant focus on backward compatibility, but the (equally constant) feature creep will inevitably break it. English hasn't moved from version 3.x for centuries, and we still have multiple redefined keywords, many modern compilers have dropped support for outdated constructs which -- though legal -- haven't been in use for ages, and in fact the very language has several different implementations with varying levels of mutual compatibility.
Please do not publish this one, (EDIT2: I don't think it's worth publishing) I just fond the slip of the tongue very funny!
EDIT: this post has been flagged as off-topic. I would have like to know why. This is a citation, about Rust, from a very interesting conference, and I selected it because it was funny. And while I think its not worth publishing it in TWIR because it doesn’t bring any new insight about Rust, I think it has its place in this thread for the pleasure of people that propose and vote for TWIR citations.
This thread is for submitting Quotes of the Week for This Week in Rust. If you don’t want your quote to be published, then it probably doesn’t belong here (though TWiR quotes that are just funny have been published before).
(The elision there is to avoid making any commentary on the actual issue in that topic part of the quote; in general, I think we should avoid highlighting quotes that directly comment on one side of an active topic, so I left that part out.)
I’m saddened to think that because this industry has an obsession with making programming accessible to the lowest common denominator, expressive and innovative languages like Rust will fall by the wayside, and we’ll all be writing code in languages like Go and Python in the future because they’re “easy” and even high schoolers can learn them in a couple days.
The context of that thread is already interesting on its own, but I even think that taking that quote seriously / in a first degree fashion is actually meaningful: for some codebases written from scratch and which developed features out of an initially thin core, the newly obtained perspective on the problem ought to make rewriting that codebase "from scratch" yield cleaner, leaner, and potentially faster code (and back to that RiiR thread, hence why sometimes the Ri part may be just as important if not more important than the iR part).
I see a lot of “we rewrote X in Rust and it got faster” posts. I think that if you rewrite anything from scratch with performance in mind, you’ll see a significant performance improvement. I’m suspicious of how much Rust itself is needed versus the developers having some performance discipline.
So why aren't we all fuzzing security-sensitive surfaces, at least for a modest number of cycles? Well that comes down to the difference between apes and programmers: apes know when they should be using tools.