this post was submitted on 31 Aug 2023
1 points (100.0% liked)
Rust
5960 readers
2 users here now
Welcome to the Rust community! This is a place to discuss about the Rust programming language.
Wormhole
Credits
- The icon is a modified version of the official rust logo (changing the colors to a gradient and black background)
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
I can only speak out of my own experience, which is mostly C++, C#, C and Rust, but I also know a bit of Haskell, Java, Fortran, PHP, Visual Basic, and, to my deepest regret, also JavaScript.
For additional context: I have been working in game development for the last 7 years, my main language is C++ for Unreal, but I've also worked on some Unity projects with C# as main language. Before I switched to game dev I worked in material science, and used C, mostly. I use Rust for my spare time projects, and the game company I work at is planning to introduce it into our Unreal projects some point later this year.
Of all the languages I mentioned above, (Safe) Rust and Haskell are the only ones that have not yet made me scream at my PC, or hit my head against the desk.
So, some of the reasons why I personally love Rust:
The points mentioned above mostly apply to Safe Rust though. Unsafe Rust is a different story.
This brings us to the downsides. Rust isn't perfect. Far from it, actually. Here are some of the things that aren't great about Rust.
async
keyword in the language itself.However, the upsides clearly outweigh the downsides imho.
tl;dr If a (Safe) Rust program compiles, chances are pretty high that it also works. This makes programming with it quite enjoyable.
For downsides, i'd like to add that the lack of function overloading and default parameters can be really obnoxious and lead to [stupid ugly garbage].
A funny one i found in the standard library is in
time::Duration
.Duration::as_nanos()
returns a u128,Duration::from_nanos()
only accepts a u64. That means you need to explicitly downcast and possibly lose data to make a Duration after any transformations you did.They cant change
from_nanos()
to accept u128 instead because that's breaking since type casting upwards has to be explicit too (for some reason). The only solution then is to make afrom_nanos_u128()
which is both ugly, and leaves the 64 bit variant hanging there like a vestigial limb.Note though that it's perfectly fine to have multiple mutable raw pointers pointing to the same data, as long as there’s no ownership held by any Rust code. The problem only happens if you try to convert them into references.
It seems I misunderstood something important here. I'd take that as proof that Unsafe Rust is rarely needed. 😜 A quick test on the Playground shows that indeed, using raw pointers does not yield the wrong result, while using references does: https://play.rust-lang.org/?version=stable&mode=release&edition=2021&gist=96f80d43d71a73018f23705d74b7e21d
Conclusion: Unsafe Rust is not as difficult as I thought.
I left something important out from my explanation. Your example still holds ownership of the data, so that’s where the rules are violated with those raw pointers. You have to use
Box::into_raw
or something similar to disassociate the data from the Rust compiler. Then you can alias it using raw pointers.