The entire compute world was built on top of C and C++. Saying they're not fit for purpose doesn't seem correct. I think what you're really saying is they're not an optimal choice from a safety perspective.
> All of these need to be ported to Rust or another memory-safe language ASAP to prevent mayhem.
Seems like hyperbole... It might be ideal if we could snap our fingers and suddenly have rust ports, but I feel like you're discounting the effort that goes into doing that properly.
Which brings me to an interesting point. We have a web engine written in Rust. It's Servo. If the Rust port is so important to do as soon as possible to avoid mayhem, why aren't companies picking up Servo and using that?
I assure you that Microsoft knew for years that there were thousands if not tens of thousands of memory related bugs lurking in Windows. But their policy was "don't fix" (and "don't look") unless a remotely exploitable vulnerability was making headlines. Because every minute a developer spends finding and fixing bugs is a minute he can't spend on adding new features customers will pay for.
Luckily one of the perks of A.I. is that it makes large scale code migrations feasible in a timely manner.
And I can assure you that there were a number of MS research developed tools for finding memory bugs that have been used for decades at MS. There was never a don’t look / don’t fix policy while I was there. Quite the contrary.
Was there ever a time, apart from the short monthlong stint in 2001 after Blaster, when Microsoft developers worked on fixing memory related bugs?
Automated tools (before the advent of A.I.) can only get you so far. The bugs being found by A.I. today could've been found by eyeballs if companies thought it worthwhile.
When these tools were set up, on every code change you had to run these tools and deal with the output of anything it thought was a memory bug - part of the dev cycle before you could commit your code.
Did you have to scan the code looking for memory bug yourself with your eyeballs too? Yes, at every code check in you went through a paired peer code review before checking code in no matter your dev level. So two sets of eyeballs would look at every change.
So yes, we had to look for bugs in multiple ways no matter the type of bug on every single code change.
Then the testers would run all these tools and look at the output too (I was there when each org still had SDE Testers).
Did bugs still get missed? Of course, just like today even with today's new tools.
> Saying they're not fit for purpose doesn't seem correct.
I'll quite happily say they were never fit for purpose. C had a role in bootstrapping early software development in the absence of anything better but once Lisp, Delphi, Smalltalk and Java arrived on the scene then it, and its equally footgunnable variants, should have been pushed to the margins where hardware constraint was the primary consideration.
Writing a browser in C++ in the 21st century was ridiculous and irresponsible.
Ekhem. When Chrome was announced there wasnt Rust. And Java was a programming language for slow moving systems, with many a flaws and its own classes of footguns.
I dont think they had much of a choice in 2008. Now? Sure. I bet a rust port is in the works.
This is correct (I worked on chrome in 2008) it's important to remember that chrome's renderer was webkit, an existing c++ stack.
Chrome's stability innovation was to run different tabs in different processes, and the security innovation was then to sandbox those processes.
Rust would have been super nice but it wasn't an option then, and of course let's remember that Rust was developed by Mozilla specifically with the goal of making safer browsers.
Quite frankly, this post is massive set of unsubstantiated claims.
For starters, no one said the only problem with Chromium is C++. But it certainly contributes with some of the problems (specially those related to security). And, no, these bugs don't come from "noob programmers." They come from experienced engineers.
Then you just mention that removed some "unnecessary and unwanted" code. According to what standard? You? Would be nice if you went into specifics and provided some benchmarks. Instead we are forced to take the word that a user "rustfreeforme" (wonder which biases they have) made an polished fork, instead of, possibly, mangling the code in such a way that just benefits them and screws other people.
Finally, Rust doesn't: make the code more complex than C++, specially if using the STL; doesn't make compilations slower, as C++ and Rust compilation times are on par (and keep in mind Rust is very unoptimized here, where as C++ is slow by design).
> Oh no, it seems my one brief post wasn't long and detailed enough to immediately and totally convince some Random Doubter on HN, therefore my 'claims' are 'unsubstantiated.'
No, you just didn't cite any actual data, only assertions. Don't come with this excuse of "busy day", you had enough time to create an HN solely for spewing anti-Rust nonsense.
Keep in mind, HN is a place for intellectual discussions, not for dumping your pet peeves. If you don't actually have anything actually productive to say, it's preferable to omit yourself before the mods or the flags do that for you.
> Nah. It doesn't.
Then try to prove it. I already cited a source elsewhere, which you just ad hominem'ed. The burden of proof is now on you.
> It's definitely not possible for fluffybucktsnek to just take my word here. I wonder what biases he or she might have.
Yeah, what biases does the name "fluffybucketsnek" indicates? "Rust free for me" doesn't sound as impartial in this discussion. It just sounds like you came here for an ideological battle.
> Yes, you should just assume that's what must have happened, and then move on, blissfully unaware of how wrong you are.
I didn't assume anything. If anything, I kind of wish you did/could prove me wrong. You could, at least, post the code of your fork.
Instead, you need us to assume that all your claims, none of which has any sources, are true. All I did was show a different possibility.
> Sure it does. There is extra machinery/interfacing for all the extra Rust crap bolted on, and it gets more and more complex over time as they integrate more of the crap.
Every FFI introduces some manner of complexity, specially when one language (Rust) is more strict than the other (C++). I don't say C is complex because JNI is a hassle.
> Furthermore they vendor the entire Rust compiler, library, etc, all of which has to be compiled first before the browser.
That just seems like a Chromium project issue, not a Rust one. It's weird that for issues with C/C++ in Chromium, you blame the project itself, but for Rust, you blame Rust. Just like you don't have to vendor LLVM, you don't have to vendor Cargo nor Rustc along with the project itself. Even for compile times, similar strategies for cutting C++'s work for Rust as well.
Makes sense, but strangely, no one has responded to my question about why Servo hasn't been picked up, if Rust is such an important factor in browser engine implementation. People are calling using C and C++ "ridiculous" and "irresponsible" and "not fit for purpose". And yet, no one's using the alternative that's sitting right there?
Because Servo is unfinished, and companies have different priorities. For instance, Microsoft could've have been strict and formally checked code for Windows since the inception of constraint checkers, but they chose other priorities. Now they're are slowly trying to integrate Rust to help reduce security bugs.
People who believe in total unsuitability would be acting silly indeed. But most would agree that writing code on languages that provide better and safer tooling is a positive.
Sure, the main Rust compiler currently depends on LLVM, which is currently written in C++. But the rustc team might choose to follow a similar path to Zig and replace LLVM, or LLVM might get rewritten in Rust.
Finally, while most bugs are logical, the most damaging ones, security bugs, are primarily related to undefined behavior.
The problem is that you think Rust programmers despise C or C++. We don't. We just think there are better alternatives for modern development. In fact, a lot of Rust programmers were experienced C or C++ programmers.
And then you say:
> [...] your belief system.
What do you mean by that? What beliefs? This just sounds like projection.
> Please do so at the earliest opportunity, so that your language can actually become an alternative to C++.
It already is an alternative to C++. The fact that LLVM is written in C++ doesn't change the fact that you can write software that otherwise would be written in C++ or C, in pure Rust without writing a single C or C++ source nor header file.
What a reductive view of reality. That's like saying our entire world is built on assembly. That's just missing the point.
> Saying Rust is the replacement to C/C++ is like saying Python is the replacement to C/C++. No, not quite.
With analogy such as these, I see where the "No, not quite" comes from. For starters, we can write actually low-level Rust code enough to write kernels without needing to interface with C code, only raw assembly. I don't think Python can do that.
> I don't go to Google for advice on how to design software, thanks.
Good thing they weren't giving advice, but reporting that most security vulnerabilities came from just bad memory access, which contradicts your counter assertion. None of that is subjective. Whether you think they are the ideal programmers or not is irrelevant.
> All of these need to be ported to Rust or another memory-safe language ASAP to prevent mayhem.
Seems like hyperbole... It might be ideal if we could snap our fingers and suddenly have rust ports, but I feel like you're discounting the effort that goes into doing that properly.
Which brings me to an interesting point. We have a web engine written in Rust. It's Servo. If the Rust port is so important to do as soon as possible to avoid mayhem, why aren't companies picking up Servo and using that?