5 ms·

I've dabbled in Rust, liked it, heard it was bad so kind of paused. Now trying it again and still like it. I don't really get why people hate it so much. Ugly g

I've dabbled in Rust, liked it, heard it was bad so kind of paused. Now trying it again and still like it. I don't really get why people hate it so much. Ugly generics - same thing in C# and Typescript. Borrow checker - makes sense if you have done low level stuff before.

int_19h 1y ago
If you don't happen to come across some task that implies a data model that Rust is actively hostile towards (e.g. trees with backlinks, or more generally any kind of graph with cycles in it), borrow checker is not much of a hassle. But the moment you hit something like that, it becomes a massive pain, and requires either "unsafe" (which is strictly more dangerous than even C, never mind Zig) or patterns like using indices instead of pointers which are counter to high performance and effectively only serve to work around the borrow checker to shut it up.
- dwattttt 1y ago
  > the moment you hit something like that, it becomes a massive pain, and requires either "unsafe" (which is strictly more dangerous than even C, never mind Zig) or patterns like using indices instead of pointers If you need to make everything in-house this is the experience. For the majority though, the moment you require those things you reach for a crate that solves those problems.
- carlmr 1y ago
  >requires either "unsafe" (which is strictly more dangerous than even C, never mind Zig) Um, what? Unsafe Rust code still has a lot more safety checks applied than C. >It’s important to understand that unsafe doesn’t turn off the borrow checker or disable any of Rust’s other safety checks: if you use a reference in unsafe code, it will still be checked. The unsafe keyword only gives you access to these five features that are then not checked by the compiler for memory safety. You’ll still get some degree of safety inside of an unsafe block. https://doc.rust-lang.org/book/ch20-01-unsafe-rust.html https://doc.rust-lang.org/book/ch20-01-unsafe-rust.html
- Ar-Curunir 1y ago
  I’m sorry, but your comment is a whole lot of horseshit. Unsafe rust still has a bunch of checks C doesn’t have, and using indices into vectors is common code in high performance code (including Zig!)
- creata 1y ago
  > patterns like using indices instead of pointers which are counter to high performance Using indices isn't bad for performance. At the very least, it can massively cut down on memory usage (which is in turn good for performance) if you can use 16-bit or 32-bit indices instead of full 64-bit pointers. > "unsafe" (which is strictly more dangerous than even C, never mind Zig) Unsafe Rust is much safer than C. The only way I can imagine unsafe Rust being more dangerous than C is that you need to keep exception safety in mind in Rust, but not in C.
  - whytevuhuni 1y ago
    Not quite, you also need to keep pointer non-nullness, alignment and aliasing safety in Rust, which is very pervasive in Rust (all shared/mutable references) but very rare in C (the 'restricted' keyword). In Rust, it's not just using an invalid reference that causes UB, but their very creation, even if temporary. For example, since references have to always be aligned, the compiler can assume the pointer they were created from was also aligned, and so suddenly some ending bits from the pointer are ignored (since they must've been zero). And usually the point of unsafe is to make safe wrappers, so unafe Rust makes or interacts with safe shared/mutable references pretty often.
    - creata 1y ago
      It's just hard for me to imagine someone accidentally messing up nonnullness or aliasing, because it's really in-your-face that you need to be careful when constructing a reference unsafely. There are even idiomatic methods like ptr::as_ref to avoid accidentally creating null references.
- jplusequalt 1y ago
  >which is strictly more dangerous than even C, never mind Zig No it's not? The Rust burrow checker, the backbone of Rust's memory safety model, doesn't stop working when you drop into an unsafe block. From the Rust Book: >To switch to unsafe Rust, use the unsafe keyword and then start a new block that holds the unsafe code. You can take five actions in unsafe Rust that you can’t in safe Rust, which we call unsafe superpowers. Those superpowers include the ability to: Dereference a raw pointer Call an unsafe function or method Access or modify a mutable static variable Implement an unsafe trait Access fields of a union It’s important to understand that unsafe doesn’t turn off the borrow checker or disable any of Rust’s other safety checks: if you use a reference in unsafe code, it will still be checked. The unsafe keyword only gives you access to these five features that are then not checked by the compiler for memory safety. You’ll still get some degree of safety inside of an unsafe block.
  - int_19h 1y ago
    The reason why it's more unsafe than C is because Rust makes a lot more assumptions about e.g. lack of aliasing that C does not, which are incredibly easy to violate once you have raw pointers. Obviously if you can keep using references then it's not less safe, but if what you're doing can be done with references, why would you even be using `unsafe`?
- jplusequalt 1y ago
  >using indices instead of pointers which are counter to high performance Laughs in graphics programmer. You end up using indices to track data in buffers all the time when working with graphics APIs.
  - int_19h 1y ago
    I'm not disputing that there are circumstances in which indices are as good or even better. At the same time, if using indices was universally better, then we'd just use indices everywhere, and low-level PLs like Rust would be designed around that from the get go. We don't do that for good reasons.
