8 ms·

A lot of people are arguing that new projects like this should use Rust. Like https://github.com/ctz/rustls https://github.com/ctz/rustls.

user5994461 10y ago
Only because they don't know Ada and they wanna reinvent the wheel again /s
- adrianN 10y ago
  I agree that Ada is a lot better than C, but the guarantees Ada provides are different from the guarantees Rust provides.
- pcwalton 10y ago
  As soon as you call (the equivalent of) malloc/free in Ada you either need a GC or you're in undefined behavior land. In Rust, that is not true. Obviously, being able to call malloc without a GC is a nice to have for TLS on embedded systems.
mbanzi 10y ago
Are there mature versions of rust for the hundreds of microcontrollers that people are in production right now? Most of them have a decent GCC port and C works on all of them..
- oconnor663 10y ago
  Rust uses LLVM on the backend, so it gets a lot of platform support for free. Not sure how mature that stuff is yet though. Maybe someone who's used Rust for embedded can jump in and comment?
- steveklabnik 10y ago
  In general, the versions of Rust end up being most of them, rather than being pinned to one specific version. As my sibling mentions, if LLVM can target it, then we can, but generally anything < 32 bits isn't gonna work at the moment. We're slowly getting support for some of that stuff. There's a whole group dedicated to working on this: https://github.com/rust-embedded/ https://github.com/rust-embedded/
- reinar 10y ago
  > Are there mature versions let's start from this
falcolas 10y ago
Rust can't target the same platforms C can. Rust is also (generally) more memory intensive than C for similar programs. This makes its use in embedded situations a non-starter (at least for now).
- steveklabnik 10y ago
  Isn't the "more memory intensive" thing mostly due to jemalloc? How are you getting this data?
- pcwalton 10y ago
  > Rust can't target the same platforms C can. I keep seeing this argument, but nobody actually names those platforms. Name one platform you need to run a TLS stack on that LLVM doesn't have support for. > Rust is also (generally) more memory intensive than C for similar programs [citation needed]
  - oconnor663 10y ago
    Maybe falcolas means that in the same way that C++ is more memory intensive than C for similar programs, because both C++ and Rust encourage a lot of Vecs/Strings that implicitly allocate on the heap?
    - pcwalton 10y ago
      Rust doesn't encourage that.
      - oconnor663 10y ago
        I suppose everything's a continuum with this stuff, but here's one library I ran into where I was a little disappointed to find a heap allocation: https://dnaq.github.io/sodiumoxide/sodiumoxide/crypto/secretbox/xsalsa20poly1305/fn.seal.html https://dnaq.github.io/sodiumoxide/sodiumoxide/crypto/secret...
  - reinar 10y ago
bandrami 10y ago
But rust has the exact same problem: if it's "safe", it's ironically not "secure" because the algorithm no longer controls its own memory operations. If you can't say, for instance, that the key is never swapped out, then it's not secure. But if you can say the key is never swapped out, you're at a level of direct memory control that is no longer "safe".
- deleted 10y ago
  [deleted]
- oconnor663 10y ago
  I think "memory that is never swapped to disk" would fit nicely into Rust's ownership/borrowing model. It would probably just be a variant on Box that makes more guarantees, but which exposes the same safe interfaces? Having a safe API built on top of unsafe calls is more or less how everything in Rust works (maybe how any safe language works?), when you drill down far enough. That said, I guess you'd have to be careful to avoid creating something like a NoSwapBox<Vec>, because the NoSwap property would only apply to the (ptr, capacity, length) triple of the vec, and not to its actual heap allocation that you probably care about. Maybe the answer there is something like requiring that the contents of NoSwapBox implement Copy, or some other way of saying "this is plain old data"? I don't know enough about the plans for custom allocators to say anything intelligent :p

user5994461 10y ago

Only because they don't know Ada and they wanna reinvent the wheel again /s

adrianN 10y ago
I agree that Ada is a lot better than C, but the guarantees Ada provides are different from the guarantees Rust provides.
pcwalton 10y ago
As soon as you call (the equivalent of) malloc/free in Ada you either need a GC or you're in undefined behavior land. In Rust, that is not true. Obviously, being able to call malloc without a GC is a nice to have for TLS on embedded systems.

mbanzi 10y ago

Are there mature versions of rust for the hundreds of microcontrollers that people are in production right now? Most of them have a decent GCC port and C works on all of them..

oconnor663 10y ago
Rust uses LLVM on the backend, so it gets a lot of platform support for free. Not sure how mature that stuff is yet though. Maybe someone who's used Rust for embedded can jump in and comment?
steveklabnik 10y ago
In general, the versions of Rust end up being most of them, rather than being pinned to one specific version. As my sibling mentions, if LLVM can target it, then we can, but generally anything < 32 bits isn't gonna work at the moment. We're slowly getting support for some of that stuff. There's a whole group dedicated to working on this: https://github.com/rust-embedded/ https://github.com/rust-embedded/
reinar 10y ago
> Are there mature versions let's start from this

falcolas 10y ago

Rust can't target the same platforms C can. Rust is also (generally) more memory intensive than C for similar programs. This makes its use in embedded situations a non-starter (at least for now).

steveklabnik 10y ago
Isn't the "more memory intensive" thing mostly due to jemalloc? How are you getting this data?
pcwalton 10y ago
> Rust can't target the same platforms C can. I keep seeing this argument, but nobody actually names those platforms. Name one platform you need to run a TLS stack on that LLVM doesn't have support for. > Rust is also (generally) more memory intensive than C for similar programs [citation needed]
- oconnor663 10y ago
  Maybe falcolas means that in the same way that C++ is more memory intensive than C for similar programs, because both C++ and Rust encourage a lot of Vecs/Strings that implicitly allocate on the heap?
  - pcwalton 10y ago
    Rust doesn't encourage that.
    - oconnor663 10y ago
      I suppose everything's a continuum with this stuff, but here's one library I ran into where I was a little disappointed to find a heap allocation: https://dnaq.github.io/sodiumoxide/sodiumoxide/crypto/secretbox/xsalsa20poly1305/fn.seal.html https://dnaq.github.io/sodiumoxide/sodiumoxide/crypto/secret...
- reinar 10y ago

bandrami 10y ago

But rust has the exact same problem: if it's "safe", it's ironically not "secure" because the algorithm no longer controls its own memory operations. If you can't say, for instance, that the key is never swapped out, then it's not secure. But if you can say the key is never swapped out, you're at a level of direct memory control that is no longer "safe".

deleted 10y ago
[deleted]
oconnor663 10y ago
I think "memory that is never swapped to disk" would fit nicely into Rust's ownership/borrowing model. It would probably just be a variant on Box that makes more guarantees, but which exposes the same safe interfaces? Having a safe API built on top of unsafe calls is more or less how everything in Rust works (maybe how any safe language works?), when you drill down far enough. That said, I guess you'd have to be careful to avoid creating something like a NoSwapBox<Vec>, because the NoSwap property would only apply to the (ptr, capacity, length) triple of the vec, and not to its actual heap allocation that you probably care about. Maybe the answer there is something like requiring that the contents of NoSwapBox implement Copy, or some other way of saying "this is plain old data"? I don't know enough about the plans for custom allocators to say anything intelligent :p