https://opensource.org/osd

That being said, I don't expect someone filing a new patent after a RISC-V extension being published to last much longer beyond discovery in most cases, which should keep costs in lower end. Specially so in cases of bad faith.

The set of US patents, however, are not infinite and, IIRC, is also public. That said, IP laws are a mess.

Why?

Who said they have to? One can select a RISC-V configuration for a baseline for a particular purpose. Desktop? Choose the one that's most powerful.

ARM is more popular than x86 and is less consistent than it.

At worst, the post reads like a propaganda for VectorWare, but, overall, it reads more like their insights on the matter.

I don't quite remember the details of the shell crash, I only remember it being on a tool that've never seem crash due to a fault signal. It was somewhat amusing.

I also recall having my shell crashing (zsh or bash, I don't remember).

I don't want "To Be Right", I just don't want dunces slopping nonsense into this comment chain. Not my fault you fall into that group.

I don't need to assume Google's intentions and goals here. I want to see what they've done and the results they've reached with each action. I want to learn. You just want to reaffirm your delusions, that's why you have to pull the "you will learn" card rather than show objective metrics. If you really cared about quality, you would have them ready to present. Given that you haven't and even avoided doing so, it's safe to assume, as most of us have learned through experience, this to be a case of placebo at best. And placebo is not the sign of a good programmer.

Next time, provide some actual data rather than vague self-gloating. Then, we can have a discussion.

Nope, that's just your own prejudices speaking. We already cited features (seen in and inspired by other languages) and you handwaved them away with "I don't care". You are the one fixated on C and C++. You are a C evangelist, if I were to make a guess. And that's on you.

> In the latter case, why don't I just use the to auto-magically solve my C/C++ problems, rather than rewrite the entire universe from scratch? You know, like Google claims to have done for Chromium C++ sources in this very news article?

You certainly can. But to spin this the other way around: in lieu of the Bun case, why not use it to rewrite the project in Rust, Zig, D or any language of your choice (yes, even C)? Given the role harnesses have in keeping agents in check, it seems plausible that languages with stricter safety features help agents avoid common issues.

> This is the type of shit noobs are always wringing their hands about as they need maximum guardrails to cover for their ineptitude.

You seem to be forgetting that proper software engineering is just as much about managing developers and their skills as the actual code structure. If a tool helps noobs produce better quality code, specially ones without as many vulnerabilities, why not employ it? Also, it's not like experts are immune to mistakes either.

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.

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.

Good thing Rust doesn't just fix that one class of problems, but also provides better tooling to fix other classes too. Classes of problems that could be fixed with the other features of Rust mentioned later like the Hind...

> Blah blah blah. Most of that is just added runtime complexity that I could add to C if I wanted, but why would I?

...the vast majority of these features don't even run at compile time. Some of them can't even be implemented in C. For starters, show me an example of a Hindley Milner type system implemented for C (how can someone improve a strictly compile time feature, static typing, with a runtime implementation is beyond me). Or proper destructive moves in C or C++.

> Ada is the language to emulate, [...]

Good thing Rust also takes from Ada.

> Again, the actual successor to C/C++ looks nothing like Rust.

And that would be...?

It could. Switch that to C or C++ and the amount of logic bugs is likely going to triple.

> Rust is not a major advance over C/C++, only an incremental and quite limited one, [...]

"Nothing ever happens." I guess you could consider borrow checking, an actual module system, type classes, enum variants, compiler-integrated macros, async/await, etc. to be just small increments. (Theoretically, you can reimplement most of this in C++, like std::variant, but they don't integrate well into the language - having to declare a type just to use std::visit is certainly not as simple as using match).

> [...] which will require decades of rewriting perfectly good code to gain its dubious benefits, in the process introducing numerous other errors.

"Introducing numerous other errors"? Would be interesting to see an citation on that. From what I've seen, these "new errors" were already present in the original "perfectly good code", except the original also had instances of undefined behavior and logic errors from poor type modeling.

> But don't take my word for it [...]

Why would anyone other than your friends take your word? You could have substantiate your claims with actual evidence.

> [...] after the hype has worn off [...]

Which already did. Nowadays, I see more posts about Zig and Fil-C.

>[...] left with the sad mess that is Rust.

I went to read your comment history to see if you elaborated on this "sad mess" of Rust, but you didn't. How about you do it here?