Pitfalls of Safe Rust

“as” is a good example. Floats are pretty much the only reason PartialEq exists, so why can’t we have a guaranteed-not-NaN-nor-inf type in std and use that everywhere? Why not make wrapping integers a panic even in release mode? Why not have proper dependent types (e.g. to remove bound checks), and proper linear types (to enforce that object destructors always run)?

It’s easy to forget that Rust is not an ideal language, but rather a very pragmatic one, and sometimes correctness loses in favour of some other goals.

As Rust is both evolving and spreading wide, we; the programmers, users of Rust; are also leveling up in how we approach correctness and design with it.

Maybe the next evolution will be something like Haskell but fast like Rust is fast like C without the pain of C++.

But it takes a while for the world to catch up, and for everybody to explore and find ways to work with or around the abstractions that helps with correctness.

It's a bit like the evolution from a pointer to some malloc memory, then the shared/unique pointer of C++, to the fully safe box/(a)rc of Rust.

It might be obvious today how much more efficient it is programming with those abstractions.

I see some similarities with functional programming that still seems so niche. Even though the enlighteneds swears by it. And now we actually seem to be slowly merging the best parts of functional and imperative together somehow.

So maybe we are actually evolving programming as a species. And Rust happens to be one of the best scaffold at this point in history.

Thank you for reading my essay.