afdbcreid

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.

> There are precisely two languages that make the most sense to implement the TypeScript compiler in: Rust and TypeScript itself.

Incorrect. I can maybe agree that those are the only perfect languages to implement tsc in them (if there is such thing). But in the real world, "perfect" does not actually mean "it's a good idea". Go made the most sense to port to (especially before agents), more than Rust (although C# could also be a good idea IMO).

I'm pretty sure a program written in asm by agents will not only be very unsafe, but also very slow compared to Rust, or even Go or Java.

> How can Codex write fast-to-compile Rust code, do tell?? Do tell!

Because memory safety isn't just about data races. In fact data races are far from Rust's most innovative or important feature. They are a side-effect, the designers had a nice system and saw it can also prevent data-races, so they said "sure, why not".

Also, Linux has (often significantly) faster compile times than Windows (due to filesystem performance, even with Dev Drive).

Behavior-wise, it does a lot more than the Codex CLI. The code of Codex is just of extremely poor quality. Just glanced, it looks like it uses at least two different HTTP server libraries (axum and tiny_http)! From quick check, rustc has 44 duplicate transitive dependencies (with different versions) while Codex has 109! And 2 dependencies are duplicated five times (in rustc the most duplicated are only three times)!

> How can Codex write fast-to-compile Rust code, do tell?? Do tell!

Like a human can, I suppose? Avoid extreme usage of generics. Avoid dependencies if not needed. Make sure you synchronize dependency versions to avoid duplicate code. Etc..

I meant, the progress to make Salsa support persistent caching is not advancing particularly fast. It does exist, but is preliminary.

I've never seen a proof that LLMs can fix memory safety in C or C++ like Rust does. I'll believe it when I'll see it.

And I prefer to work with Rust than both anyway. Such advancement (if it will happen) will only make other languages like Zig feasible for me.

(r-a team member here) The progress is in Salsa (the incremental framework we use), not in r-a itself yet. And there is progress but it's not particularly fast, it's also not a priority for the r-a team (though if you want to contribute, you're welcome of course).