Remix clone Hacker News

Safe programs extend beyond those that Rust's borrow checker accepts though. There is more than one way to make a program safe, not all of them would be valid Rust.

▲

goku12 14 hours ago | parent [-]

There are more than one way to achieve safety in Rust. Two more, infact - runtime safety and fully manual (unsafe with some additional work). Runtime safety is a very fast way to overcome the resistance offered by the borrow checker. While it does slowdown the code a little bit, that should be pretty fine for prototyping. A more careful use of runtime checks will still give you a program more performant than in most other languages.

▲

dzaima 11 hours ago | parent [-]

Runtime safety still comes with a good amount of complication source-wise, having to spam RefCell/Arc everywhere, and whatever derefs/.get()s they necessitate, and probably a different approach to passing references. Refactoring either that or unsafe away after being done with prototyping isn't trivial, if even possible without entirely rethinking the approach.

▲

goku12 7 hours ago | parent [-]

Isn't that a bit dramatic? How much extra code or care do you need to implement runtime safety checks? This isn't the first time I hear these sort of arguments either. It gives the impression that a crowd is making up one exaggeration after another to drive the perception that Rust is somehow not suitable for general purpose programming.

	▲	dzaima 7 hours ago \| parent [-]
		It is a bit dramatic, though less so for some approaches to programming. And of course prototyping is very different from general purpose programming. With Rust, if you really want the borrow checker to actually never bother you, you really do just have to spam the dynamically-checked wrappers everywhere; when in the groove, having to stop and wrap some existing field (or its holder) and all its usages just to be able to mutate it because you previously didn't think you'd need to is just completely awful if you don't find that "fun". Whereas in C, if you want to mutate a thing, you can always do so whenever with no concerns (whereas using unsafe to mutate a field of a &Thing in Rust is just UB, though maybe you can get away with using unoptimized builds for a bit) and deal with previous code that may have been written with the assumption it wouldn't change Later™ (but, importantly, still allowing properly testing the modified thing, and perhaps the entire project). Want to change the lifetime of a thing? Just move where you free it, no need to ever change lifetime args across a dozen functions. And in Java the most anything may take is removing a "final" on a field.