It’s not compiling C code, so that’s not really possible to answer. C is uniquely fast to compile, especially compared with more featureful languages like C++ and Rust.
In practice, C++ and Rust feel pretty similar, mostly due to the kind of code people tend to write in both languages (favoring static dispatch, generics/templates, etc.).
This isn't true, often even in trivial cases. Auto-vectorization is actually quite fragile in 2026. The reason is that it's subject to (a) scalar float semantics (i.e. the resulting code must not produce different results from the scalar version), and (b) a number of opaque compiler heuristics that sometimes work out, sometimes don't.
For example, consider you want to compute the average of a list of floats. The compiler cannot autovectorize this, because float addition is not commutative. However, it's much faster to do component-wise addition in groups, then a horizontal sum at the end, and then divide. Whether it matters depends on your use case, and the compiler unfortunately can't read your mind, so it has to be conservative.
If you try writing SIMD by hand autovectorization can mess it up, eg if you have to write a scalar trailing loop then it might try to autovectorize it.
Europe, like the US, is rich because it outsources lower-value production and focuses on higher value targets.
Chip production is not nearly as high in value as all the things you can build with those chips.
Local production is about supply chain security, not profit. Europe doesn’t mind one bit paying for chips produced somewhere else, but it does mind a world order where global trade is unreliable.
If we did mind a world were global trade was unreliable we have a military to match that concern, but we don't. The Houthi close the red sea for years and we can't do anything about it. Iran, attacked by the US, retaliates against us by closing the strait of Hormutz and we sit in the monitoring chair.
Don’t buy too much into the propaganda. Back when the US was a reliable partner that still understood how much it was gaining from global trade, it would have been idiotic to focus on building European military capability.
The thing that seems to have changed is that both the US and Russia are determined to destroy their own future.
If you’re building an AI data center, you are not a customer of ASML. You are a customer of NVIDIA, who is a customer of TSMC, who is a customer of ASML.
Building a competitor to TSMC is definitely something Europeans would like, but it’s also a multi-decade undertaking.
I define undefined behaviour as a bug in C++. Now C++ is memory-safe!
btw, it's not actually that hard to write correct code in C++, easier than in C because you have all the container types. The problem is that nothing will tell you when you write incorrect code - there's no guarantee.
UB is part of the C++ standard. Surely you can understand the difference between the C++ standard and bugs in compilers implementing the C++ standard. This is that.
Rust does not have an ISO standard, but it does have a language design, and if you knew the first thing about cve-rs (including what’s on its own Github page), you would know that this is an extremely confirmed soundness bug.
The cve-rs repo is not meant to be the toxic gotcha aimed at Rust language maintainers you seem to think it is. It’s a repro case.
> I define undefined behaviour as a bug in C++. Now C++ is memory-safe!
I mean, sure, insofar as such a thing would also imply that a) the standard would need quite a bit of cleanup/clarification work to not contradict your definition, and b) the main optimizing C++ compilers are miscompiling code, analogous to how cve-rs is a rustc miscompilation rather than an issue with Rust itself.
(Fil-C might be an interesting exception here, though IIRC its definition of memory safety is slightly different)
Since we are not at some point in the future where that correct compiler exists and there is only one official compiler, the distinction you make is practically meaningless!
I mean… no? It matters whether something is a part of the language or not, because it matters if you can write code relying on this behavior. Since this is a compiler bug, you cannot - the code will stop compiling the moment the bug is fixed.
There are no known instances of this bug being encountered in the wild, and if you look into it, you will see how extremely unlikely such code is.
> Isn't ten years enough to call something a feature of the language rather than a bug?
I suppose it depends on who is doing the classifying? From the developer's standpoint I'd imagine intent is all that matters: a bug is something that does not match developer intent and that is (eventually) expected to be changed to match the intent, while a feature is something that does match developer intent regardless of how old/new it is. From a user's standpoint I'd imagine it's a combination of developer intent and the user's reliance on said behavior, but IIRC in this particular case there's no known non-demo code that has organically run into this particular bug so there's little weight in favor of calling the bug a feature despite the devs' stance.
Also as GP said I think one needs to be careful to distinguish between the compiler and the language. IIRC the devs have known for basically this entire time exactly in what manner the Rust compiler fail to implement the rules of Rust the language, but a general fix has been blocked on long-running projects that have only recently been approaching the finish line [1].
There is no memory safety without freedom from data races. One is a prerequisite of the other. This is why languages like C# throw exceptions on unsynchronized concurrent access to some container types, and treat all property accesses as atomic.
> I have never seen real Go code (i.e. not code written purposefully to be exploitable) that was exploitable due to a data race.
And from tptacek in that same discussion [2]:
> The fact is that Go doesn't admit memory corruption vulnerabilities, and the way you know that is the fact that there are practically zero exploits for memory corruption vulnerabilities targeting pure Go programs, despite the popularity of the language.
I am, but you’d be surprised. All of the single-threaded languages are fine, for example. Very few languages are actually low-level enough to allow data races. C# and Java go to great lengths to avoid it.
Race conditions in general are another matter, and aren’t generally considered a requirement (though you can certainly create nasty bugs).
The claim is not there is no data races in Java programs. The claim is that Java programs are memory safe, because the underlying virtual machine memory model is free of data races.
Go does not have that.
(Of course also Java may suffer from memory safety issues on system boundaries to unsafe code and due to JVM bugs.)
All of those features just seem so gimmicky, and I could never imagine myself actually relying on them. If you are a functioning adult, these things are barely convenient, and the novelty wears off very quickly.
I will take a solidly engineered fridge with a good energy usage profile every single time over some overengineered wifi-connected piece of crap.
People pay 10-20% extra for food to be delivered to their door just for the convenience of only having to open a single app rather than call the take out place directly.
Never underestimate the value of convenience to people.
This hasn’t been the finding of the R4L project. Go look at their code, it’s shockingly safe outside of the parts that interact with extern “C” symbols, which naturally need to be unsafe.
In practice, C++ and Rust feel pretty similar, mostly due to the kind of code people tend to write in both languages (favoring static dispatch, generics/templates, etc.).
reply