- cornstalks 1y ago
  (This is a reply to multiple sibling comments, not the parent) For those saying unsafe Rust is strictly safer than C, you're overlooking Rust's extremely strict invariants that users must uphold. These are much stricter than C, and they're extremely easy to accidentally break in unsafe Rust. Breaking them in unsafe Rust is instant UB, even before leaving the unsafe context. This article has a decent summary in this particular section: https://zackoverflow.dev/writing/unsafe-rust-vs-zig/#unsafe-rust-is-hard https://zackoverflow.dev/writing/unsafe-rust-vs-zig/#unsafe-...
  - creata 1y ago
    The author seems to mostly be talking about the aliasing rules, but if you don't want to deal with those, can't you use UnsafeCell? Imo, the more annoying part is dealing with exception safety. You need to ensure that your data structures are all in a valid state if any of your code (especially code in an unsafe block) panics, and it's easy to forget to ensure that.
  - Ygg2 1y ago
    For those thinking unsafe Rust is harder than C. C standard defined just 216 unsafe rules, that you need to keep in mind at all times.
sapiogram 1y ago
Haters gonna hate. If you're working on a project that needs performance and correctness, nothing can get the job done like Rust.
- LAC-Tech 1y ago
  unless you have to do anything that relies on a C API (such as provided by an OS) with no concept of ownership, then it's a massive task to get that working well with idiomatic rust. You need big glue layers to really make it work. Rust is a general purpose language that can do systems programming. Zig is a systems programming language. (Safety Coomers please don't downvote)
  - saghm 1y ago
    What does it even mean to be able to "do systems programming" but not actually be a "systems programming language"? I would directly disagree with you, but what you're arguing is so vague that I don't even know what you're trying to claim. The only way I can make sense of this is if you literally define a "systems programming language" as C and only other things that are tightly tied to it, which I guess is fine if you like tautologies but kind of makes even having a concept of " systems programming language" pretty useless.
  - bbkane 1y ago
    And yet Rust in the one in the Linux and Windows kernels, so people must think it's worth the effort. https://threadreaderapp.com/thread/1577667445719912450.html https://threadreaderapp.com/thread/1577667445719912450.html is certainly a glowing recommendation
    - LAC-Tech 1y ago
      Kernels are big pieces of software. Rust is used for device drivers mainly, right? So in that case you write an idiomatic rust lib and wrap it in a C interface and load it in. Actually interfacing with idiomatic C APIs provided by an OS is something else entirely. You can see this is when you compare the Rust ecosystem to Zig; ie Zig has a fantastic io-uring library in the std lib, where as rust has a few scattered crates none of which come close the Zig's ease of use and integration. One thing I'd like to see is an OS built with rust that could provide its own rusty interface to kernel stuff.
dgb23 1y ago
Both are great languages. To me there's a philosophical difference, which can impact one to prefer one over the other: Rust makes doing the wrong thing hard, Zig makes doing the right thing easy.

int_19h 1y ago

If you don't happen to come across some task that implies a data model that Rust is actively hostile towards (e.g. trees with backlinks, or more generally any kind of graph with cycles in it), borrow checker is not much of a hassle. But the moment you hit something like that, it becomes a massive pain, and requires either "unsafe" (which is strictly more dangerous than even C, never mind Zig) or patterns like using indices instead of pointers which are counter to high performance and effectively only serve to work around the borrow checker to shut it up.

dwattttt 1y ago
> the moment you hit something like that, it becomes a massive pain, and requires either "unsafe" (which is strictly more dangerous than even C, never mind Zig) or patterns like using indices instead of pointers If you need to make everything in-house this is the experience. For the majority though, the moment you require those things you reach for a crate that solves those problems.
carlmr 1y ago
>requires either "unsafe" (which is strictly more dangerous than even C, never mind Zig) Um, what? Unsafe Rust code still has a lot more safety checks applied than C. >It’s important to understand that unsafe doesn’t turn off the borrow checker or disable any of Rust’s other safety checks: if you use a reference in unsafe code, it will still be checked. The unsafe keyword only gives you access to these five features that are then not checked by the compiler for memory safety. You’ll still get some degree of safety inside of an unsafe block. https://doc.rust-lang.org/book/ch20-01-unsafe-rust.html https://doc.rust-lang.org/book/ch20-01-unsafe-rust.html
Ar-Curunir 1y ago
I’m sorry, but your comment is a whole lot of horseshit. Unsafe rust still has a bunch of checks C doesn’t have, and using indices into vectors is common code in high performance code (including Zig!)
creata 1y ago
> patterns like using indices instead of pointers which are counter to high performance Using indices isn't bad for performance. At the very least, it can massively cut down on memory usage (which is in turn good for performance) if you can use 16-bit or 32-bit indices instead of full 64-bit pointers. > "unsafe" (which is strictly more dangerous than even C, never mind Zig) Unsafe Rust is much safer than C. The only way I can imagine unsafe Rust being more dangerous than C is that you need to keep exception safety in mind in Rust, but not in C.
- whytevuhuni 1y ago
  Not quite, you also need to keep pointer non-nullness, alignment and aliasing safety in Rust, which is very pervasive in Rust (all shared/mutable references) but very rare in C (the 'restricted' keyword). In Rust, it's not just using an invalid reference that causes UB, but their very creation, even if temporary. For example, since references have to always be aligned, the compiler can assume the pointer they were created from was also aligned, and so suddenly some ending bits from the pointer are ignored (since they must've been zero). And usually the point of unsafe is to make safe wrappers, so unafe Rust makes or interacts with safe shared/mutable references pretty often.
  - creata 1y ago
    It's just hard for me to imagine someone accidentally messing up nonnullness or aliasing, because it's really in-your-face that you need to be careful when constructing a reference unsafely. There are even idiomatic methods like ptr::as_ref to avoid accidentally creating null references.
