7 ms·

I think whether you feel you need unsafe when you first come to Rust depends on the angle from which you're coming. Coming from C/C++, I know that there are st

I think whether you feel you need unsafe when you first come to Rust depends on the angle from which you're coming. Coming from C/C++, I know that there are structs in memory and can visualize what they look like - surely I can just go and tweak them? (No I can't because either it wasn't safe to do that anyway, or I need to explain to the Rust compiler why it is safe, and that can be quite difficult.) Coming from something like Java, I (probably) don't think too much about what the underlying structure in memory is, so I'm less likely to try to do this. Either way, it feels like part of the learning curve is learning the "Rustic" way to do something - in general, you probably shouldn't be reaching for "unsafe" until you know what you're doing! ;)

readittwice 10y ago
I am not so sure about this, at least for Java for one simple reason: it is so easy to have back-pointers/cycles in your object graphs. In Java you don't even have to think about that. This was quite hard for me to figure out when starting with Rust.
drbawb 10y ago
>Either way, it feels like part of the learning curve is learning the "Rustic" way to do something - in general, you probably shouldn't be reaching for "unsafe" until you know what you're doing! ;) I tend to agree with this sentiment. The moment I saw that OP was doing pointer arithmetic: I knew they were in for a bad time. It's not that you can't do it -- it's moreso that Rust's raison d'etre is to highlight the flaws inherent in that approach. I hadn't thought about it, but I think you're right, my background in managed languages is probably why I didn't run into these sorts of issues until after I was already comfortable with Rust. I wasn't trying to make maximally storage-efficient collections right out of the gate, instead I was building application-level stuff on top of `std::collections`.
- braveo 10y ago
  In other words, you weren't using it as the systems language it's billed as. Which is fine, but it's claimed to be a systems level language, and if it's really that painful to do systems level things, then there's a problem somewhere. Which is what's being discussed.
  - drbawb 10y ago
    >and if it's really that painful to do systems level things, then there's a problem somewhere. To me it's not a problem at all, Rust is working exactly as designed. When you start writing code in the style that Ayende has: its memory layout becomes entirely non-obvious. The structure definition no longer lines up with how that memory is actually being used. You'll need documentation of the sentinels & invariants, you'll want diagrams of the memory layout (since it won't line up with the structure definition), and a careful understanding of every line of code packing the bytes -- that's just to get a basic understanding of what's actually going on. This is fine, and you absolutely need to be able to do it, which is exactly why Rust provides `unsafe {}` (along with `std::ptr` and `std::mem`.) Sometimes you need that control you want a memory-efficient data structure, other times that's because you're reading registers directly off the hardware. In either case Rust is going to make you use `unsafe {}` which is a signal to say: "to understand how this is really laid out in memory you need to understand every single line in this block." I would much rather be able to grep for `unsafe {}` and audit parts of a trie-map for memory safety, as opposed to auditing my entire program for memory safety violations. That's not a failing of Rust, it's functioning exactly as intended. Trying to squeeze every last byte out of a struct is neither obvious nor safe, it requires careful thought.
    - braveo 10y ago
      > I would much rather be able to grep for `unsafe {}` and audit parts of a trie-map for memory safety, as opposed to auditing my entire program for memory safety violations. you mean auditing the entire implementation of the trie data structure, not the entire program. Guess what? In rust, if you use unsafe, you also have to audit the implementation of the entire trie datastructure. And if you think you don't, then I submit you don't understand Rust safety that well.
  - Manishearth 10y ago
    Rust contests the claim that you actually need to do pointer arithmetic and stuff often in systems languages. You need to do it a bit to implement your abstractions, maybe, but it is not the first tool you should need to reach for. The code in the blog post looks very much like C-translated-to-rust. Right now, systems programming mostly does look like C/C++ because those are the only two mainstream languages that work here (D, too, but D is like C++. There are also other languages). But systems programming doesn't have to look the same or use the same primitives. Do you really need to use malloc to allocate memory in a systems language? Do you really need to use pointer arithmetic to deal with things in a systems language? Sometimes, but not necessarily often. Even the Rust operating systems have managed to minimize the amount of unsafe/C-like code. Rust does expose this functionality, but if it's not something it expects you to use often it makes sense that it might not always be straightforward to use.

