Herb Sutter on increasing safety in C++
Herb Sutter on increasing safety in C++
Posted Mar 15, 2024 18:36 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++
Being responsible to your users does *enable* toxicity? Really?
And yes, I think that I as a free software maintainer am responsible for delivering a good product to my users.
I do my best to avoid unsafe code, because it is risky for my users.
If a user comes and suggests to replace unsafe code with a equivalent safe alternative, I will be grateful. I will apply it.
If there is a vulnerability in my published code, I am responsible for doing my best to fix it ASAP or at least to clearly mark it as vulnerable ASAP if I don't have the time to fix it. Users depend on my work. Users trust me. That makes me responsible.
I do my best to reduce risk for my users.
So, very clearly: Yes. Publishing a free software project that has many users depending on it comes with a maintenance responsibility.
Even if they don't pay me a Dime.
If I would not care about my users, I would not publish my projects.
Posted Mar 15, 2024 20:46 UTC (Fri)
by pizza (subscriber, #46)
[Link] (12 responses)
No. What is toxic is users *demanding responsibiity* when it's been *explicit* from the beginning that they do not have any grounds to expect it.
What is toxic is fostering a culture that says that making those demands (without appropriate compensation) is somehow okay.
Posted Mar 15, 2024 20:53 UTC (Fri)
by mb (subscriber, #50428)
[Link] (11 responses)
Just stop publishing things, if you don't care about users. It really is that simple.
Posted Mar 15, 2024 21:57 UTC (Fri)
by pizza (subscriber, #46)
[Link] (10 responses)
You keep assuming that users are somehow owed "care" by some sort of divine right. [1]
If you want "care" then you must supply equivalent "compensation" [2]
And it really is that simple.
> And most important, don't complain, if all users tell you that you are wrong. Because most likely you are wrong.
You've been in this field far too long to truly believe that.
(And just in case you are actually serious, if the user has a different use case or expectations to what the author claimed to the software would provide, then yes, the user is *wrong*. But remember, this particular bruhaha was about the *style of implementation* of completely legal Rust code.)
[1] I've written software to sovle a problem my partner was having. That was the only user I "cared" about.
Posted Mar 15, 2024 22:46 UTC (Fri)
by mb (subscriber, #50428)
[Link] (9 responses)
You know what? The longer I have been in this field, the more I care about code correctness and about what other people say. I want to learn from other people. I know that I am wrong most of the time.
>if the user has a different use case or expectations to what the author claimed to the software would provide, then yes, the user is *wrong*.
That is something I absolutely disagree with.
I as the author do reserve the option to not do anything about it and keep the project as-is.
In free software there is no immediate "wrong" or "right". It's just that the "right" solution will continue to live. If I am actually right and 1000 people are wrong, then at the end I will succeed.
But unnecessary unsafe code won't succeed, IMO.
Posted Mar 16, 2024 22:40 UTC (Sat)
by Wol (subscriber, #4433)
[Link] (1 responses)
> That is something I absolutely disagree with.
Screw. Meet hammer.
Just because many users think Excel is a database, just because clueless idiots think that F1 racing cars would be an excellent fast delivery vehicle, doesn't make them right.
Actually, that F1 example is pretty apt. The project was designed for SPEED, not heavy lifting. Just because idiots want to use a racing car to deliver 44-tonne loads, words fail me ...
Cheers,
Posted Mar 16, 2024 22:43 UTC (Sat)
by mb (subscriber, #50428)
[Link]
That is not a base for further discussion.
Posted Mar 17, 2024 14:40 UTC (Sun)
by anselm (subscriber, #2796)
[Link] (6 responses)
If the user thinks they're “right” but the maintainer of the code disagrees, it is the user's privilege to fork the code. The user is not entitled to have the maintainer change the code, at no charge, to conform to the user's wishes, and the user most certainly does not get to hijack the original project by driving away the original maintainer.
The principle of free software is, you scratch your own itches. Scratching other people's itches, particularly for free, is entirely optional (even though some free-software maintainers take satisfaction from that, and if that happens, good for those other people). In fact, the whole idea behind free software in the first place is putting other people in a position where they can scratch their own itches and don't need to rely on anyone else to scratch those itches for them.
Posted Mar 17, 2024 14:52 UTC (Sun)
by mb (subscriber, #50428)
[Link] (5 responses)
Popular projects don't live in a vacuum. If a maintainer of a popular project makes decisions that many users disagree with, then the maintainer will have to live with the feedback.
Please go and take a look at the code. Some uses of unsafe were completely ridiculous.
>The principle of free software is, you scratch your own itches
That is only a very small part of it.
Posted Mar 17, 2024 16:45 UTC (Sun)
by paulj (subscriber, #341)
[Link] (4 responses)
I am sceptical that it is possible for an author to leave responses to PRs/CRs made on their own personal project that could justify a campaign of negative comments against them. A campaign apparently that included "death threats" and which the author felt included "abuse". How can an unreasonable response by an author to PRs on their own project justify anything _else_ but "Thanks for the code, I'll make those changes somewhere else myself"?
You keep saying those responses exist, can you show them?
The level of entitlement that is implied by what you are saying is completely off the scale.
Posted Mar 17, 2024 16:57 UTC (Sun)
by mb (subscriber, #50428)
[Link] (3 responses)
>included "death threats"
You surely have a link to that?
Posted Mar 18, 2024 15:07 UTC (Mon)
by paulj (subscriber, #341)
[Link] (2 responses)
"You alway face with rude and hate, everyone knows better how to build software, nobody wants to do home work and read docs and think a bit and very few provide any help. ... I started to receive complaints that docs are not updated and i have to go fix my shit. Encouraging. ... You felt betrayed after you put so much effort and then to hear all this shit comments, even if you understand that that is usual internet behavior."
https://github.com/fafhrd91/actix-web-postmortem
That is authoritative text on how the author felt. And I think we were all aware of that text before we started this discussion.
Now, your counter to this is that /his/ responses to the criticisms he received were unprofessional. I have asked for an example, twice now I think, but you've not given any, other than to claim I can find it if I look. Well, from reading around forums on this, the most heinous charge I can find levelled against the author is that he called a PoC change in a comment "boring":
http://web.archive.org/web/20200116231317/https://github....
I don't think /any/ response by an author, on their own issue tracker for their own personal project, could justify a campaign of "ostracism" (which in an online comment pretty much implies lots of toxic comments being left on various forums; from the target's own issue trackers, to reddit, etc. - i.e. abuse and bullying). I especially think that "this patch is boring" does not justify it.
The correct response is "Thanks for all your hard work on this code, and your generosity in open sourcing it - appreciate it, and I'll see about making my desired changes in my own version". Always really. At least, for anyone who is not a toxic ingrate.
If you had another comment in mind by the author, feel free to link to it.
Posted Mar 18, 2024 17:16 UTC (Mon)
by mb (subscriber, #50428)
[Link] (1 responses)
So? Maybe they are right?
> "nobody wants to do home work"
Also applies to the author.
> "and read docs and think a bit and very few provide any help."
Also applies to the author.
But it's Ok to have a different opinion.
> I have asked for an example, twice now I think, but you've not given any,
I said twice, that this has been posted already. I am not going to search the discussion threads for you.
> At least, for anyone who is not a toxic ingrate.
Do you realize that your definition of "toxic ingrate" also applies to yourself?
Posted Mar 18, 2024 18:13 UTC (Mon)
by corbet (editor, #1)
[Link]
Posted Mar 15, 2024 20:48 UTC (Fri)
by paulj (subscriber, #341)
[Link] (12 responses)
As a user of another project, you have 0 right to expect its author or maintainer has any responsibility towards you - unless you've some other contract with them.
Posted Mar 15, 2024 20:59 UTC (Fri)
by mb (subscriber, #50428)
[Link] (11 responses)
Being wrong is fine. But don't blame others.
Posted Mar 16, 2024 0:40 UTC (Sat)
by Wol (subscriber, #4433)
[Link] (10 responses)
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,
Posted Mar 16, 2024 1:02 UTC (Sat)
by khim (subscriber, #9252)
[Link]
Don't publish it, if you don't want it to be looked on. Problem solved. 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. 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”?
Posted Mar 16, 2024 9:43 UTC (Sat)
by mb (subscriber, #50428)
[Link] (8 responses)
I doubt it. Very much.
>about what HE wants HIS code to do.
He can do whatever he wants to his code in private.
Posted Mar 16, 2024 10:49 UTC (Sat)
by khim (subscriber, #9252)
[Link] (4 responses)
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. Yup. That's precisely what happened here: Kim got his 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.
Posted Mar 16, 2024 11:08 UTC (Sat)
by mb (subscriber, #50428)
[Link] (3 responses)
And before the removal of the unsafe code it was this much faster? It was on top of the list?
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 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 And when Kim started adding safe functions which exported unsafe behavior to bring down number of 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.
Posted Mar 16, 2024 11:58 UTC (Sat)
by mb (subscriber, #50428)
[Link] (1 responses)
Ok, that is quite unusual then.
>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.
Posted Mar 16, 2024 12:26 UTC (Sat)
by khim (subscriber, #9252)
[Link]
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”.
Posted Mar 18, 2024 14:42 UTC (Mon)
by pizza (subscriber, #46)
[Link] (2 responses)
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
Posted Mar 18, 2024 15:02 UTC (Mon)
by khim (subscriber, #9252)
[Link]
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. Seriously? When was Kim reinstated as the lead of Actix-web and his opponents were sent to jail? 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.
Posted Mar 18, 2024 15:10 UTC (Mon)
by Wol (subscriber, #4433)
[Link]
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,
Herb Sutter on increasing safety in C++
Herb Sutter on increasing safety in C++
Therefore, that cannot be the reason for the step down.
He could have just continued with his "me driving in the right direction and 1000 people driving wrong".
And most important, don't complain, if all users tell you that you are wrong. Because most likely you are wrong.
Herb Sutter on increasing safety in C++
[2] Which can include "happy wife, happy life" euphamisms.
Herb Sutter on increasing safety in C++
I think the user might be right.
But that means that I will *have* to leave the project, if the majority of users wants a feature that I reject.
I can still maintain the project without this feature in private or as a fork.
I really don't see the problem.
I would not loose anything.
IMO that is pretty obvious.
But ya know. I might be wrong. Who knows.
Herb Sutter on increasing safety in C++
> I think the user might be right.
Wol
Herb Sutter on increasing safety in C++
Herb Sutter on increasing safety in C++
I think the user might be right.
Herb Sutter on increasing safety in C++
That has nothing to do with "hijacking".
And so were his responses in the PRs trying to improve that code. Please look at it.
The major part of free software is collaboration, communication and technical improvements. All three of which the maintainer failed at, in the opinion of many users.
Herb Sutter on increasing safety in C++
Herb Sutter on increasing safety in C++
Herb Sutter on increasing safety in C++
Herb Sutter on increasing safety in C++
You see, the author complains about stuff that he does, too.
You are disagreeing with me and instead of going your way and forking this discussion to somewhere else, you keep on "harassing" me (by your definition) by trying to push your opinion onto me.
How rude. I am the victim. (Not really. It's called a discussion.)
It's a discussion that, I think, has run its useful course and beyond; perhaps we could bring it to a close, please?
Herb Sutter on increasing safety in C++
Herb Sutter on increasing safety in C++
Herb Sutter on increasing safety in C++
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.
Herb Sutter on increasing safety in C++
> So? That means users can't complain about unsafe code? The developer is a "victim" for defending his unsafe code?
Wol
> You have no right to tell me my priorities for my code are wrong.
Herb Sutter on increasing safety in C++
Herb Sutter on increasing safety in C++
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?
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.
> If your point is right, the project must be much slower today.Herb Sutter on increasing safety in C++
Is it?
ntex to play benchmark games, community got something they may trust.Herb Sutter on increasing safety in C++
Herb Sutter on increasing safety in C++
unsafe in Actix-web but the attitude that removal of unsafe needs a justification, while using them when pesky compiler complains is fine.unsafe words per see.unsafe code blocks… how do you deal with that?Herb Sutter on increasing safety in C++
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?
> Or is the architecture so broken and it can't work safely and fast at the same time?
Herb Sutter on increasing safety in C++
Herb Sutter on increasing safety in C++
[2] The parallels here with TFA's "voluntary practices to improve safety in C++" are richly ironic
> ....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!
Herb Sutter on increasing safety in C++
Herb Sutter on increasing safety in C++
Wol