I'm confused about how it's hard to craft transmute trickery to eliminate overhead. Transmute should be zero-overhead...
It is the mental and the syntactic overhead. For a simple reference to say my framebuffer can become more complicated than they should need to be.
Re:You can't Rust that
by anewhnaccount2 on Sunday April 01, 2018 @02:53AM
(#16727112)
For exposing a safe subset of transmutes, there's https://github.com/nabijaczleweli/safe-transmute-rs
I don't like it's API at the moment, but perhaps it could be turned into something nicer?
Re:You can't Rust that
by burntsushi on Sunday April 01, 2018 @10:03AM
(#16728301)
Please don't use that crate. From what I can tell, it is not actually exposing safe routines and gets things wrong. I've filed issues in the past, and I've just now filed a couple more.
And then comes a point where you realize that you need to write _some_ low level code that is unsafe. You read a lot about unsafe Rust and it almost allows you to almost work as if you are working with C. You can transmute a reference to native pointer type and then transmute it back as a mutable reference with a static lifetime if you want. But at that point you have lost the safeties and now you have to know exactly how to craft your transmute trickery such that you know there will be little to no overhead.
Perhaps it all comes down to the borrow checker being less strict about things. I can't tell exactly in which ways, perhaps about the lifetimes of references. Something doesn't feel as natural to reason about working in Rust as it does in C but I can't put my finger on it.
One thing I can say though is I wish I didn't need to use lazy static for non-primitive static globals.
But overall I really like the general direction that the language is heading. Love the way dependencies are managed although TOML wasn't the best format choice in my mind. crates.io, docs.rs and the entire community and the ecosystem are great and unique too.