readittwice 10y ago

I am not so sure about this, at least for Java for one simple reason: it is so easy to have back-pointers/cycles in your object graphs. In Java you don't even have to think about that. This was quite hard for me to figure out when starting with Rust.

drbawb 10y ago

>Either way, it feels like part of the learning curve is learning the "Rustic" way to do something - in general, you probably shouldn't be reaching for "unsafe" until you know what you're doing! ;) I tend to agree with this sentiment. The moment I saw that OP was doing pointer arithmetic: I knew they were in for a bad time. It's not that you can't do it -- it's moreso that Rust's raison d'etre is to highlight the flaws inherent in that approach. I hadn't thought about it, but I think you're right, my background in managed languages is probably why I didn't run into these sorts of issues until after I was already comfortable with Rust. I wasn't trying to make maximally storage-efficient collections right out of the gate, instead I was building application-level stuff on top of `std::collections`.

braveo 10y ago
In other words, you weren't using it as the systems language it's billed as. Which is fine, but it's claimed to be a systems level language, and if it's really that painful to do systems level things, then there's a problem somewhere. Which is what's being discussed.
- drbawb 10y ago
  >and if it's really that painful to do systems level things, then there's a problem somewhere. To me it's not a problem at all, Rust is working exactly as designed. When you start writing code in the style that Ayende has: its memory layout becomes entirely non-obvious. The structure definition no longer lines up with how that memory is actually being used. You'll need documentation of the sentinels & invariants, you'll want diagrams of the memory layout (since it won't line up with the structure definition), and a careful understanding of every line of code packing the bytes -- that's just to get a basic understanding of what's actually going on. This is fine, and you absolutely need to be able to do it, which is exactly why Rust provides `unsafe {}` (along with `std::ptr` and `std::mem`.) Sometimes you need that control you want a memory-efficient data structure, other times that's because you're reading registers directly off the hardware. In either case Rust is going to make you use `unsafe {}` which is a signal to say: "to understand how this is really laid out in memory you need to understand every single line in this block." I would much rather be able to grep for `unsafe {}` and audit parts of a trie-map for memory safety, as opposed to auditing my entire program for memory safety violations. That's not a failing of Rust, it's functioning exactly as intended. Trying to squeeze every last byte out of a struct is neither obvious nor safe, it requires careful thought.
  - braveo 10y ago
    > I would much rather be able to grep for `unsafe {}` and audit parts of a trie-map for memory safety, as opposed to auditing my entire program for memory safety violations. you mean auditing the entire implementation of the trie data structure, not the entire program. Guess what? In rust, if you use unsafe, you also have to audit the implementation of the entire trie datastructure. And if you think you don't, then I submit you don't understand Rust safety that well.
- Manishearth 10y ago
  Rust contests the claim that you actually need to do pointer arithmetic and stuff often in systems languages. You need to do it a bit to implement your abstractions, maybe, but it is not the first tool you should need to reach for. The code in the blog post looks very much like C-translated-to-rust. Right now, systems programming mostly does look like C/C++ because those are the only two mainstream languages that work here (D, too, but D is like C++. There are also other languages). But systems programming doesn't have to look the same or use the same primitives. Do you really need to use malloc to allocate memory in a systems language? Do you really need to use pointer arithmetic to deal with things in a systems language? Sometimes, but not necessarily often. Even the Rust operating systems have managed to minimize the amount of unsafe/C-like code. Rust does expose this functionality, but if it's not something it expects you to use often it makes sense that it might not always be straightforward to use.