Hacker News Reader

To be blunt, the security of the software that runs so much of the world is way more important than the feelings of some programmers who feel that their beloved languages are under attack.

With ransomware and other online attacks on the rise, the stakes are too high to allow safer alternatives to be developed at a leisurely pace by volunteers. That's why ISRG is paying to have the work done, and why corporate projects like Android are putting financial resources into this as well. It's not a sinister attack on your favorite language, just an effort to make software more secure.

Getting back to something you said in your previous comment:

> you will take my C++ out of my dead cold hands.

Is this really the hill you want to die on? To me this suggests a lack of perspective on what really matters. A programming language is just a tool, not something to get attached to. When a better tool comes along, be open to using it when you can. Especially if someone pays you to do so. I used to be a big fan of both Python and Lua. Now I usually don't use them for new projects, though I may still if I think one of them is the right tool for the job.

> With ransomware and other online attacks on the rise

Yeah we really need to show the world better defense is possible, or the US military, always hungry for mission creepy, is just going to subsidize critical infrastructure that should have never been private in the first place with free counter attacks or whatever.

The non-technical policy consensus is already "defense is hard", not "we're incredibly sloppy and we should be ashamed of ourselves", and so changing norms is really important and already an uphill battle that's just going to get harder.

> To be blunt, the security of the software that runs so much of the world is way more important than the feelings of some programmers who feel that their beloved languages are under attack.

As someone that have created software in at least 7 programming languages, including Rust, I agree with you, i only disagree with the recipe and the tactics used.

The bugs will happen, and contrary to the constant hammering sales pitch, Rust will not escape from them. Its like saying we are free from uncertainty. Its a false promise and anyone with real life experience in big software that are not neurotic about security like someone that only see software under this perspective would do.

Now, i believe Rust will likely have less bugs in the end? It depends most of the coder, but taking that variable out of the way, its more likely because its design is more strong into that direction.

Cant people fix security bugs once they happen? this will be the approach be it in Rust, C++.. Rust still will have to wrap insecure parts in unsafe{} blocks anyway, the same way a C++ coder do only that its not a keyword.

Im all for Rust having the right to tell its strenghts, i like the tech and what its offering, i can see why it can be better, but lets take care of the language used and the ideology behind our wording, its all i'm asking here..

Its time for the Rust community to grow up and stop pitching by shaming other languages, projects and communities, as if its the only reasonable answer like as if was some sort of master-race of programming languages and everything else should be replaced because its garbage.

This is not true, and while i like the tech, im worried about how a culture formed around bullying "inferior" languages will become with time.

The Rust community tries extremely hard not to shame other languages, projects, and communities. If you're talking about ideology, you will not see any ideology from the Rust project saying "This other language sucks." You'll just see "We're trying to build a high-quality technical product."

In fact, the Rust compiler itself depends heavily on LLVM (C++), Cargo fetches crates using libgit2 (C), rustup downloads updates using libcurl (C), Rust uses the C standard library (C) instead of directly making syscalls like Go/Zig/etc. do, memory allocation used to use jemalloc (C) until they switched to using the platform's C standard library for compatibility, etc. If there were any belief in the Rust community that other languages are garbage, those dependencies would have been replaced long ago.

If outsiders are saying that other languages are inferior, it is because they've examined the evidence and made up their minds, not because anyone is organizing a bullying campaign. Most of the people saying that do, in fact, have extensive "real life experience" with C and C++ and have come to their conclusions based on that experience.

Which is to say, I don't know any way that the Rust project could try harder to steer the language and ideology to be more respectful of other languages other than by making Rust a less compelling language.

I mean, I'm a fan of this project and happy about Rust's emerging role in the world, but that first sentence is obviously not true. Maybe they're trying harder lately.

It has been longstanding policy of the project itself to take this stance. That doesn’t mean that every single community member follows our example, though, or that everyone involved is perfect. But we made a deliberate decision to try and avoid this as much as possible.

Part of this was informed by my past experiences…

I mean, come on. Are you on a bunch of Slacks? At least one of them has a :resf: emoji. It's not just random Rust users; there are people deeply involved in Rust itself that disparage other languages. Maybe that's gotten better recently, but, again, come on: look at the "About" section on this project --- which is a great project! --- and how it talks about C/C++. I happen to think Rust people are correct about C/C++, despite loving in my bones how it feels to write C code. But that doesn't mean I have to pretend that there's a real norm in the Rust community of respecting other languages.

To me, this whole thing about Rust and its decorum in language debates reminds me of those projects that don't have codes of conducts, but instead a "be excellent to each other" policy. I believe what you're saying is something the Rust project wants to be true. But that doesn't make it so!

I say this with love as someone looking forward to the next couple thousand lines of Rust I'm going to have to write at my job.

I'm not on basically any Slacks, no. "RESF" is a meme, and it's a meme for a reason. There is far more complaining about it than it actually existing. I actually got halfway to publishing a quantitative analysis on this...

