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.
I dont think they had much of a choice in 2008. Now? Sure. I bet a rust port is in the works.