A lot of good stuff in there

Posted Feb 15, 2025 16:40 UTC (Sat) by wtarreau (subscriber, #51152)
In reply to: A lot of good stuff in there by mb
Parent article: New leadership for Asahi Linux

> Rust forces you to not code the same bug as in your C code. The one where argv[1] is not a numeric string.
To me that is a good thing.

The thing is, there are plenty of cases where I *know* it's valid, e.g. because it has been validated a few lines before one way or another, or because it's guaranteed by contract in an API or anything. Instead I feel like the extra difficulty diverts me from doing the thing I was trying to do, and that constantly working around the compiler has serious chances of making me introduce bugs the same way I occasionally introduce some by trying to shut up an inappropriate gcc warning by rewriting code differently and making a mistake while the initial one was correct. I have strong doubts about the validity of all rust code in the wild in 10 years. Sure we'll see less overflows, but control bugs are very present as well and I suspect will be harder to spot (and sometimes even fix).

A lot of good stuff in there

Posted Feb 15, 2025 16:56 UTC (Sat) by mb (subscriber, #50428) [Link]

>The thing is, there are plenty of cases where I *know* it's valid, e.g. because it has been validated a few lines before one way or another,

Sure. And then you just have to tell the compiler about that knowledge. It's often as simple as calling unwrap(). Or sometimes even simpler by throwing in a question mark at the end.
And if you were wrong with that assumption, it won't UB on you like C does.

In C you would also at least have to add a comment about where your assumption that an error can't happen comes from. In Rust you can just write that comment into code. For example with expect("The caller shall handle this").

>and that constantly working around the compiler has serious chances of making me introduce bugs

This "constantly working around the compiler" is just because you didn't learn the language.

Everybody who knows Rust knows that the compiler is extremely helpful when dealing with errors.
It often suggests what exactly to change.
It explains exactly what is wrong and often even provides a link to an article about the error with examples of the coding error and examples how to fix it.

> I have strong doubts about the validity of all rust code

Based on what? Your non existing Rust experience?

A lot of good stuff in there

Posted Feb 15, 2025 17:27 UTC (Sat) by intelfx (subscriber, #130118) [Link] (13 responses)

> The thing is, there are plenty of cases where I *know* it's valid, e.g. because it has been validated a few lines before one way or another, or because it's guaranteed by contract in an API or anything

Sure. Then someday preconditions change, API contracts get violated (accidentally, or perhaps maliciously), and the CVE database grows a new entry.

If Rust forces you to code defensively, then that is a *very good thing*. That's the entire point.

A lot of good stuff in there

Posted Feb 15, 2025 18:52 UTC (Sat) by wtarreau (subscriber, #51152) [Link] (12 responses)

> If Rust forces you to code defensively, then that is a *very good thing*. That's the entire point.

But are you sure that it's not C that forces you to code defensively instead, given that you have no safety belt and you're on your own. If on the opposite I say "it compiled so it's safe", I quickly learn not to care anymore about defensive approaches.

A lot of good stuff in there

Posted Feb 15, 2025 19:00 UTC (Sat) by mb (subscriber, #50428) [Link]

Why do you need additional defensive approaches, if the compiles proved that something is safe?

A lot of good stuff in there

Posted Feb 15, 2025 19:19 UTC (Sat) by intelfx (subscriber, #130118) [Link] (9 responses)

Well, I guess it's on the programmer to not become complacent towards other classes of bugs that Rust does not inherently protect from (e.g., logic bugs). Yes, we're seeing this in Rust with unwrap() proliferation. But you can write bad code in any language, that's hardly news.

I would argue that if we are honestly trying to say "C keeps us on our toes by virtue of being such a mess", it's not a good picture either way.

A lot of good stuff in there

Posted Feb 16, 2025 22:22 UTC (Sun) by mathstuf (subscriber, #69389) [Link] (8 responses)

> I would argue that if we are honestly trying to say "C keeps us on our toes by virtue of being such a mess", it's not a good picture either way.

I understand the argument in the context of automating life-risky processes[1]. But the difference here is that Rust *isn't* guaranteeing "all bugs are gone". It is guaranteeing "the compiler will tell you when your code has *a class of problems*" so that you *can* focus on the logic bugs rather than having to think about "is this index calculation going to blow us up later?" Anything that has software for life-risky bits better have some level of logic bug detection (e.g., comprehensive test suite, formal verification, etc.), but this is needed *regardless* of the language unless one is actually doing their coding in Idris or something.

[1] A self-driving car that is wrong 50% of the time keeps the driver "in the loop" more effectively than a 75% accurate self-driving car, but once you hit some threshold, there's a bad overlap between human complacency with how accurate it *usually* is and hitting the gap in the AI behavior.

A lot of good stuff in there

Posted Feb 16, 2025 22:33 UTC (Sun) by intelfx (subscriber, #130118) [Link] (1 responses)

> Anything that has software for life-risky bits better have some level of logic bug detection (e.g., comprehensive test suite, formal verification, etc.), but this is needed *regardless* of the language unless one is actually doing their coding in Idris or something.

That seems to align with what I was trying to say? If the only thing that keeps the codebase working is "bleed-over" of attention from memory correctness to logic correctness, that's not a sustainable practice either way (== we should instead be using tests and other stuff for logic correctness).

A lot of good stuff in there

Posted Feb 16, 2025 23:07 UTC (Sun) by mathstuf (subscriber, #69389) [Link]

Yes, I was not disagreeing with you. Sorry, should have been clearer that I was expanding on it.

A lot of good stuff in there

Posted Feb 16, 2025 22:58 UTC (Sun) by jengelh (guest, #33263) [Link] (5 responses)

>A self-driving car that is wrong 50% of the time keeps the driver "in the loop" more effectively

A mechanism with 50% error rate is a mechanism that quickly gets disabled by the user. ("Fine, I'll do it myself" is effectively keeping the user in the loop, I give you that.)

A lot of good stuff in there

Posted Feb 17, 2025 8:29 UTC (Mon) by mathstuf (subscriber, #69389) [Link] (4 responses)

Yes. I'm aware. I'm trying to clarify that there's a worrying gap where humans feel that they don't need to pay attention because it is "good enough" but ends up failing in the corner cases that aren't all that uncommon. Manufacturers try to absolve themselves of any culpability by saying "but we alerted the user" without considering the "we trained them to be able to ignore what the car is doing" situation built up over time.

A lot of good stuff in there

Posted Feb 17, 2025 8:36 UTC (Mon) by mathstuf (subscriber, #69389) [Link] (3 responses)

Actually, I have relevant experience here. My latest vehicle has some of these fancy new tech feature things in it. One is that it makes a noise when it has a traffic camera in its maps is coming up. However, all it does is play a noise and a small icon appears on the navigation part of the map. The distraction of trying to figure out what the car is telling me and only noticing the icon after multiple instances definitely felt less safe than it needed to be. Most alerts show up right in front of the driver, but those that don't are probably best left alone.

A lot of good stuff in there

Posted Feb 17, 2025 10:42 UTC (Mon) by Wol (subscriber, #4433) [Link] (2 responses)

The other worry is "the car knows best". My car is most definitely NOT considered a "self-driving" car, yet whenever I engage cruise control the car takes control of the speed, and completely ignores the saying "it's a limit not a target", and police advice "the speed limit is not a statement that that speed is safe".

It will (less so now) select illegal speeds, accelerate inappropriately, do all sorts of things. I tend to refer to it as a "granny racer" given that it tries to as fast as possible at every opportunity, yet is excessively cautious at others. It will accelerate, and then when it gets itself into trouble it will scream at me to brake ...

Cheers,
Wol

A lot of good stuff in there

Posted Feb 17, 2025 11:18 UTC (Mon) by mathstuf (subscriber, #69389) [Link] (1 responses)

The cruise control in my '89 Cherokee was like that: race up a hill, brake going down (I never used it because of that). Fair for something that cannot sense anything beyond its direct measurement sensors. I find it much better to go a *little* fast down the hill and lose some speed on small hills. I also had a good sense of how hard to press the accelerator to avoid unnecessary shifting. It is a lot better with adaptive cruise control today which can keep a set distance with the car in front at least. It still wants to race up/brake down to some extent, but at least it will do so within the constraints of traffic.

A lot of good stuff in there

Posted Feb 17, 2025 12:58 UTC (Mon) by Wol (subscriber, #4433) [Link]

Yup. Our previous car was "set the speed and that's what it goes at". Friends have got cars with adaptive control, which slows down to suit conditions. My car has got predictive control, which can be simply translated as "do the speed limit at every possible opportunity". Imho thats blankety-blank dangerous! and could be considered as illegal, seeing there's a requirement on the driver to "be in control at all times", which they're clearly not if the car is programmed to accelerate unexpectedly with no driver input whatsoever.

And it breaks a whole bunch of safe UI guidelines as well, such as allowing a driver to *override* the acceleration!

Cheers,
Wol

A lot of good stuff in there

Posted Feb 16, 2025 11:41 UTC (Sun) by khim (subscriber, #9252) [Link]

> If on the opposite I say "it compiled so it's safe", I quickly learn not to care anymore about defensive approaches.

Not possible. Not even remotely close. If you proved to the compiler that something is safe then you have proved to yourself that it's safe, as well.

Precisely because compiler is dumb and doesn't understand many “subtle” ideas – you have to “dumb down” that proof of correctness that you have in your head to the level that compiler would understand.

But compiler is also tireless and persistent. You couldn't convince it to like your code by writing long but incorrect explanation – like may happen with human reviewer.

> But are you sure that it's not C that forces you to code defensively instead, given that you have no safety belt and you're on your own.

Nah. The most “defensively programmed” code that I saw was in Java or Python. Often “uselessly defensively programmed”. Because there you don't need to prove anything to anyone, any nonsense that you may write would be “memory safe” (by the virtue of virtual machine that decouples you from hardware) and then you have to program defensively and check everything 10 times because nothing (except these redundant checks) protect the integrity of your code from bugs.