afdbcreid

Cargo has no cache cleanup for `target` on stable.

Rust can do that just fine. https://doc.rust-lang.org/stable/std/cell/struct.UnsafeCell..... "some complex algorithmic properties that guarantee that the changes do not overlap" are exactly the place to use unsafe and encapsulate it.

If you mean things that formally create a data race, then C++ cannot do that either.

Like?

Not concepts, contracts.

Java vs. Kotlin is a different matter. It's still an open question if C++ even could match Rust's features, not to say if it (the committee) wants to, and the answer seems to be "no".

TIOBE is nonsense.

But, of course, there is still a lot of new C++ code written, more than Rust. I believe C++ will become legacy, but it's not there yet and even once that happens it'll take at least decades to stop writing C++.

A single bug can usually allow you to prove anything you want. Saying that this is how the proofs were achieved is a totally different matter though, and probably incorrect.

I won't comment on your entire comment, but this:

> To make it fast you need simd, which implied using unsafe

Is just false. There are multiple safe SIMD libraries for Rust that can exploit the full SIMD potential. Only very rarely they require unsafe for maximum performance and only to avoid bound checks.

The problem here is experimental evidence, which is the general reason they focus on mathematics.

No, the discussion at https://www.reddit.com/r/esp32/comments/1x3bmjh/ordering_esp... clarifies that the FCC ID was faked and the product was counterfeit.

The original post and the following discussion at https://www.reddit.com/r/esp32/comments/1x3bmjh/ordering_esp... clarify that the devices ordered were likely counterfeit and one had a fake FCC ID, so it was illegal to buy them irrelevant to the new law and likely why they were seized.

So the conclusion is not necessarily "don't buy ESP", but "verify what you're actually buying".

Since undefined behavior is impossible, that means there are only two options.

Sure, but in this context, the meaning was clear to refer to the differences from C++.

I agree that the best leaders are devastating. /s

Java and C# did kill C++. They just did it only in places they were feasible. People forget that before them, it was very common to write application and even serve code in C++. Now Rust is targeting its remaining niche(s).

Here's a tip most Rust users don't know about extension traits: if you put `#[rust_analyzer::prefer_underscore_import]` above your trait (and you're using rust-analyzer and not RustRover), autocompletion and the import assist will import the trait `as _` by default, which is very useful for extension traits.

> True, but there's no reason PGO can't eventually be implemented for native AOT.

It already is implemented, I believe. The thing I wondered is how NativeAOT could be faster, which is what GP claimed.

(Also, practically it should be slower because NativeAOT is based on the JIT and the JIT is worse at optimizing than LLVM).

You mean 200B?

That means those are probably builders and not setters. Do they change an existing object or a newly-constructed or to-be-constructed object?

It does but only on the stack, known as `ref struct`. E.g. `Span<T>` is an interior pointer, and this is extremely common in modern C#.

He writes regularly. Sometimes explaining C++, rarely explaining C#, sometimes historic stories, sometimes current stories, etc..

You can always not enable PGO of course. What I meant is that I don't expect NativeAOT to do better.

C# indeed does not have a catch-all ecosystem. But for some domains (servers, UI are a mess but also pretty good, CLI is plausible), it has a very good support. Like Java but nicer (this is subjective) and faster (this is not).

The most problematic missing feature for both C# and Go is interior pointers. But there are many others.

> and in some specific situations faster than Rust

I'm very curious to hear when? Because even the people that argue managed languages can be faster than unmanaged, say it because the JIT has better information at runtime. But NativeAOT cannot be better (and will be worse) than LLVM with PGO.

Indeed, some parts are possible to strip. Some not.

> ultimately everything is eventually possible against any given hardware.

Not everything, no. You can't run C# without the .NET runtime. Some parts of it are irreplaceable.

And the Rust optimizations to shrink binary size (see https://github.com/johnthagen/min-sized-rust) are commonly done in production when it matters, not just in WASM but also in embedded.

C# doesn't (and can't) use WASM GC.

The comparison is unfair for other reasons (the C# runtime was optimized for WASM size and the Rust not, it's possible to be much smaller in Rust), but it's still cool.

But not than assessment and controlled shutdown or access minimization. Turning off critical systems can result in deaths.

If you tell them where the problem is (even rough code area) - I'm 99% sure they can, and have.

If you only tell them to find issues in PHP - the strongest models probably still can, although they might find different issues ;)