What do you think is disrespectful about the about page? Maybe this is like, part of where we differ. Stating facts plainly, and talking about tradeoffs isn't disparaging. This is an engineering discussion. This isn't contempt culture. This isn't some sort of "JavaScript is shit and anyone that uses it is an idiot," which is an attitude that is a problem and is corrosive. The about page doesn't even say C and C++ are bad languages! It says that characteristics of them make it unsuitable for a specific kind of application, due to requirements that they believe are important. That's it.

And yes, I do believe that it is something that the project and project leadership wants to be true, that is less true the further you get away from the project itself. We do not have the power (nor the desire) to control what every single person says on the internet. It is about leading by example. We do not make language comparisons in official marketing or documentation, when people show up and are flamebait-y and disparaging of other languages, we tell them "hey we don't do that here" and ask them to cut it out. To me, this feels very, very different and better than a lot of language spaces. YMMV.

The page literally includes the words "Using C and C++ is bad for society, bad for your reputation, and it's bad for your customers." This is not a good hill to die on.

The about page? https://www.memorysafety.org/about/ That phrase isn't on the page linked in the story either.

I fully agree that sentence is terrible. I did not see that when making my comment.

Is it terrible? Which part of it do you disagree with? I agree with it entirely.

I think it is far too broad to be taken literally. I also think, regardless if it's true or not, it's phrased in too combative of a way to be actually useful. Even if one does believe that this is true in all cases, presenting it this way isn't likely to help achieve that goal, and thus, it's a terrible statement. Finally, talking like this about technologies tends to beget an attitude and culture that ends up being unable to evenhandedly evaluate engineering tradeoffs. This makes you miss certain advantages, even in new technologies you may not like overall, which means you can't take advantage of the good parts.

It's on, "https://www.memorysafety.org/docs/memory-safety/"

Thanks.

To be fair, that sentence has linked information, that apparently no one is reading when complaining about it.

"bad for society" => "WannaCry cyber attack cost the NHS £92m as 19,000 appointments cancelled"

https://www.telegraph.co.uk/technology/2018/10/11/wannacry-c...

"bad for your reputation" => QualPwn vulnerabilities in Qualcomm chips let hackers compromise Android devices

https://www.zdnet.com/article/qualpwn-vulnerabilities-in-qua...

"bad for your customers." => Israeli Software Helped Saudis Spy on Khashoggi, Lawsuit Says

https://www.nytimes.com/2018/12/02/world/middleeast/saudi-kh...

Now lets get back complaining about the semantics of the sentence.

The complaint isn't about the semantics, but about it furthering an image of the Rust community that's working against it when it comes to actually fixing this. Being "right" is less effective if you are being insufferable about it.

Actually it is the security community, Rust isn't alone on this endeavour.

"Many years later we asked our customers whether they wished us to provide an option to switch off these checks in the interests of efficiency on production runs. Unanimously, they urged us not to--they already knew how frequently subscript errors occur on production runs where failure to detect them could be disastrous. I note with fear and horror that even in 1980, language designers and users have not learned this lesson. In any respectable branch of engineering, failure to observe such elementary precautions would have long been against the law."

C.A. Hoare stated on his Turing award speech done in 1981.

I can relate to other remarks or papers from memory safe systems programming all the way back to 1961, when Burroughs B5500 was released.

Yet many keep not paying attention, like Microsoft bosting 70% memory corruption issues on one side, while selling Azure Sphere security pitch having only C as available language, or bosting the use of C++ on WinUI, among many other examples.

Sure, but not particularly relevant to how the Rust community is perceived. Well, maybe, if people think you are more insufferable about any topic than the infosec community, that is actually kind of impressive.

70% of CVEs (bugs detected) being memory related does not mean that 70% of all software bugs are memory errors (bugs that exist). See survivors bias. Memory errors can be detected with the assistance of programs, so they are much easier to find than other bugs like logic errors, which require knowing what a program ought to do. I think the latter is much more insidious.

Lol I don't think any of Ransomware authors uses Zero day to get into system. Most are using maldocs or phone calls.

> not by virtue, but by force and politics.

It looks like virtue to me.

You seem to like C++. Look at the C++ direction of travel. Lifetime annotation? Rust has it, Bjarne now wants it in C++. Volatile access? Rust has it as methods read_volatile and write_volatile, and C++ is moving away from "cv qualfier" towards that same approach. Modules? Rust has them. C++ is now getting them. Backwards compatibility? Rust has editions, C++ is trying to do epochs.

C++ has spent years trying to argue that "Good" C++ won't have all the terrible problems, and so far it just hasn't worked out that way. I think the backward compatibility nightmare will consume C++ faster than it can try to dig itself out.

Here's the biggest problem: The people who can't leave C++ for Rust are also most invested in the features that prevent C++ from evolving to compete with Rust. If you're programming x86-64 machines with a C++20 compiler, you could go to Rust anyway, you'd be excited about a C++23 with lifetime annotation and epochs, but not so excited that you will throw effort at helping that to happen rather than Rust. Whereas if you're programming a specialist DSP and you're looking forward to getting C++ 17 next year when your vendor offers it, you can't move to Rust easily because there is no Rust for your DSP (yet?) but you also don't care about C++23 because your compiler vendor hasn't even announced a C++20 compiler yet.

