6 ms·

>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"

by 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.
  - pjmlp 10y ago
    > 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? To add to this point, my answer would be a big NO, if one would look to the C alternatives that sadly became niches. Sadly the adoption of C has lead to younger generations thinking that those are the only valid paths in system languages. Thankfully new languages, including Rust, are changing that.
    - AstralStorm 10y ago
      However, typed and separate memory areas with various allowed kinds of concurrent access are needed. Even simple RAM has multiple modes, plain, atomic of multiple kinds, barriers... On top of that, you get devices that handle access only with delay inbetween, can never be accessed concurrently (volatile), have alignment requirements and more. Rust memory model is too weak to enforce safety in such cases while not sacrificing performance. It is written from "I have one CPU" side. Even C is far beyond that with things like OpenCL...
      - dbaupp 10y ago

by drbawb 10y ago

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.
- pjmlp 10y ago
  > 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? To add to this point, my answer would be a big NO, if one would look to the C alternatives that sadly became niches. Sadly the adoption of C has lead to younger generations thinking that those are the only valid paths in system languages. Thankfully new languages, including Rust, are changing that.
  - AstralStorm 10y ago
    However, typed and separate memory areas with various allowed kinds of concurrent access are needed. Even simple RAM has multiple modes, plain, atomic of multiple kinds, barriers... On top of that, you get devices that handle access only with delay inbetween, can never be accessed concurrently (volatile), have alignment requirements and more. Rust memory model is too weak to enforce safety in such cases while not sacrificing performance. It is written from "I have one CPU" side. Even C is far beyond that with things like OpenCL...
    - dbaupp 10y ago