4 ms·

The article and the links it references do a good job of explaining the arguments. A short summary: * Rust's no_std means you can run bare metal with less memo

The article and the links it references do a good job of explaining the arguments. A short summary: * Rust's no_std means you can run bare metal with less memory overhead than even newlib based c * no_std also makes it easier to port to new platforms, as nonportable parts are isolated out of the std lib * algebraic data types and in particular enums that can carry disjoint associated data reduce the number of error prone magic constants and casts in your code, as well as catching all missing switch cases * unsafe makes it very easy for you to audit where data races or memory errors are possible, instead of needing to audit an entire c codebase * The borrow check makes you work more, but in many cases this is justified by it leading you to a less brittle design The examples, particularly on cliff's blog post, make pretty convincing arguments oo these points imo. I also wouldn't discount EEs so much. There's plenty of complexity to Verilog and all the other tools they use.

saurik 6y ago
If you are using no_std isn't that the same as just not having a C standard library? I have been programming in C/C++ for over 25 years in ridiculously restricted contexts--even using it to compile tiny trampolines and the such--and I have no clue what you might mean that Rust could possibly have a smaller runtime library than C's "literally it comes with and uses nothing as the C standard library is nothing more than an optional library that most embedded people don't use".
- nindalf 6y ago
  > If you are using no_std isn't that the same as just not having a C standard library No. no_std means that all standard library functions that involve allocation aren't available. Things like std::collections::{Vec, HashMap} etc. You have access to std::core (https://doc.rust-lang.org/core/index.html https://doc.rust-lang.org/core/index.html), which is pretty useful.
  - chrismorgan 6y ago
    Technical correction: core is a crate, not a module in the std crate. Your paths will be core::, not std::core::.
  - saurik 6y ago
    The context was with respect to memory overhead, so can you explain this difference with respect to that axis, showing that C with no standard library somehow has higher memory overhead than Rust with no_std? With respect to the actual conversational context, I stand by my comparison.
    - strbean 6y ago
      I think the point is that running no stdlib in C is throwing the baby out with the bathwater.
- deleted 6y ago
  [deleted]
sai_c 6y ago
* unsafe makes it very easy for you to audit where data races or memory errors are possible, instead of needing to audit an entire c codebase I have seen this argument a couple of times before. But I can't make myself buy it. Because I always have to think about embedded systems in the car industry. Look at this list: https://betterembsw.blogspot.com/2018/09/potentially-deadly-automotive-software.html https://betterembsw.blogspot.com/2018/09/potentially-deadly-... The argument is basically "the possible fail places are easily grepable", right? I said in another comment in this thread (jokingly) "time is money". It seems for the devs in the car industry this saying is of utter most importance. So how does Rust prevent something like this throughout the code base (and those are BIG code bases): "LOL. I need to get this done. unsafe { ... } "
- baq 6y ago
  it doesn't. if such code passes peer review, it's their problem. you absolutely need buy-in from devs that the borrow checker is there to help you and save time for your future self.
- steveklabnik 6y ago
  > So how does Rust prevent something like this throughout the code base In some sense, it doesn't. But in another sense, you can't just throw unsafe around things. Unsafe doesn't turn off checks. Unsafe adds new unchecked constructs. This means you can't have written a bunch of code, run into errors, and just toss unsafe {} around it. You'd have to actually re-write it with unsafe constructs in the first place. You can very much do that, if you want. But it's not a trivial escape hatch.
  - sai_c 6y ago
    I understand the "unsafe" construct on the technical level, but thanks for clarification nevertheless. My point was that, with "unsafe", Rust provides a technical construct which allows to carry over some negative development styles, possible in the C(++) world, without friction (if wanted). And from the list I linked, there seems to be a lot of momentum for this kind of behaviour in certain industries. You'd have to actually re-write it with unsafe constructs in the first place. This is what I think would happen, and tried to describe. Someone trying to implement a feature, failing with safe mode and resorting to "unsafe" from scratch, just to get it done. So it stays the way it is, i.e. I can't buy the "possible fail places are easily grepable" argument.

saurik 6y ago

If you are using no_std isn't that the same as just not having a C standard library? I have been programming in C/C++ for over 25 years in ridiculously restricted contexts--even using it to compile tiny trampolines and the such--and I have no clue what you might mean that Rust could possibly have a smaller runtime library than C's "literally it comes with and uses nothing as the C standard library is nothing more than an optional library that most embedded people don't use".

nindalf 6y ago
> If you are using no_std isn't that the same as just not having a C standard library No. no_std means that all standard library functions that involve allocation aren't available. Things like std::collections::{Vec, HashMap} etc. You have access to std::core (https://doc.rust-lang.org/core/index.html https://doc.rust-lang.org/core/index.html), which is pretty useful.
- chrismorgan 6y ago
  Technical correction: core is a crate, not a module in the std crate. Your paths will be core::, not std::core::.
- saurik 6y ago
  The context was with respect to memory overhead, so can you explain this difference with respect to that axis, showing that C with no standard library somehow has higher memory overhead than Rust with no_std? With respect to the actual conversational context, I stand by my comparison.
  - strbean 6y ago
    I think the point is that running no stdlib in C is throwing the baby out with the bathwater.
deleted 6y ago
[deleted]

sai_c 6y ago

* unsafe makes it very easy for you to audit where data races or memory errors are possible, instead of needing to audit an entire c codebase I have seen this argument a couple of times before. But I can't make myself buy it. Because I always have to think about embedded systems in the car industry. Look at this list: https://betterembsw.blogspot.com/2018/09/potentially-deadly-automotive-software.html https://betterembsw.blogspot.com/2018/09/potentially-deadly-... The argument is basically "the possible fail places are easily grepable", right? I said in another comment in this thread (jokingly) "time is money". It seems for the devs in the car industry this saying is of utter most importance. So how does Rust prevent something like this throughout the code base (and those are BIG code bases): "LOL. I need to get this done. unsafe { ... } "

baq 6y ago
it doesn't. if such code passes peer review, it's their problem. you absolutely need buy-in from devs that the borrow checker is there to help you and save time for your future self.
steveklabnik 6y ago
> So how does Rust prevent something like this throughout the code base In some sense, it doesn't. But in another sense, you can't just throw unsafe around things. Unsafe doesn't turn off checks. Unsafe adds new unchecked constructs. This means you can't have written a bunch of code, run into errors, and just toss unsafe {} around it. You'd have to actually re-write it with unsafe constructs in the first place. You can very much do that, if you want. But it's not a trivial escape hatch.
- sai_c 6y ago
  I understand the "unsafe" construct on the technical level, but thanks for clarification nevertheless. My point was that, with "unsafe", Rust provides a technical construct which allows to carry over some negative development styles, possible in the C(++) world, without friction (if wanted). And from the list I linked, there seems to be a lot of momentum for this kind of behaviour in certain industries. You'd have to actually re-write it with unsafe constructs in the first place. This is what I think would happen, and tried to describe. Someone trying to implement a feature, failing with safe mode and resorting to "unsafe" from scratch, just to get it done. So it stays the way it is, i.e. I can't buy the "possible fail places are easily grepable" argument.