Just a correction: Im not implying that Rust have no virtues, it has a lot, and its a very strong candidate to write new projects into whenever you think you need C++.

I would and will consider Rust always, and it probably will make sense to use instead. If my former post implied that i dont like Rust, im correcting here, because i like it and i thinks its cool technology and that it have virtues C++ don't have.

I was saying that, specially now that the language is more mature theres a thriving community around it, it can go by virtue..

C++ is where it is now because of its "killer apps". OS's, Browser, Games, a great amount of complex software with millions of lines of code.

And they are not garbage that need to be replaced. Rust taking over by virtue will be by creating killer apps in it. Showing itself as a great replacement for projects that can also be coded in C++.

Security folks invested in Rust saying that all new code in Android will now be coded in Rust its not replacing by virtue as important things like domain knowledge and getting used to a tool is also very important, and it will probably go away. Security is just one thing that is important in a project, its not the only one. But of course if you let the security folks decide, other important aspects will not be taken into account (I tought it was a really bad move by the way, as other problems not linked to security will appear with time).

Nobody with influence agrees with this assessment. Without taking the bait on this "C++ software is garbage" stuff: there's general acceptance that some significant chunk of memory-unsafe software, particularly the stuff most exposed to attack, or that runs on the systems we're most concerned with being attacked, needs to be replaced with memory-safe alternatives.

It is simply not the case that Rust's only role is in "new killer apps". Replacing C++ code is part of the raison dêtre of Rust.

You knew this was a pointless dead argument the moment Linus Torvalds began entertaining Rust kernel modules. The debate is over. That doesn't mean --- regardless of what any website says --- that all C++ software is "garbage", or that anyone is going to pry C++ out of your cold, dead hands. But it does make arguing about whether the maintainer of curl should accept funds to replace some of their code with Rust tedious and unproductive.

There is, yet WinUI selling point is that it is written in C++, just like macOS DriverKit and Metal.

I am betting with you how Microsoft will tout the C++ trumpet on the Windows 11 Developer talks next week, despite their timid approach to Rust on some of their tools now.

> yet WinUI selling point is that it is written in C++

That is probably intended to be a contrast with C# or JavaScript, not Rust.

So the marketing message goes something like this,

Microsoft Security Response Center puts out a guideline that states:

1 - Use .NET languages, Java, Go if you can afford a GC

2 - Adopt Rust otherwise

3 - If C++ must be used, take care and adopt C++ Core Guidelines

WinUI team,

"WinUI is powered by a highly optimized C++ core that delivers blistering performance, long battery life, and responsive interactivity that professional developers demand. Its lower system utilization allows it to run on a wider range of hardware, ensuring your sophisticated workloads run with ease."

https://microsoft.github.io/microsoft-ui-xaml/

I should also note that .NET is migrating their C++ code into C#, as they improved the language to add the features available on Sing# and System C#.

" In this release, we’ve continued, and even accelerated, the process of porting native implementations in the coreclr runtime from C/C++ to instead be normal C# managed code in System.Private.Corelib."

https://devblogs.microsoft.com/dotnet/performance-improvemen...

C++ force is too strong on WinDev, the very fact that Windows is the only mainstream OS that still doubles down on a C++ based GUI framework kind of proves it.

I am really curious if Windows 11 will finally be more like Apple and Google platforms, or keep going down this path of making certain APIs only available in C++, while forcing .NET devs to manually wrap them.

> If you're programming x86-64 machines with a C++20 compiler, you could go to Rust anyway...

No I won't, because the ecosystem that makes me reach out for C++ when not using either Java or .NET based languages doesn't exist for Rust.

Unreal/Unity class game tooling, CUDA/SYSCL class GPGPU programming, WinUI/QT/VCL class GUI frameworks, JUCE/openFrameworks/Cinder creative coding tools, LLVM/Gimple,...

So C++ with static analysers is still the way to go for those of us that don't care about building an ecosystem from scratch and rather focus on deliverables.

Force and politics are how you get shit done when people's minds are closed to virtue. Another example is the climate: we've had decades to solve the climate crisis voluntarily, and people did relatively nothing. Now it will take drastic measures to prevent the crisis from becoming a catastrophe, and believe me, governments WILL implement these measures to much hemming and hawing from the public, especially Americans. But it will happen because it has to, and the public twiddled their thumbs back when solutions were relatively easy.

Same with software. If you write critical infrastructure and are not actively involved in writing it in a memory-safe manner at the language level, then you are complicit in every hack that involves a buffer overflow, UAF, or other boondoggle inherent to C and C++ programming. C is the internal combustion engine of software: we've known about its dangers for decades but done nothing to fix it, and now the crisis has reached the point of catastrophe and we have to use coercion or shame in order to fix it.