5 ms·

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 abstract

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
    Rust gets all your favourite kinds of atomics and barriers, exactly like C. Other things are indeed hard to get safe, which is why Rust has `unsafe`: it is possible to use them, marking out the dangerous regions precisely, rather than the whole program being `unsafe` just because a few places need niche features. In any case, Rust is definitely not written with "I have one CPU" in mind. A slogan that is sometimes used for Rust is "safe. fast. concurrent.", and it's one of the headline features on the front page: http://rust-lang.org/ http://rust-lang.org/ . Rust's abstractions allows writing extremely high performance libraries like rayon, which, had better performance than even highly optimised C libraries like Cilk, in one benchmark I heard about. Building out that parallelism ecosystem takes time, so it does not seem particularly surprising that there are more (unsafe!) libraries for the 40-year-old language, than (safe!) libraries in the less-than-2-year-old one.
    - AstralStorm 10y ago
      No, by one CPU i meant not a single core. I meant not having to manage different memory models and available access patterns. Or different ways of handling race conditions and alignments. You get to use unsafe almost exclusively in the internals of such access where it shouldn't be necessary if there are ways to specify more properties than just binary "safe" and "unsafe". It is extremely hard to prove such code correct in Rust.
      - dbaupp 10y ago
        > I meant not having to manage different memory models and available access patterns The only way I can make this make sense, is having cross-platform abstraction around atomic orderings etc. (like the new C++11 std::atomics) that works on x86 and ARM and PowerPC etc. Rust has such a cross-platform abstraction, almost identical to C++11: https://doc.rust-lang.org/std/sync/atomic/index.html https://doc.rust-lang.org/std/sync/atomic/index.html Please be more specific about what exactly you mean if I am wrong.
braveo 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? Sometimes, but not necessarily often. Even the Rust operating systems have managed to minimize the amount of unsafe/C-like code. If you're adding performance considerations I think the answer is going to be yes.
- bryanlarsen 10y ago
  I'm not an expert, but I believe that Rust's performance will be better if you avoid unsafe pointers. Rust's abstractions are generally cost-free, but if you use unsafe pointers the compiler will have to avoid optimizations that could be broken by potential pointer aliasing.
  - braveo 10y ago
    the idea of cost-free came from C++ where the belief is that you don't pay for what you don't use. The underlying meaning there is that you don't pay the cost of virtualized function calls if you're not using polymorphism (this is a big reason why C++ doesn't feature virtualized function calls by default). polymorphism is of course an abstraction, the idea of cost-free is that you only pay for the abstractions you actually use. This is not the same as maximizing performance. The real question is whether or not you can do these things without giving the developer the control to maximize performance, and I think the answer is going to be no. The response will be that it's "good enough", but that's not actionable as we don't know what "good enough" means for any particular project.
- Manishearth 10y ago
  > If you're adding performance considerations I think the answer is going to be yes. You can build (or use, from the stdlib) safe abstractions over malloc that have the same performance. This should cover 99% of the use cases of malloc. For the few quirky cases where you still need malloc, you can still use it, but that means that the language doesn't need to make malloc-based memory management easy.
  - 10y ago

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
  Rust gets all your favourite kinds of atomics and barriers, exactly like C. Other things are indeed hard to get safe, which is why Rust has `unsafe`: it is possible to use them, marking out the dangerous regions precisely, rather than the whole program being `unsafe` just because a few places need niche features. In any case, Rust is definitely not written with "I have one CPU" in mind. A slogan that is sometimes used for Rust is "safe. fast. concurrent.", and it's one of the headline features on the front page: http://rust-lang.org/ http://rust-lang.org/ . Rust's abstractions allows writing extremely high performance libraries like rayon, which, had better performance than even highly optimised C libraries like Cilk, in one benchmark I heard about. Building out that parallelism ecosystem takes time, so it does not seem particularly surprising that there are more (unsafe!) libraries for the 40-year-old language, than (safe!) libraries in the less-than-2-year-old one.
  - AstralStorm 10y ago
    No, by one CPU i meant not a single core. I meant not having to manage different memory models and available access patterns. Or different ways of handling race conditions and alignments. You get to use unsafe almost exclusively in the internals of such access where it shouldn't be necessary if there are ways to specify more properties than just binary "safe" and "unsafe". It is extremely hard to prove such code correct in Rust.
    - dbaupp 10y ago
      > I meant not having to manage different memory models and available access patterns The only way I can make this make sense, is having cross-platform abstraction around atomic orderings etc. (like the new C++11 std::atomics) that works on x86 and ARM and PowerPC etc. Rust has such a cross-platform abstraction, almost identical to C++11: https://doc.rust-lang.org/std/sync/atomic/index.html https://doc.rust-lang.org/std/sync/atomic/index.html Please be more specific about what exactly you mean if I am wrong.

braveo 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? Sometimes, but not necessarily often. Even the Rust operating systems have managed to minimize the amount of unsafe/C-like code. If you're adding performance considerations I think the answer is going to be yes.

bryanlarsen 10y ago
I'm not an expert, but I believe that Rust's performance will be better if you avoid unsafe pointers. Rust's abstractions are generally cost-free, but if you use unsafe pointers the compiler will have to avoid optimizations that could be broken by potential pointer aliasing.
- braveo 10y ago
  the idea of cost-free came from C++ where the belief is that you don't pay for what you don't use. The underlying meaning there is that you don't pay the cost of virtualized function calls if you're not using polymorphism (this is a big reason why C++ doesn't feature virtualized function calls by default). polymorphism is of course an abstraction, the idea of cost-free is that you only pay for the abstractions you actually use. This is not the same as maximizing performance. The real question is whether or not you can do these things without giving the developer the control to maximize performance, and I think the answer is going to be no. The response will be that it's "good enough", but that's not actionable as we don't know what "good enough" means for any particular project.
Manishearth 10y ago
> If you're adding performance considerations I think the answer is going to be yes. You can build (or use, from the stdlib) safe abstractions over malloc that have the same performance. This should cover 99% of the use cases of malloc. For the few quirky cases where you still need malloc, you can still use it, but that means that the language doesn't need to make malloc-based memory management easy.
- 10y ago