Follow

re: C++ & Rust 

@amiloradovsky@functional.cafe

That's the usual justification for unsafe blocks. I think if the constraints are good fit for the use case, the players will have no incentive to switch to anything, and that's the only way to ensure safety, otherwise nothing will stop them, not to mention that unsafe is not the easy mode, it's the hard mode. Wood carving with a sharper knife is better, not because it can't cut you, but because you are less likely to make mistakes when everything is going smoothly.

The better language would have better primitives to allow the programmer to impose constraints where it matters and relax them where it doesn't. And yes I'll say the same about purity or immutability: applied across the board they are insufficient, and allowing exceptions diminishes their value, compared to them being optional.

Another common argument is that it's easier to pay attention to and keep track of unsafe blocks. IMO it isn't. If you break invariants, anything can go haywire anywhere at any time with no indication to any specific unsafe block. There is no mechanical process of ensuring integrity. At the end of the day people ensure it. You can create a super safe virtual machine, that as far as the processor or the kernel or any other "overseer" are concerned has no errors, but people can still make internal logic errors causing undefined behaviour worse than jumping to a random address.

Rust's borrow checker is cool, I like it and can't wait until a better version of it is implemented as a c++ library or two.

@newt

Sign in to participate in the conversation
Qoto Mastodon

QOTO: Question Others to Teach Ourselves
An inclusive, Academic Freedom, instance
All cultures welcome.
Hate speech and harassment strictly forbidden.