[uecker]

There can be made very good arguments why C is less safe than Rust, but null pointer dereferences which are perfectly safe everywhere except on weird platforms (and usually could be made safe even there by turning on a compiler flag) seems a very misleading argument.

And as as the Cloudflare incident showed, a Rust unwrap can have equally bad consequences. (or as Ariane 5 showed, a safe overflow in Ada can have explosive consequences)

[1718627440]

A dereference in the final binary is not different from Rust. A dereference in the source code, that makes the whole program invalid, so the compiler doesn't emit a credentials check you wanted it to emit, is.

For availability and stability concerns, the C approach is actually better, but for security and reproducibility, it is not.

[uecker]

The check is removed only if you already dereference the pointer before doing the check. But then, you also get the trap before the check. So the compiler eliding the check is not making this worse - as long as the zero page is not mapped.

In any case, you can also configure GCC to not do this, and you can also configure it to insert explicit null checks before dereferencing a pointer. So C can offer you security and reproducibility (in this aspect).

[1718627440]

No, it's also removed if you dereference it later on, that's why it is said, that UB has time traveling behaviour. This means, that the compiler can emit a program, that let's you access data without a security check, while the crash only comes later. Also the crash can be removed, because dereferencing it is UB anyway, so the compiler does not need to emit it.

[Ygg2]

> And as as the Cloudflare incident showed, a Rust unwrap can have equally bad consequences.

Arguably less bad than silently corrupting your data and forcing you to do CAPTCHA everywhere.

Which is what the parallel Perl(?) component was doing at the time.

Rust solution gave a clear signal something was wrong, the other solution was slowly annoying everyone and pushing them away.

[uecker]

A major global internet outage can certainly considered a "clear signal". Still not sure this was a good thing though.

[Ygg2]

It's not an ideal thing for sure, but between loud bang and silent corruption, I'd probably take loud bang. I.e. I'll take a panic rather than the method return 43 when you pop the null member from the stack.

And the Rust wasn't the root cause but corrupt configs were being erroneusly duplicated.

[uecker]

I guess this depends on what you might corrupt (if it is not valuable but irrelevant intermediate state it might be ok) and what the consequences of an outage are.

In any case, I largely tend to agree with you that this is better in most scenarios (not for the cloudflare incident though). But a segfault in C for a null pointer dereference would have exactly the same result, which is why null pointer dereferences are a terribly example if you want to show the advantages of Rust.

The only example I know where I think Rust clearly has a real advantage are lifetimes.

[blub]

These Rust discussions typically contain grains of truth wrapped into exaggerations while downplaying or ignoring the two big issues of Rust, which are complexity and out of control dependency trees.

For the first issue of complexity, the reply is along the lines of show me the code and then either nitpicking that to pieces or explaining in several paragraphs how the behavior is perfectly reasonable and in fact quite easy to understand. Beginners get intimidated, professionals don’t have time to write novels on HN. Complexity in Rust is systemic. It’s little things accumulating and amplifying each-other that add up to having to spend significant time just designing types to satisfy the static analyzer. Many Rust programmers seem to see the type system as a hammer to be used liberally, an predilection also known in the C++ metaprogramming community.

On the second topic (also present in this thread) the counter-argument is that other languages do it too and nothing bad happened so far. The former is not valid, because Rust is uniquely bad in its competitor group and security by waiting is not a valued approach.

[hurril]

I would argue that what you call complexity here is better referred to as explicit or visible complexity, as compared to hidden or implicit commplexity. The complexity as such comes with the domain and its application; but with Rust you can see it and you are forced to deal. With C++ you can get away with pretending that it is in fact not there.

This is honestly not intended to pick on C++ as a Rust fanboy, however. It really isn't.

For instance, to be a little unpolished, I would shrug off the unwrap incident as doing it the C++ way and pretending that the complexity does not need to be solved right then and there because ItShouldNotHappen or IKnowWhatIAmDoing.

I prefer Rust over C++, but I do not hate C++. This isn't even about C++ anyway.

When it comes to out of control dependency trees, I agree with you. But there is a trade off here too and that is that either you implement the thing or you externalize it. I use both approaches myself and am in no way excusing anything or attempting to be Rust's defense lawyer. There definitely seems to be a leftpad-problem brewing in the Rust community.

[uecker]

There are certainly good parts in Rust that force you deal with inherent issues explicitly. I do not think this justifies a language with the complexity of Rust, but I would agree it is preferable to C++ in this regard.

[hurril]

I reject the whole Rust has a high complexity premise, but I would gladly continue our conversation around it here but I would need a little more definition for that to be possible.

What do you mean by complexity in this context and in what way does Rust carry a lot of it?

[uecker]

I did not know this was disputed, as even developer surveys in the Rust community highlighted complexity as a concern. But seems it is the overall summary of features that make it complex: lifetime, borrowing, a polymorphic type system, traits, multiple tools to manage lifetimes, macros, proc macros, async, unsafe, panic, unwrap, etc. But I agree it is much cleaner than C++.

[hurril]

Still not picking on C++ here. I would claim that these concepts pretty much all exist in C++ too, but often implicitly so. You would solve them by "braining them", with good rules of thumb, patterns, tests and deep knowledge and skill. In fact, you _have_ to solve them this way.

In Rust the compiler is going to have a problem with your code unless you are explicit about borrowing/ ownership, gcc won't care. Which is the more complex thing there?

Same goes for the polymorphism. Looking at languages without parametric polymorphism, you instead see casts and inheritance trees. Not picking on old Java here, but is this more or less complex?

Let's talk some about unsafe as well. In C or C++, for instance, there is a global unsafe surrounding all the code, so if someone has problem with unsafe, why would they pick on Rust where "unsafety" is optional?

Same goes for unwrap. Unwrap is basically a deref combined with a _safe_ crash if the deref was not successful at runtime. Do that in an unsafe language and you have an access violation best case. Or just silent corruption. Which is more complex?