afdbcreid

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 ;)

If anyone can login, probably yes. If only trusted people can, probably no.

Nice idea, but I don't think you would want e.g. your hospital to have their systems suddenly turn off.

It's not "trivially exploitable". Two or three years ago, this would be a critical issue but require quite some expertise to exploit and exploits definitely wouldn't spread like that. LLMs are shaking the entire security industry.

If you maintain a 9 figures business, I would recommend to not rely on that and shut it down or at least do more.

Indeed, an attacker theoretically can access anything the PHP process has permission to access. However even without limiting permissions (also a good idea) that means the simple/published exploits won't work on your server, and there's a high chance criminals will look for other targets, assuming you're not targeted.