Are you writing lots of FFI and/or embedded code? Those are the main places I see unsafe being used a lot.
The tooling and the encapsulation go hand in hand.
> The idea that you will convince people not to write broken unsafe code, in ways that breaks safe APIs, or that the ability to assign blame matters, is very strange to me, and is no better than C. As systems grow, the likelihood of totally safe transmutes growing in them is basically 100% :)
To be honest this doesn't track with my experience at all. Unsafe just isn't that commonly used in projects I contribute to. When it is, it is aggressively encapsulated.
Yes - I spend about half my time with rust embedded, where unsafe code is just everywhere, whether needed or not.
There is still plenty in my non-embedded stuff, but a fair amount hardware-adjacent (IE i have to drive things like relay cards, just from a desktop machine). to be fair.
But i've found plenty of broken unafe in things like, uh, constraint solvers.
I would agree that useful and successful rust projects aggressively encapsulate (and attempt to avoid) unsafe usage.
I will still maintain my belief that this will not be enough over time and scale.
The tooling and the encapsulation go hand in hand.
> The idea that you will convince people not to write broken unsafe code, in ways that breaks safe APIs, or that the ability to assign blame matters, is very strange to me, and is no better than C. As systems grow, the likelihood of totally safe transmutes growing in them is basically 100% :)
To be honest this doesn't track with my experience at all. Unsafe just isn't that commonly used in projects I contribute to. When it is, it is aggressively encapsulated.