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

> 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), which is pretty useful.

Technical correction: core is a crate, not a module in the std crate. Your paths will be core::, not std::core::.

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.

I think the point is that running no stdlib in C is throwing the baby out with the bathwater.

   * 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-...

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 { ... } "

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

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.

Yes, in theory that could happen. In practice, we don’t see it happening. Doesn’t mean it can’t, but time will tell.

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.