jplusequalt 1y ago
>which is strictly more dangerous than even C, never mind Zig No it's not? The Rust burrow checker, the backbone of Rust's memory safety model, doesn't stop working when you drop into an unsafe block. From the Rust Book: >To switch to unsafe Rust, use the unsafe keyword and then start a new block that holds the unsafe code. You can take five actions in unsafe Rust that you can’t in safe Rust, which we call unsafe superpowers. Those superpowers include the ability to: Dereference a raw pointer Call an unsafe function or method Access or modify a mutable static variable Implement an unsafe trait Access fields of a union It’s important to understand that unsafe doesn’t turn off the borrow checker or disable any of Rust’s other safety checks: if you use a reference in unsafe code, it will still be checked. The unsafe keyword only gives you access to these five features that are then not checked by the compiler for memory safety. You’ll still get some degree of safety inside of an unsafe block.
- int_19h 1y ago
  The reason why it's more unsafe than C is because Rust makes a lot more assumptions about e.g. lack of aliasing that C does not, which are incredibly easy to violate once you have raw pointers. Obviously if you can keep using references then it's not less safe, but if what you're doing can be done with references, why would you even be using `unsafe`?
jplusequalt 1y ago
>using indices instead of pointers which are counter to high performance Laughs in graphics programmer. You end up using indices to track data in buffers all the time when working with graphics APIs.
- int_19h 1y ago
  I'm not disputing that there are circumstances in which indices are as good or even better. At the same time, if using indices was universally better, then we'd just use indices everywhere, and low-level PLs like Rust would be designed around that from the get go. We don't do that for good reasons.
cornstalks 1y ago
(This is a reply to multiple sibling comments, not the parent) For those saying unsafe Rust is strictly safer than C, you're overlooking Rust's extremely strict invariants that users must uphold. These are much stricter than C, and they're extremely easy to accidentally break in unsafe Rust. Breaking them in unsafe Rust is instant UB, even before leaving the unsafe context. This article has a decent summary in this particular section: https://zackoverflow.dev/writing/unsafe-rust-vs-zig/#unsafe-rust-is-hard https://zackoverflow.dev/writing/unsafe-rust-vs-zig/#unsafe-...
- creata 1y ago
  The author seems to mostly be talking about the aliasing rules, but if you don't want to deal with those, can't you use UnsafeCell? Imo, the more annoying part is dealing with exception safety. You need to ensure that your data structures are all in a valid state if any of your code (especially code in an unsafe block) panics, and it's easy to forget to ensure that.
- Ygg2 1y ago
  For those thinking unsafe Rust is harder than C. C standard defined just 216 unsafe rules, that you need to keep in mind at all times.

sapiogram 1y ago

Haters gonna hate. If you're working on a project that needs performance and correctness, nothing can get the job done like Rust.

LAC-Tech 1y ago
unless you have to do anything that relies on a C API (such as provided by an OS) with no concept of ownership, then it's a massive task to get that working well with idiomatic rust. You need big glue layers to really make it work. Rust is a general purpose language that can do systems programming. Zig is a systems programming language. (Safety Coomers please don't downvote)
- saghm 1y ago
  What does it even mean to be able to "do systems programming" but not actually be a "systems programming language"? I would directly disagree with you, but what you're arguing is so vague that I don't even know what you're trying to claim. The only way I can make sense of this is if you literally define a "systems programming language" as C and only other things that are tightly tied to it, which I guess is fine if you like tautologies but kind of makes even having a concept of " systems programming language" pretty useless.
- bbkane 1y ago
  And yet Rust in the one in the Linux and Windows kernels, so people must think it's worth the effort. https://threadreaderapp.com/thread/1577667445719912450.html https://threadreaderapp.com/thread/1577667445719912450.html is certainly a glowing recommendation
  - LAC-Tech 1y ago
    Kernels are big pieces of software. Rust is used for device drivers mainly, right? So in that case you write an idiomatic rust lib and wrap it in a C interface and load it in. Actually interfacing with idiomatic C APIs provided by an OS is something else entirely. You can see this is when you compare the Rust ecosystem to Zig; ie Zig has a fantastic io-uring library in the std lib, where as rust has a few scattered crates none of which come close the Zig's ease of use and integration. One thing I'd like to see is an OS built with rust that could provide its own rusty interface to kernel stuff.

dgb23 1y ago

Both are great languages. To me there's a philosophical difference, which can impact one to prefer one over the other: Rust makes doing the wrong thing hard, Zig makes doing the right thing easy.