Ah the traditional browser stress test from the .NET team. :)

Joke aside, yet another interesting read of all little improvements that go across all the runtime, and very much appreciated that they put out the effort to go through this detail level.

Thanks Stephen for this, it is very rewarding to read something very technical that is not AI slop these days.

Runtime async is certainly an interesting development. Really excited to see how this plays out.

I stared at my keyboard for bloody ages and came up with || instead of m.

nob end!

The software has to start clipping the audio above "100%", but I use it regularly in say, VLC, because I might want the volume slightly higher without increasing my whole system volume just to hear a quiet section. I rarely notice any degradation at 150%.

This comment is written by AI. "Fair enough" "over compensation" in one line. We should ban such accounts

FWIW the .NET 10 release also had 2 occurrences of "real" in literally the first paragraph.

I, too, tire of the constant YOU WROTE THIS WITH LLMs outrage. An incredible engineer dumped an ENORMOUS amount of technical knowledge at your feet, and you're commenting on the smell? Is that all you have to contribute?

I saw this too on the Ryan Carniato/SolidJS 2.0 announcement post. A world-class engineer makes a great blog post, and all the comments can focus on are the LLM-smells. Oh well. Any reason not to learn, I guess.

It’s a spinal tap joke.

For some people LLM-spotting feels like a sport they need to compete in

Backing you up on this. I smelled LLM and hit cmd+w.

No. If you're a low-level C language programmer then it is useful.

You don’t need to, but if you ever want to really optimise some code, understanding what it turns into on the target CPU really helps. Especially if you know the implications for any particular instruction (cost of memory access, potential branch prediction misses, etc)

The three* letter mnemonics are usually pretty easy to decode, even if you don’t know the architecture: anything beginning with ‘B’ will be branch, so ‘ble’ is branch if less than or equal. L and S based mnemonics are unusually Load and Store from and to memory. After that it’s understanding the stack and registers and you’re pretty much good to go.

Everything in assembly is loading something from memory into registers doing something basic with those registers, like add/divide/etc and then putting the result back into memory or using the result to make a decision to jump to processing instructions from another place in memory.

Most devs won’t ever need to know this stuff, but as someone who grew up with computers that could barely do anything without grinding to a halt (8bit computer, 2mhz processor, 32kb of RAM, 20kb of which is for the screen), knowing this stuff was essential; however I still find this stuff useful today, even with my C# work.

I am a bit of a performance tuning nerd though, so…

[*] or more

Not really, you only need to know you can get at it. One day you might be doing something like processing images or video and you are finding it slow and getting down to this level can be helpful. But it wouldn't necessarily be the first thing you'd look at.

Kinda. I use the `disassemble` function in Common Lisp quite a bit, and I can't work backwards to explain what a function is doing based on the disassembly.

BUT what I can do is see which functions are being inlined, which values are in memory versus in registers, see if things are being boxed and unboxed a lot, see if SIMD is being used, etc.

And more importantly I can compare two versions of a function to see which one looks better by those criteria. It's not perfect, but IME it works really well for guiding optimization.

I should add that I read the book "Assembly Language: step-by-step" by Jeff Duntemann, and wrote a Tic-Tac-Toe game in assembly ages ago, so that helps a bit to understand the syntax.

(And technically that's a patch file :-)

Assembly is honestly very easy to learn, especially ARM assembly, for the basics (even if whole-program assembly is still difficult). In the worst case, you end up learning something interesting.

C# takes a lot of different roles. If all you're doing is higher level stuff, say you're only working on a local GUI app where you're waiting on the user 99% of the time, you probably don't need to understand it. But you can also treat C# as more of a low level systems language, maybe you need to optimise some number crunching in a server - and then, as with any systems language, being able to read it may help.

All you could tell from this snippet is that .NET 11 eliminated 2 instructions, one of which is a branch.

You should learn assembly anyway, but it won't make this part any more insightful.

do you mean NativeAoT? it's mentioned a few times in the post

It still exists, it's still a bit quirky because of the way you need to match CPU to binary (e.g. some opcode extensions only existing on some CPUs)

With Claude I never had that problem. However Claude does not use the pattern by default

The dotnet team provides some agent plugins which solve some of these issues. I expect unions in dotnet 11 will need some skill updates too.

Buildings games in Unity feels like magic with frontier reasoning models.

Assuming you are competent with scene work and the various art pipelines, the rest of the problem is significantly easier now.

I've been using the Unity CLI to run arbitrary C# code against Unity 6 scenes without requiring domain reloads. It uses Roslyn to compile the snippet in a special Unity editor component instead of running the normal compilation pipeline.

The implications for a reasoning model are significant. Domain reloads in my projects can take 10-20 seconds. Compound across 5-10 tool calls and the difference adds up very quickly.

Always appreciate the continued perf gains. Our existing services just get faster for free, which is a nice win.

Very thorough write up. Clearly a lot of performance improvements across their stack. As if it wasn't detailed/long enough already, I would have loved to see some application-level benchmarks that gave a hint of the cumulative performance gains we should expect.

Saw a noticeable startup time boost on a recent project migration. Always appreciate the continued focus on speed.

We've banned this account for repeatedly posting abusive comments and ignoring our appeals to stop. If you don't want to be banned, you can email us and demonstrate an intention to observe the guidelines. https://news.ycombinator.com/newsguidelines.html

This.

The community is being diluted by…a different demographic!

I'm sure you know more about this than me, but EF works fine with SQLite for a project I work on. There are limitations, but I think there's a difference between the idea of EF deliberately not implementing some features for SQLite and SQLite itself not having support for some EF features (which is the reality I'm familiar with).

SQL Server is the flagship database project on the Microsoft side and that team surely has some imperative to facilitate the EF vision. It simply must be less of a priority for the PostgreSQL and SQLite maintainers to do so. Is that really a valid dig on the .net ecosystem, though?

I can't even remember the last time I used MSSQL with .NET. I'm embarrassed that I worked on projects now that were paying huge sums for licenses when .NET works so absolutely well with every other DB.

These days I just use EF with Sqlite on 99% of my projects.

That is not my experience. Sure, the background of .NET is windows, but in the last decade or so it opened up to other platforms, and so many shops prefer deploying their .NET based applications to linux for multitude of reasons. Along with this comes linux oriented culture. So windows culture is not tied to .NET per se, more so tied to certain shops I would say. Speaking from anecdotal experience, I have no numbers on this :)

looks like a large chunk of this was written by claude though :(

the technical parts are fresh as ever but the writing style is awful, man

For anyone who enjoys Stephen Toub’s deep technical articles like this one as much as I do - he also published another post today on migrating the Copilot coding harness from Node.js to Rust. Another great read.

https://github.blog/ai-and-ml/generative-ai/migrating-the-gi...

I hope there will be some kind of runtime async support for the current or a new asyncmethodbuilder. That is amazing work.

casey muratori would like to have a talk with you about the following :))

    // Approximately what the JIT generates
    if (animal?.GetType() == typeof(Dog))
    {
        ((Dog)animal).Speak();  // devirtualized, inlinable
    }
    else
    {
        animal.Speak(); // original virtual call, hopefully rare
    }