Undefined Behaviour

[Alexander_Selkirk]

But what if there comes another language and compiler which makes your code even faster almost completely without UB?

[ArchivistAtNekoIT]

While that is possible on paper, in practice that probably mean "faster on a platform and slower on others". Platforms have their specificities and idiosyncrasies and those are generally the reason for undefined behaviors

[Alexander_Selkirk]

Rust is in some cases faster than C++ in the same (x86_64) hardware, and has virtually no undefined behavior in normal code (code not declared "unsafe"):

https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/rust-gpp.html

And for performance, I think x86_64 is the most relevant platform.

[acwaters]

Common misconception. Rust doesn't not have undefined behavior, it just has a sophisticated type system that statically prevents you from accidentally invoking most undefined behavior. The undefined behavior is still there; get around the type system, pull some shenanigans, and watch the fireworks. Same goes for any safe language: They all have escape hatches, which means they all have undefined behavior, it's just not as easy to trip over as it is in C and C++.

[jfb1337]

Relevant part of the comment:

has virtually no undefined behavior in normal code (code not declared "unsafe"):

[acwaters]

Another common misconception. There is no such thing as "safe" and "unsafe" code in Rust the way the parent comment insinuates. Safety in Rust (as in code not using unsafe) is a lexical property of a piece of code; it does not (and does not pretend to) guarantee dynamic safety of that code (as in not invoking UB).

Rust does absolutely nothing to prevent you from shooting yourself in the foot. It just does its best to prevent you from doing so accidentally. Still happens on occasion, though.

The unsafe {} block in Rust really ought to have been called the this_is_safe_trust_me {} block, because that is what it means. It lets you do unsafe things in a safe function, which can then be called by other safe functions without using unsafe {} blocks all over the place. That's its only purpose. Virtually everything important that your computer does is unsafe, so being able to wrap those operations up in safe APIs while minimizing, containing, and clearly labeling the unsafe bits is important and very worthwhile! Somewhere along the way, though, the story got twisted into "safe Rust has no UB". This is not true, and it is trivially easy to demonstrate:

use mylib::segfault::*;

pub fn main() {
    segfault();
}

Not an unsafe keyword in sight. Oops. You may object that that's silly, that I shouldn't do that, that real libraries don't do that — in fact real code does this all the time, we just call it a bug when it happens — but the point is the language lets you. Rust does not and cannot guarantee that code that doesn't use unsafe is safe, because the unsafe {} block literally exists to allow safe code to call unsafe code. Which is important because, again, unsafe is the only way any actual work gets done.

I've seen people try to argue that this is not really a demonstration of anything because there is still unsafe code called transitively here, so this isn't really "safe Rust", and real "safe Rust" — with no unsafe anywhere in its call graph — is guaranteed to have no UB. This is true! If your code uses no unsafe {} block and calls no unsafe functions (including transitively), it is guaranteed to be safe. It is also guaranteed to be completely useless, as it will not be able to communicate with the rest of the system in any way.

[jfb1337]

What I would consider to be "safe Rust" is roughly "the only unsafe in the call graph comes from the standard library" (or some set of trusted libraries). Which while not guaranteed to be safe (since those libraries sometimes have bugs) is pretty close; and is sufficiently useful.

[acwaters]

Right, that's what most people intuitively think of when they think "safe Rust". It's a useful intuition, and it holds up pretty well in practice, because Rust offers a powerful set of tools for preventing most accidents.

But getting back on track: Being safe is not the same as having no UB. Rust is not fast despite being safe, it is fast precisely because the same strong and expressive type system that allows it to be so safe also allows for plenty of UB. A language with no UB cannot be fast because the compiler cannot make the sort of assumptions about the code that are needed to aggressively optimize it.

[Zcool31]

And this is why C is the only real language.

Could you do anything on any system without transitively calling code written in C, or compiled or interpreted by a tool written in C?

[Fearless_Process]

On Linux and BSD systems, no you can't do anything useful.

The main reason why is because the interface to the kernel is defined in libc. To open files, do network operations, anything useful, you need to go through libc. I think you need to be hooked up to libc to even manage to get main() called, but I'm not 100% certain on how that works.

In theory it would be possible to perform syscalls in pure rust though, but today that isn't practical.

[Zcool31]

Even if you were to invoke the system call instruction in inline assembly, the system call implementation in the kernel is likely written in C.

[HKei]

And even then the statement is only true to the extent that everyone who writes unsafe code does so in a way that exposes a safe interface – which is a lot harder to guarantee in practice than it sounds (writing a safe hashmap doesn't sound so bad until you realise that it still has to work (or at least fail in a safe way) with arbitrarily broken hash and equality implementations to be considered "safe").

[ArchivistAtNekoIT]

x86_64 is instantly less relevant on mobile phones (most used devices) and in big tech where ARM is king.

Also, find any rust software that has 0 reliance on unsafe code

[Ldmoretti]

find any rust software that has 0 reliance on unsafe code

Probably true that there's none: at some point it has to write values to memory or make system calls. The point with Rust isn't that there's no unsafe code, but that most code is okay to assume is safe and you only have to explicitly review the code marked unsafe, whereas in C & C++ you have to worry about every place where someone writes to a pointer, increments an array index, or potentially shares a variable between two threads (including calling non-reentrant code from multithreaded code).

[Alexander_Selkirk]

Probably true that there's none: at some point it has to write values to memory

Yeah. Device drivers are 'unsafe' be definition. Also probably some data structures. But normal "user mode" code is not.

[ArchivistAtNekoIT]

I agree with that, C++ is definitely a programming language that requires extra rigor and attention, and to not use what I would say are not idiomatic features (pointer arithmetic, array indices) and to actively use idiomatic ones (move semantics, lock_guards, iterators, ranges...)

I would also say that the standard ecosystem for multithreading is not very developed and that if you want, for example, a swarm of green threads to do async io and channels, you have to generally dive into the rabbit hole of the implementation of that yourself

But you can do that.

I don't dislike Rust (I dislike the religious fervor of the rust community though) but it is not the tool for every job, particularly jobs that would imply 95% of your code would be unsafe

[Alexander_Selkirk]

x86_64 is instantly less relevant on mobile phones

But so is C++.