As long as it's just receiving money it's whatever, we have lots of corporate sponsorship in the Linux kernel and in other components we use every day for computing. I wouldn't move to a different kernel/OS just because I agreed on some ideological stuff with their makers.

unmildifies

Those companies and firms back Rust because it's memory safe without a garbage collector, and great for general purpose programming or systems programming. That's super important for everyone, but especially large companies working on high performance or mission critical software.

Zig is not memory safe so it's a non-starter for these things, and has not proven itself in the industry anywhere near what Rust has.

This has nothing to do with Rust being "corporate" or anything wrong with Rust.

I think I did! Rust has lots of corporate and political backing from big companies and political/security firms (FBI, pentagon etc) and zig is more free and has less governance and backing, less politics involved.

You probably could implement some workarounds in the compiler, though the linked Oodle blog-post does a good job of explaining why that isn't feasible in this particular case:

The bug is not a flaw in the CPU logic as such, but rather the result of the CPU physically degrading due to design flaws. And for whatever reason, that degradation most frequently manifested as the mov instruction occasionally doing the wrong thing. Though the blog-post also makes it clear that this is not the only issue resulting from this degradation.

Moreover, the mov instruction is a very common instruction, so a general workaround for this problem would affect large parts of the resulting programs. For example, the 1-line function that Godbolt uses as its example code results in 3 mov instructions when compiled without optimizations:

int square(int num) {
    return num * num;
}

becomes

"square(int)":
        push    rbp
        mov     rbp, rsp
        mov     DWORD PTR [rbp-4], edi
        mov     eax, DWORD PTR [rbp-4]
        imul    eax, eax
        pop     rbp
        ret

I would say Rust is more similar to java and Zig is more similar to C in that manner

You're gonna have to elaborate on that… How so?

How so?

I would expect it to apply to everything. You don't want to hit the issues in the first place.

It seems like a weighing of (safe) CPU support vs better generated instructions. If you don't care about a CPU generation, maybe because it's old enough, or your target environment is restricted/controlled, you don't enable it. If it's still out there and you want to or have to support it, you enable it.

I would imagine a "CPU-Workaround--" or something, and if you enable it, it completely evades the instruction constellations that cause the issues and uses alternatives instead.

Maybe it could have "evade completely" (same code runs on every CPU) and "generate cpu-checked workaround code branches" (faulty CPUs execute a different branch) as alternatives.

Also, Foundation members have no say on the direction of the language.

This is probably not worth losing sleep over. OpenAI are not the only Platinum Member, nor the biggest contributor to the Rust Foundation. Microsoft and Google have both contributed at least $1 million each, going by previous press releases. See here for a list of the foundation members

(mild panic intensifies)

uhhhhh

Makes sense now! Also, the post itself is good! (Pre-knowledge of the terms possibly helped you, yes.)

I was kinda surprised as well that you couldn't annotate the function or something. But then again, an attribute like "please don't use this instruction" sounds like something that's pretty hard to integrate in the code generation. What kind of flag would you use? I don't think you want to apply that flag to everything, just to that particular function.

zlib-rs => crate replacing non-rust zlib
firefox => where the replacement is happening
trifecta => the foundation sponsored to develop the replacements

Maybe I'm influenced by the fact that I pre-knew all of the above. But as I wrote, it's quite ironic choosing this perfect title in particular to complain about 😉.

On the topic of low(ish) level dependencies getting incrementally replaced with Rust rewrites, a Google employee did a presentation on the same topic recently.

I can assure you it's not "automated" or anything like that. I usually prefer to see an excert of the post that caught the poster's attention, or any info in that realm really.

For me it's interesting because nowadays we have frequently too much information, not too little.

If the majority of the title (and body) is the name of a company or organization, I get cautious.

Shouldn't compilers (in this case LLVM) cover such CPU bugs with flags? So users can commit to either evading CPU bugs or not.

It'd also be a good entry-point and overview of what CPU bugs are out there. Without it, how are you supposed to know about and evaluate them?

People usually like at least some minimal context attached, in case they are not familiar with the topic at hand.

But as it happens, the title of this specific post is rather self-documenting. So I'm not sure what's "non-descriptive" about it.

Or perhaps we have automated complaining now, pushing against automated low quality (re-)posting. And we got caught in the middle as remnants of the genuine human interaction that used to take place online 🙂.

Posts usually show a summary through the website provided metadata, though, but this website doesn't.

Dunno if that's what the original commenter was thinking of, though.

I honestly don't think that is very usual. I would even say it's more usual to see bare links posted, at least if I look in my own feed. But maybe that's just the sort of stuff I follow.

People usually include a summary or first few paragraphs in the text of their post along with the link.

What do you mean?

That's a very... non-descriptive post?