|
|
Subscribe / Log in / New account

Herb Sutter on increasing safety in C++

Herb Sutter on increasing safety in C++

Posted Mar 15, 2024 20:59 UTC (Fri) by mb (subscriber, #50428)
In reply to: Herb Sutter on increasing safety in C++ by paulj
Parent article: Herb Sutter on increasing safety in C++

You are completely right.
So? That means users can't complain about unsafe code? The developer is a "victim" for defending his unsafe code?
If I feel unhappy about unsafe code in a project that I use, I will complain. That is my right. It is the right of the developer to not listen. If the developer takes it personally, that is the developer's decision. He's not a victim. He's just wrong, from my POV.

Being wrong is fine. But don't blame others.


to post comments

Herb Sutter on increasing safety in C++

Posted Mar 16, 2024 0:40 UTC (Sat) by Wol (subscriber, #4433) [Link] (10 responses)

> You are completely right.
> So? That means users can't complain about unsafe code? The developer is a "victim" for defending his unsafe code?

NO, NO AND THRICE NO!

The developer is victim (a *real* victim) for having the temerity to disagree with his users about what HE wants HIS code to do.

It comes over quite clearly that those users you are defending didn't give a shit about what the developer was trying to achieve.

The developer wanted the code to be FAST. The users placed safety over speed. That's their right, but it doesn't give them the right to steal someone else's project. As others have said, they have the right to *fork*, not *steal*. You have no right to tell me my priorities for my code are wrong.

Cheers,
Wol

Herb Sutter on increasing safety in C++

Posted Mar 16, 2024 1:02 UTC (Sat) by khim (subscriber, #9252) [Link]

> You have no right to tell me my priorities for my code are wrong.

Don't publish it, if you don't want it to be looked on. Problem solved.

> That's their right, but it doesn't give them the right to steal someone else's project.

Once again: it wasn't stolen. Kim had enough integrity to leave without making life of everyone who just uses Actix-web miserable. Kudos for him.

That's more than authors of many other projects do when the majority of their users and/or codevelopers disagree with some decision: usually original project just dies and fork continues.

Think XFree86 or OpenOffice.org.

This doesn't make anyone happy, just makes everyone confused.

> The developer is victim (a *real* victim) for having the temerity to disagree with his users about what HE wants HIS code to do.

What about Oracle? Is Oracle a victim of unfriendly community which doesn't want, for some reason, to donate their code on terms that Oracle would like, too?

I don't like Kim for the games he played (and still plays) for the sake of benchmarks, but I appreciate his willingness not to involve innocents into these discussion (David Dawes-style).

It was his decisions whether to continue (and try to cope with stigma, somehow) or quit.

How can that be called “stolen project”?

Herb Sutter on increasing safety in C++

Posted Mar 16, 2024 9:43 UTC (Sat) by mb (subscriber, #50428) [Link] (8 responses)

>The developer wanted the code to be FAST. The users placed safety over speed.

I doubt it. Very much.
In Rust you almost never trade safety for speed. That's not how Rust works.
If your point is right, the project must be much slower today.
Is it?

>about what HE wants HIS code to do.

He can do whatever he wants to his code in private.
But if a developer publishes some code, the developer must be able to live with feedback.
And if a developer publishes code that goes against the fundamental rules of the ecosystem and receives the corresponding answers, then he's not a victim. He should either learn from the answers or step back from the project and continue it in private.
Be responsible for the things you do in public.

Herb Sutter on increasing safety in C++

Posted Mar 16, 2024 10:49 UTC (Sat) by khim (subscriber, #9252) [Link] (4 responses)

> If your point is right, the project must be much slower today.

Is it?

Yes. It's about 30% slower on benchmarks.

How much of it is real and how much is Dieselgate-style improvements is hard to say, but the majority of the Rust community vote went to safety and not to 30% speed increase.

Simply because most of the time it's better to spend 30% more on hardware then lose millions from outages.

> He should either learn from the answers or step back from the project and continue it in private.

Yup. That's precisely what happened here: Kim got his ntex to play benchmark games, community got something they may trust.

One may argue that “it's not fair” that community got the name, too, but we know from the history that it wouldn't have mattered in the long run anyway. Think gcc/egcs split, think LibreOffice/Apache OpenOffice, etc. The only thing that stubbornness of the developer brings in cases like that is damage for the innocent bystanders.

The fact that Kim got enough dignity to accept that is a big plus for his human character IMNSHO, but that still doesn't mean I would like to use ntex instead of actix-web, sorry.

Herb Sutter on increasing safety in C++

Posted Mar 16, 2024 11:08 UTC (Sat) by mb (subscriber, #50428) [Link] (3 responses)

>Yes. It's about 30% slower on benchmarks.

And before the removal of the unsafe code it was this much faster? It was on top of the list?

Herb Sutter on increasing safety in C++

Posted Mar 16, 2024 11:36 UTC (Sat) by khim (subscriber, #9252) [Link] (2 responses)

Yes. It was near the top, often #1. And that was, apparently, primary concern of it's author, his goal and achievment.

And it's not as if “bullying” started from nothing. Read this article, e.g. Does it look like a bullying?

Just read the whole discussion linked from there. Does this “car shouldn't have a seatbelts coz good drivers don't have accidents” or “bike helmets are for sissies, I wouldn't look cool if I would wear them” sound like a something you would want in an important project or library?

The problem was always not the number of unsafe in Actix-web but the attitude that removal of unsafe needs a justification, while using them when pesky compiler complains is fine.

What you have if you program like that is not Rust, that's C++ in the Rust skin!

That was the issue, not number of unsafe words per see.

And when Kim started adding safe functions which exported unsafe behavior to bring down number of unsafe code blocks… how do you deal with that?

AFAICS Rust community dealt with it in the only way that actually works: try to educate, but if that doesn't work then expell.

C/C++ community is full of such persons and it doesn't look as if any “safety plan” for C++ even acknowledges their existence.

Herb Sutter on increasing safety in C++

Posted Mar 16, 2024 11:58 UTC (Sat) by mb (subscriber, #50428) [Link] (1 responses)

>Yes. It was near the top, often #1.

Ok, that is quite unusual then.
I guess they took the other extreme and also removed all unsafe code that made sense? Or is the architecture so broken and it can't work safely and fast at the same time?

>The problem was always not the number of unsafe in Actix-web but the attitude that removal of unsafe needs a justification

Yes, I agree adding unsafe needs a justification. Not the removal.

Unsafe code is Ok, if it is carefully documented and thought through. The safe API to it must always be sound. Most of the time that means the unsafe code is down somewhere inside of a safe wrapper. But of course, that's not always easy to do and requires some serious engineering.

Herb Sutter on increasing safety in C++

Posted Mar 16, 2024 12:26 UTC (Sat) by khim (subscriber, #9252) [Link]

> Or is the architecture so broken and it can't work safely and fast at the same time?

The issue it that at certain point you reach the state where you have to make a choice. You may achieve, typically, about 50% of theoretical maximum performance while keeping architecture “safe and fast” bit at some point you hit the limit of what can be done that way.

Axum is developed independently and it's very close to Actix-web on benchmarks (currently 5% fater, but that changes over time, it was 5% slower year ago).

Beyond certain point you have to either do some hard choices or accept significant (though rarely critical) performance loss.

Things like the decision of Windows NT 4.0 to move graphics drivers into the “microkernel”.

Herb Sutter on increasing safety in C++

Posted Mar 18, 2024 14:42 UTC (Mon) by pizza (subscriber, #46) [Link] (2 responses)

> In Rust you almost never trade safety for speed. That's not how Rust works.

Incorrect; the fact that this code is explicitly conformant with the language shows that Rust does indeed work this way.

If the programmer wants to do something "unsafe" to gain some speed (or any other reason!) then they are free to do so. It is, after all, their own code.

....congratulations, Rust is finally beginning to have to grow up and face the harsh fact that in the real world, developers will write crappy [1] code that violates any number of "cultural norms" or "best practices" [2] and there is *nothing* that can be done about it!

Rust-the-project has no legal (or moral!) ability to ostracize or otherwise exclude anyone from writing software in Rust, putting it online with a warranty disclaimer, and random third parties incorporating/using it. After all, that's how Rust itself continues to exist. Indeed, any exclusionary actions will likely lead to some expensive legal trouble.

[1] in the eye of the beholder
[2] The parallels here with TFA's "voluntary practices to improve safety in C++" are richly ironic

Herb Sutter on increasing safety in C++

Posted Mar 18, 2024 15:02 UTC (Mon) by khim (subscriber, #9252) [Link]

> ....congratulations, Rust is finally beginning to have to grow up and face the harsh fact that in the real world, developers will write crappy [1] code that violates any number of "cultural norms" or "best practices" [2] and there is *nothing* that can be done about it!

Except the whole discussion started with example which directly contradicts your assertion.

Yes, developers will write crappy code, but that's not a problem by itself. It only becomes a problem when crappy code becomes popular and is starting to affect other people while developer ignores the issue. And that can be fixed. It was done pretty successfully, or else we wouldn't have had this discussion at all.

> Indeed, any exclusionary actions will likely lead to some expensive legal trouble.

Seriously? When was Kim reinstated as the lead of Actix-web and his opponents were sent to jail?

> Rust-the-project has no legal (or moral!) ability to ostracize or otherwise exclude anyone from writing software in Rust, putting it online with a warranty disclaimer, and random third parties incorporating/using it.

Indeed. But that doesn't mean that “nothing can be done”, as you assert. People are people, they find a way to achieve their goals. And if simple and obvious way doesn't work they find a roundabout way.

Herb Sutter on increasing safety in C++

Posted Mar 18, 2024 15:10 UTC (Mon) by Wol (subscriber, #4433) [Link]

> ....congratulations, Rust is finally beginning to have to grow up and face the harsh fact that in the real world, developers will write crappy [1] code that violates any number of "cultural norms" or "best practices" [2] and there is *nothing* that can be done about it!

And the assumption that "users of Rust" are "members of the Rust community" is tenuous, in itself ...

> [2] The parallels here with TFA's "voluntary practices to improve safety in C++" are richly ironic

The important thing with Rust - and what the REAL Rust community presumably say - is that you cannot write unsafe code BY ACCIDENT.

Either (a) you have to wrap your own code in "unsafe" markers, or (b) you should KNOW whether or not you trust other peoples' code you're importing. Assuming the library author isn't lying (and in general, why should they) then you should KNOW whether their code contains unsafe blocks, and more importantly WHY.

After all, if it's acceptable to call out to C/C++, surely a bit of unsafe Rust is a drop in the ocean :-)

Cheers,
Wol


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds