Footguns
Footguns
Posted Jul 11, 2021 15:55 UTC (Sun) by khim (subscriber, #9252)In reply to: Footguns by pizza
Parent article: Rust for Linux redux
But they don't disable warnings because of malice! They disable warning because “they know better”! And, indeed, the original plan explicitly called for compilers writers to augment the language by providing a definition of the officially undefined behavior. To make life of such developers easier.
Instead C and C++ developers have painted themselves into the corner: by repeating mantra “nothing except the standard text matter to us” they made said standard text sacred. Now, when they have found out that some optimizations they actually perform are unsound and don't obey the letter of said standard… attempts to change the standard are rightfully and correctly perceived as an act of sabotage.
Maybe if for last couple of decades compiler developers have actually listened to the users and not used said standard as fig leaf… then maybe, just maybe reaction would have been different. Even then: it's not guaranteed. Backward incompatible changes, especially not detectable at compile time is not something which users would welcome.
But at this point it looks as if the only sane decision would be to switch to some other language. Where developers actually listen to user's complains.
Rust is one such language.
Posted Jul 11, 2021 16:09 UTC (Sun)
by pizza (subscriber, #46)
[Link] (9 responses)
"Sufficiently advanced stupidity is indistinguishable from malice"
> Instead C and C++ developers have painted themselves into the corner: by repeating mantra “nothing except the standard text matter to us”
Because "The standard" is all that actually matters, because it is the contract that everyone involved relies upon to determine what to expect. If "the standard" is inadequate, then the correct thing to do is *improve the standard*
Otherwise you're just asking for the compiler equivalent of IE6 ("standards be damned, we're the ones with the market share") and OOXML's "autoSpaceLikeWord95" parameter.
> But at this point it looks as if the only sane decision would be to switch to some other language. Where developers actually listen to user's complains. Rust is one such language.
Which users are Rust's stewards listening to? What happens when (if?) its userbase grows large enough that their requests can not be reconciled? Will the "losing users" then have to switch to a new language whose developers "Actually listen to users' complaints"?
Posted Jul 11, 2021 17:00 UTC (Sun)
by khim (subscriber, #9252)
[Link] (6 responses)
Then why haven't compiler developer have done that? Why the heck they made signed integer two's complement without making integer overflow legit? No. I'm asking about some kind of dialogue where users talk to compiler writers and they listen (instead of dismissing any and all concerns with reference to the standard). Note that story with IE6 ended not with some kind of all-compassing “finished and sacred” HTML5 standard, but with living standard. Which tries to reconcile concerns of different actors. Nothing like that happened with C/C++ developers. First they ignored any and all concerns about standard craziness. And then, when they found out that standard is problematic for them, too — they decided do change it. And retroactively turn valid programs into invalid. That is why it was pulled in through “defect report” venue (and not through “changes for the next version” venue). They want to try to pretend that standard always meant to say what it doesn't explicitly say. And don't plan to offer any compatibility options. Have they really though compiler users wouldn't notice that bait-and-switch tactic? Please watch (or read) that presentation by Stephen Klabnik. He explains that better than me. But the short answer is: they try to minimize number of unhappy users. Not by applying some crazy rules buy by listening to a different people and trying to reconcile opposing POV. They have found out that when you actually listen and explain people very often are willing to change their opinions and compromise which is acceptable for everyone (or almost everyone) involved is possible more often then you may think. Right now they are brainstorming the asynchronous programming story and, frankly, I'm 99% sure they would reach a much better compromise then what C++ got and instead of something everyone hates equally they would reach to something everyone would accept equally. We would see, I think. Nobody have the crystal ball and can predict the future. Anything can happen but I just don't foresee the situation which was the norm for last 10-15 years in the C/C++ land where opinions of the wast majority of “normal developers” were ignored “because sacred standard gave us that right” and the “my way or the highway” approach to the treatment of UB was normal. In spite of the fact that standards committee explicitly said that UB identifies areas of possible conforming language extension it was almost never treated as such. Instead of looking for a way to remove UB where it made sense (to make language easier to work with) compiler developers always seeked a way to exploit and amplify them (to win these all-important 2-3% on SPEC CPU benchmarks). That is something I don't see in Rust so far (but then, it only has one official compiler thus benchmark games don't matter… yet). Consider how that issue with signed overflow was treated. First of all: there are large and detailed document which explains the decision. Second: for the ones who want/need wrapround there are standardized handling of it. And, most important, it was clearly decided that overflow may be handled differently, but it absolutely, under no circumstances can be used to remove code from the program. It's not a UB. Now compare to what happens in C/C++ land.
Posted Jul 14, 2021 16:21 UTC (Wed)
by pizza (subscriber, #46)
[Link] (5 responses)
Here's what I see.
Rust is able to be more "responsive" to users' complaints than the C & C++ folks because it is young, immature, and not widely used. [1] I'm not saying that pejoratively; this gives Rust a _lot_ more freedom and flexibility to rapidly evolve and improve, and this is also reflected in the processes that Rust uses to improve itself. Its lack of users (and diversity of use) means there's very little at stake, and the single-implementation monoculture ensures everyone is using the same tooling with changes becoming rapidly available.
However, C & C++ have many independent implementations, and (due in part to a 30 year head start vs Rust) have many orders of magnitude more lines of code, projects, and active coders out there, with the inevitable (and _considerable_) historical baggage that entails. Each of those stakeholders has different requirements and goals (that are, more often than not, inherently confliciting), and collectively represent a _lot_ of investment. This means the standardization efforts operate much more conservatively, slowly, and *formally*, but perversely, that many-independent-implementations state of affairs means that there's _less_ need to actually participate in standardization efforts. (This is why C++ was such an utter interoperability mess for so long..)
But yes, standards groups fall back to their standards documents, which are simultaneously sacrosanct and highly fungible depending on the context and what's being discussed. Welcome to the wonderful world of diverse stakeholders that only occasionally pull in the same direction. If Rust succeeds in becoming anything more than a small niche language, this diversity (and inevitable impact on velocity & responsiveness) will happen to them too... indeed, it's more likely that achieving this diversity is necessary in order for Rust to succeed.
Rust seems to have the basics/core down pretty solidly now; ie the language meets their own goals/needs fairly well. But trying to grow the tent means they have to appeal more broadly -- and beating/berating the folks you're trying to convince isn't exactly endearing. Putting questionable PR aside, the harsh reality is that these other prospective users need a gradual path to adoption, and Rust is still quite awful about integrating into both predominantly non-Rust codebases and into a larger systems as a whole. Sure, they're working on improving both, but again, software & system maintainers tend to be _very_ conservative and have seen plenty of "don't worry, we'll solve these [very hard problems] later" hot-and-shinies come and go.
FWIW, personally, if I were to start a new project today I'd probably try it in Rust, but there's zero advantage to rewriting my existing C projects.
[1] The product at $dayjob that my team will eventually integrate into has over 5.5M lines of in-house C++ code. Once you include stuff shared with other in-house products and 3rd-party code/libraries it goes up considerably further. It's safe to say that my employer easily has tens of millions of lines of C++ code in production today, and I wouldn't be surprised if the actual number is closer to 100 million. And this is just _one_ (admittedly large) organization.
Posted Jul 14, 2021 17:19 UTC (Wed)
by khim (subscriber, #9252)
[Link] (2 responses)
True, but what about Java, Python, or, IDK., C#? Python is 30 years old, Java is 26 years old. And amount of code written in both is comparable to C or C++. Yes, there are tensions between developers of these languages and users of them, there are always are. But nothing like the situation with C and C++ where concerns of users are usually dismissed with magic phrase “you don't know C (or C++), read the standard, please”. I don't know of any other language where “holy standard gave us the right, you must bow before our might” is the normal attitude. In fact even when Spidermonkey or V8 developers justify something with reference to standard it's usually with note of sadness and intent to help. You can certainly feel that they genuinely want to help the developer, user of their language, but they have to follow the standard rules, too. So they are looking for the compromise (and often finding it: by showing standard-compliant compromise, adding certain feature or just offering a way to refactor code to make it better). For them the fact that standard is, in some places, crazy and stupid is a limitation which they still have to follow, but attempts to make life of users easier are equally important. And if they can fix the issue in a new version of a standard — they do that without leaving pile of footguns behind (except where backward compatibility make them do that). Java never had such an issue, despite there being lots of players, too. No, I think the toxic C/C++ compiler developers attitude comes from the mere fact that most C/C++ developers, perversely enough, are irrelevant for them. They are captive audience. Either they need to use proprietary compiler to develop code for certain hardware platform. Or, they are not even directly relevant at all if compiler developer comes from some university (then the need to publish paper is much more important than the need to send time thinking how real users would use the compiler). It also doesn't help that C and C++ are last widely used languages which were developed before rise of the Usenet, mailing lists or web sites. The actual software developers are not their customers — that is the issue. Everything else is secondary. That's exactly why I think trying to bring these folks by talking about virtues of Rust is pointless. Ultimately it all would be decided by Google and Microsoft (and other large companies to lesser degree). If their management would like Rust and divert development resources from C++… house of cards may implode very quickly. If not… then Rust would remain strong yet niche player like Haskell for years. In both cases it makes little sense to try to bring C++ developers to the Rust bandwagon: if Google and Microsoft would continue with C++ then they would be able to use for years, if they would back Rust instead then they would have to come to Rust camp. It's probably better to bring Javascript, Python or maybe even Java developers: users of these language are not accustomed to the deal with languages composed almost entirely from footguns, but they appreciate speed. C++ developers would join later… if that would even happen at all. That sounds like a sensible approach. Yes, sooner or later, without constant vigilance, these C projects would die because new generations of compilers would find a way to compile them onto nothing with a very powerful prover that would prove that something triggers “undefined behavior” in them, but while they work… why spend efforts to fix something that is not broken? I'm 99% sure Google and Microsoft would find a way to solve that issue. Maybe by creation of Rust++ (similar to how Apple solved that problem with Objective C++ years ago — language which makes zero sense on it's own, but allows one to write a glue code which connects Objective C code to C++ code). If they would decide it's worthwhile for them to switch from C++ to Rust, of course. I don't think they would bother to both push C++ forward and write something like that.
Posted Jul 14, 2021 18:45 UTC (Wed)
by pizza (subscriber, #46)
[Link] (1 responses)
Yes and no -- Java was completely proprietary until 2007, and to this day is still ultimately under the control/ownership of a single (very litigious) company.
Posted Jul 14, 2021 19:17 UTC (Wed)
by khim (subscriber, #9252)
[Link]
But why would that force it's developers to hear complains of the users? Wouldn't that make reponse “you have violated the spec, thus your program is wrong, just go and fix it” more attractive, not less? Can you show me any other language at all where response to some complaint from users (and they are numerous for any language) starts and finishes with reference the the standard, reference manual, or some other documentation? Not “if we do X then we would have this, if we do Y then we would have that, and we if we would do Z then we would have something else and standard says we should do Y thus that's what we do”, but flat out refusal to even hypothetically contemplate the notion that what the standard says may not be a good idea to do at all? Where standard is turned into holy gospel instead of being perceived as one (albeit, sure, very serious) argument among many? I just couldn't recall such an attitude among developers of any other language. Consider shifts: Java and Rust pick “modulo size of operand” choice while Go picks “mathematically defined shift” (where Can you show me one place where developers of any other language are doing that? Knowingly make the life of their users hell just because their “holy gospel” say they have the right to do that — while pointedly and explicitly ignoring and and all other arguments? I'm not saying that it never happens. I just haven't seen that. So if you have such examples — can you show me them to make our discussion more concrete?
Posted Jul 14, 2021 18:03 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link] (1 responses)
It might make sense to eventually rewrite legacy codebases (like Unix command line tools) just to make them more approachable for new people.
Posted Jul 14, 2021 18:28 UTC (Wed)
by khim (subscriber, #9252)
[Link]
It may be fun project for someone who may want to learn Rust, but it don't think right now it would make them more approachable for new people. Rust currently much more popular, than, e.g., Haskell, but still there are many times less developers than C or C++.
Posted Jul 12, 2021 9:19 UTC (Mon)
by Wol (subscriber, #4433)
[Link] (1 responses)
> Because "The standard" is all that actually matters, because it is the contract that everyone involved relies upon to determine what to expect. If "the standard" is inadequate, then the correct thing to do is *improve the standard*
You're missing Khim's point. Whether he is right or not is irrelevant here - what has allegedly happened is that the compiler writers have BROKEN THE STANDARD and, instead of trying to fix the compiler, are trying to fix the standard instead.
Oh - and as for the standard being inadequate, the correct fix is to *remove* UB, not convert what was defined behaviour into UB, which again is Khim's point.
Cheers,
Posted Jul 12, 2021 10:39 UTC (Mon)
by khim (subscriber, #9252)
[Link]
The sequence of events:
So the end result: P.S. I would have been more sympathetic to the woes of compiler writer is they would have been more sympathetic to woes of developers. And requests of “why shift by 32 turns my program into pile of goo?” (even if after said shift I do
Footguns
> If "the standard" is inadequate, then the correct thing to do is *improve the standard*
Footguns
Footguns
> Rust is able to be more "responsive" to users' complaints than the C & C++ folks because it is young, immature, and not widely used.
Footguns
Footguns
Footguns
1 << 100 is 0). Both choices have pro and cons, both make some sense, but C compiler developers pick “if we ever catch you doing that we would punish you” which have only one justification: “standard allows us to do that thus we will do that”.Footguns
Footguns
Footguns
Wol
What you are saying is correct, only there are no allegedly there.
Footguns
-fwrapv/-ftrapv, but AFAIK -ftrapv was broken for years with GCC and I'm not even sure it's fixed now).
punish the users optimize well… and they needed them because they already miscompiled certain standard-compliant code.
x & 0 which, you know, in normal math always produces zero) answer was not “standard gave us right to assume that, go away” but something more reasonable (e.g. some kind of intrinsic which I can use for that). But after decades of both insisting that users have to follow standard to the letter and apparent refusal of developers to follow it… it's hard to see what kind of dialogue is possible.