Rendered at 21:08:23 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
tiffanyh 19 hours ago [-]
This post was so refreshing to read, because it reminds me of a time of solid engineering & writing in a pre-AI era.
I’m afraid posts like this might become fleeting.
satnhak 5 hours ago [-]
I thought the exact opposite a few lines in, and that's a shame because I'm genuinely interested. But it was unreadable.
rkagerer 4 hours ago [-]
[dead]
7bit 10 hours ago [-]
Really? I got bored throughout the 7 paragraph (or whatever number) in unrelated introduction.
nozzlegear 6 hours ago [-]
This is what tiktok and vibe coding do to a mf's attention span
Pannoniae 13 hours ago [-]
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
sltr 5 hours ago [-]
Agree. A whole tree of comments agreeing with you is not appearing on this post because that's how HN works.
I loathe LLM prose, no matter who posts it. It earns a quick cmd+w.
My prizes for spending the internet points to say this are the joy of resisting normalization of illiteracy and a tacit camaraderie with the hundreds of others who agree but won't comment or upvote.
Scharkenberg 13 hours ago [-]
The writing style is similar to the other articles by the same author. He has been doing this for years. I have no idea what your problem with the actual content is.
mpawelski 7 hours ago [-]
idk, it really feels like it was redacted by LLM. At least the content is good as usual.
lukehoban 18 hours ago [-]
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.
Outside of the outstanding optimizations .net has made (plus async runtime), what I really enjoyed was the reworked entry section. Stephen reiterated all the concepts from the past Performance Improvement articles to really showcase the layers of optimization techniques and how the can transform.
adzm 2 days ago [-]
Runtime async is certainly an interesting development. Really excited to see how this plays out.
rsalus 20 hours ago [-]
these blog posts have really turned me into a dotnet evangelist. love the framework & language.
refactor_master 19 hours ago [-]
Too bad there’s such a lingering culture of Windows and creaky Lenovos and Dells around it. I’m sure it can be different, but I’m not taking my chances ever again. Simply not worth my sanity.
ctenb 14 hours ago [-]
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 :)
paulirwin 8 hours ago [-]
It is different. I do nearly 100% of my .NET development on macOS, only dropping into Windows to support .NET Framework users of open-source projects I work on, and we deploy exclusively now on Linux containers. The apps I maintain haven't touched a Windows server in years. My colleagues (and OSS co-maintainers) use a mix of macOS, Windows, and Linux. I use Rider instead of Visual Studio.
The only time I've been forced into a "culture of Windows and creaky Lenovos and Dells" recently was on a Java project. (Anecdotally, of course. Java has a similarly cross-platform culture as a whole.)
littlecranky67 15 hours ago [-]
Not sure when your last foray into the .NET ecosystem was, but every since it is xplat and unified (.NET 5 probably) it is a real joy. I use VSCode as IDE for C# on my mac, and deploy to Linux.
farlight 14 hours ago [-]
I've been using .NET almost exclusively on Linux since it was called .NET Core 2.0, and development platforms other than Windows do feel like second class citizens. Any time you venture into anything remotely advanced, the tooling is usually Windows only.
"Everything" expects you to use MSSQL, even if today there's ok official support for PostgreSQL and SQLite. Most "thought leaders" of various sorts are on Windows and expect you to use it. This pervades throughout the ecosystem.
Can't see this ever changing as it's not in MS' interest to turn other operating systems into good .NET development platforms.
qingcharles 13 hours ago [-]
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.
replwoacause 7 hours ago [-]
I do all my dev in .NET on a mac, using Postgres and Sqlite only, so I don't relate to your experience at all. It's dead simple for me and I'm not even that good of a developer.
osigurdson 8 hours ago [-]
I used .NET for many years with Postgres on a huge project. Honestly, I don't know what you mean. Can you break down "Everything" a little. What is it that expects MSSQL? Who are the thought leaders pushing it?
I'd say Microsoft's revenue related push with .NET these days is to try to subtly nudge you into Azure (where MSSQL is rare and Windows is virtually non-existent).
But, I also think they know they will kill .NET if they go overboard with it as the competition is strong.
aksss 14 hours ago [-]
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?
osigurdson 8 hours ago [-]
I think for most projects, add an ORM only after you start getting really annoyed and understand what you are trading.
moron4hire 11 hours ago [-]
Incidentally, I'm seriously considering dropping EF. The ability to apply migrations is nice. I find the means of authoring them to be arcane and capricious. Not having to write every simple query is nice, but it gets really hard to do complex or high performance stuff. After a decade of using this thing, I find myself fighting the Entity tracker more and more and now I'm seriously questioning if it's really all worth it.
intrasight 10 hours ago [-]
I use EF now - but only for the string interpolation in Database.SqlQuery and Database.ExecuteSql. We don't use POCOs but instead use XML and JSON with Linq.
moron4hire 10 hours ago [-]
It's really the navigations that make EF a problem. I've built a typed object graph database on top of Sqlite that works really well specifically because it's in Sqlite, so the overhead of the 1+N query problem with recursively descending navigations isn't a big problem. But it requires lazy loading and that requires all the navigation to happen inside a single service scope and that makes sequencing some things get difficult (can't just pass the results around willy nilly).
The navigation system in EF is where all of the pain points originate. All of my troubles with getting the migration generator to work are because I'm trying to express rather complex relationships. For example, to store a record representing a property on an object, I need to have two foreign keys from the Properties table to the Types table: one for the type of the property and one for the type in which the property lives. Types themselves have many relationships to other types: their base type, interface types they implement, generic type parameters, constraints on generic type parameters (actually, haven't even implemented that one as is too much).
I'm generally happy with the performance and expressivity of the system I've developed so far, but damn, it came with a lot of pain.
atraac 15 hours ago [-]
He didn't say you can't use Linux or MacOS, he said there's still a culture of being Windows and Microsoft only across .NET shops. As an ex .NET dev I can confirm, the community is quite close minded, language is awesome.
IneffablePigeon 14 hours ago [-]
I think it's changing a lot recently. Our eng team of ~150 has been fully macos for several years now and we've deployed to Linux for ten.
mpawelski 7 hours ago [-]
do you mind sharing the company name?
DANmode 14 hours ago [-]
This.
The community is being diluted by…a different demographic!
intrasight 10 hours ago [-]
Including the internal Microsoft community
smt88 10 hours ago [-]
Why do I care if other shops are Windows-only? The language and ecosystem are phenomenal and Linux support is first-class.
masfoobar 12 hours ago [-]
> As an ex .NET dev
Just curious.. what language(s) are you using now?
atraac 4 hours ago [-]
I landed in a web3 Node, Typescript startup so... Not great. But it allowed me to see an entirely different world so I can't complain.
osigurdson 8 hours ago [-]
Note that Linux often runs on Lenovos and Dells, some of which may be creaky. I guess you are saying you prefer macOS.
replwoacause 7 hours ago [-]
I do .NET dev exclusively on a mac completely within Visual Studio Code and it's by far the easiest and most enjoyable framework and ecosystem I've had the pleasure of working in. I couldn't be happier with it.
osigurdson 8 hours ago [-]
Obviously, don't use it if you don't want to and don't have to. It is not worse than Go or Java however which is its only meaningful competition.
GiorgioG 18 hours ago [-]
[flagged]
tomhow 16 hours ago [-]
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
GiorgioG 11 hours ago [-]
[dead]
animal531 7 hours ago [-]
Now if only they could spend time making Visual Studio 2026 perform up to par.
Just today I created e.g. 100 changes in a file, performed an undo and it rolled back 90 or so of the changes while somehow managing to keep the 5 at the start and the 5 at the end.
testerius 8 hours ago [-]
I remember .NET fails when there were dramas about not open sourced debugger, planning to remove hot reload (make it only available in Visual Studio because of licensing) or poor support in Visual Studio Code compared to other languages. AFAIK many people were angry that VS Code is not first class editor for C#/.NET. I am not sure how it is these days.
https://isdotnetopen.com/ has a good list of "dramas" questioning if .NET is truly open. At least there are not many new dramas from Microsoft...
For me it's not that big of a deal that some parts are not open. At least we have good competition (Microsoft (Visual Studio, VsCode c# Dev Kit) vs Jetbrais (Rider, VsCode + recent "Resharper for VsCode" extension.) that prevents one party to mess up something big.
ozim 7 hours ago [-]
Debugger was there, hot reloading was the issue.
Still I take debugger in Visual studio or Rider any day instead of VSCode debugger.
wiseowise 7 hours ago [-]
> Debugger was there, hot reloading was the issue.
Was it? There was only Samsung debugger.
mpawelski 7 hours ago [-]
it wasn't. Jetbrains can't legally use .NET's debugger, only Visual Studio and Vs Code can.
AlexErrant 22 hours ago [-]
Dumb Q: should a non-systems-language dev know/read assembly?
; Arm64
--- .NET 10
+++ .NET 11
@@ -13,8 +13,6 @@
ble G_M000_IG04
G_M000_IG03:
- cmp w1, w2
- bhs G_M000_IG05
str wzr, [x0, w1, UXTW #2]
G_M000_IG04:
@@ -25,4 +23,4 @@
bl CORINFO_HELP_RNGCHKFAIL
brk #0
-; Total bytes of code 68
+; Total bytes of code 60
I know C#/F# decently well, but is there any reason to actually pull out the ol textbooks and learn wtf the above is saying?
louthy 22 hours ago [-]
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
masfuerte 11 hours ago [-]
> anything beginning with ‘B’ will be branch
Usually. BRK is a breakpoint.
louthy 10 hours ago [-]
True, there are of course exceptions! :D
(Also, other architectures might use J for 'Jump' rather than 'Branch'). I don't make the rules ;)
apple1417 17 hours ago [-]
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.
drdexebtjl 17 hours ago [-]
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.
jlarocco 20 hours ago [-]
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 :-)
bjoli 13 hours ago [-]
What I wish more languages did was what the guile optimizer does. There is a source->source optimizer which does inlining, DCE, CSE and partial evaluation.
That is very handy, especially when writing macros. I only have to look at assembly when I want to know about optimizations that are not visible in the source->source optimizer.
If I ever want to know if something is reified (which I never do) I can always look at the ASM.
keithnz 21 hours ago [-]
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.
Starlevel004 19 hours ago [-]
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.
19 hours ago [-]
flowerlad 22 hours ago [-]
No. If you're a low-level C language programmer then it is useful.
Sorrel47 22 hours ago [-]
Always appreciate the continued perf gains. Our existing services just get faster for free, which is a nice win.
pseudosavant 21 hours ago [-]
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.
momocowcow 13 hours ago [-]
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
}
program_whiz 10 hours ago [-]
actually this is likely just as performant as the "Ugly but fast" code from the famous talk. After all, this is just branching on GetType() == typeof(Dog) which is presumably boiling down to an integer comparison. This roughly the same as the following C code:
void speak_generic(void* animal, int type_id) {
if (type_id == DOG) {
dog_speak((Dog*)animal);
} else {
dispatch_speak_vtable(animal);
}
}
Advantage 1:
You don't have to maintain this logic (its automatic), so you won't get weird cases if you forget to update all your switches everywhere, and/or you get weird fallthrough logic and footgun yourself in C.
Advantage 2:
You still get the flexibility of the vtable if you need it (for the case the type is chosen at runtime at not known). But for 90% of cases, its just as fast as the ugly C code.
Disadvantage 1: Losing a smug sense of superiority because you eschew abstractions and prefer writing verbose error-prone switch statements over clean easy to understand code.
Disadvantage 2: Writing performant code can no longer be gate kept behind archaic practices, now everyone can just use `var animal = new Dog()` and be done with it.
kg 9 hours ago [-]
You can always just not use OOP. C#'s tooling for functional programming and C-style programming is really good, thanks to stuff like statics on interfaces or spans.
d_finch 21 hours ago [-]
Saw a noticeable startup time boost on a recent project migration. Always appreciate the continued focus on speed.
ochronus 9 hours ago [-]
As much as Micro$oft is ... subpar, .NET never fails to amaze in the last couple of years. Kudos to the team.
pjmlp 2 days ago [-]
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.
mlhpdx 22 hours ago [-]
Impressive technical work and authorship. My quibble, which seems significant in context, is what happened with AoT?
CurtHagenlocher 22 hours ago [-]
AoT is still a thing. Presumably a lot of the JIT improvements would also improve the generation of AoT-compiled code.
mlhpdx 22 hours ago [-]
I hope that’s the case but I’d feel a lot better to see it in print.
rsalus 20 hours ago [-]
do you mean NativeAoT? it's mentioned a few times in the post
qingcharles 13 hours ago [-]
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)
kg 9 hours ago [-]
AoT uses the same codegen (mostly) as the JIT so if you see a JIT improvement it's possible NativeAOT/ilc picked up that improvement too.
Unless it's a runtime-only optimization, like guarded devirtualization... there's no straightforward way for an AOT compiler to do that without profiling data.
gerdesj 23 hours ago [-]
Spinal Tap's "put it up to 11". My laptop (Kubuntu) has volume controls that allow me to override 100% and take it to 150%.
I can wind it up to 15! \||/ (is there an official ASCII art four finger devil's horns)
richiebful1 19 hours ago [-]
I noticed that audio quality begins degrading above 100% (at least if the media is already at high volume), so it really is a useful concept. I'm unsure what Linux distro I'm recalling this from, but it was useful on my little old netbook from college
qingcharles 13 hours ago [-]
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%.
parineum 22 hours ago [-]
\m/
gerdesj 22 hours ago [-]
I stared at my keyboard for bloody ages and came up with || instead of m.
nob end!
5 hours ago [-]
equasar 2 days ago [-]
Thanks Stephen for this, it is very rewarding to read something very technical that is not AI slop these days.
bjoli 15 hours ago [-]
I hope there will be some kind of runtime async support for the current or a new asyncmethodbuilder. That is amazing work.
I'm not sure if this will surface as an "enabled by default" feature in .NET 11 - indeed there may not be a final decision on that yet. But it is an active area of work that will arrive sooner or later.
afdbcreid 7 hours ago [-]
`AsyncMethodBuilder` is a way to declare async methods that return your own task types. AFAIK it is not supported with the current runtime async, and maybe never will be - it's quite hard to support, I believe.
jcon321 9 hours ago [-]
dotnet has been a pleasure to work with the last few years
23 hours ago [-]
dude250711 22 hours ago [-]
C#/.NET are very well-represented in LLM data - from enterprise back-end code to games. A language to use for sure.
CharlieDigital 22 hours ago [-]
Flip side: LLMs have to be very explicitly told to code in "modern" .NET and C# due to lack of representation in the training set.
Case in point: extension members from C# 14 is one that LLMs commonly stumble on and requires an explicit example. It still sometimes says that this is not valid syntax.
extension(SomeType instance)
{
public OtherType DoSomething() { ... }
}
Agents really struggle on this one for some reason.
Even older releases have a few that I notice LLMs making mistakes on like use of `System.Threading.Lock` over `Object` when locking.
pjmlp 7 hours ago [-]
For me it hardly matters, given that so many enterprise .NET projects are still stuck in Framework, including some from Microsoft themselves.
oldmanhorton 14 hours ago [-]
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.
mexicocitinluez 9 hours ago [-]
I wonder if any of those work alongside Github Copilot (the autocomplete not actual agent).
Because at this point I would do anything if I could get Github Copilot to understand the new language features and stop trying to constantly revert code.
The one specific thing I'm constantly having to deny is Copilot seeing this:
List<string> items = [];
into this:
List<string> items = new List<string>();
qingcharles 13 hours ago [-]
[flagged]
merb 21 hours ago [-]
With Claude I never had that problem. However Claude does not use the pattern by default
sander1095 4 hours ago [-]
I am not noticing this. Does this by default for me
bob1029 21 hours ago [-]
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.
One of the best perf tests for C# it's to run the Switch emulator against some legal Switch demo game dump.
kristianp 23 hours ago [-]
[flagged]
pestkranker 23 hours ago [-]
These comments about potential LLM usage are so boring. Stephen is doing this kind of blog post since 6+ years. They all look the same. Read it! It’s very good. Performance deep dives with this kind of quality are rare.
kristianp 21 hours ago [-]
Ok, fair enough. I may have over compensated for this one. I found the Spinal Tap, "this one goes to 11 stuff" so irritating that I might have not thought it through. It's such a tired joke by now. I did enjoy his Frozen reference last year.
nitinreddy88 20 hours ago [-]
This comment is written by AI. "Fair enough" "over compensation" in one line. We should ban such accounts
22 hours ago [-]
gerdesj 23 hours ago [-]
Not too sure here. I use quite a few commas, too.
I suspect it was done old school: Written by Stephen and passed to a LLM to fill in all those links and other garnish and then passed back for final polish by Stephen. That's how I do my write ups (but generally without the LLM bit for shorter efforts).
This is a long write up, and I'm sure it will have been assisted, but in the right way, and not a sloppy way.
I've dropped several commas before conjunctions, soz!
AlexErrant 22 hours ago [-]
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.
cindyllm 21 hours ago [-]
[dead]
tester756 22 hours ago [-]
For some people LLM-spotting feels like a sport they need to compete in
wolttam 22 hours ago [-]
This is the loudest release of .NET to date(!)
y1n0 22 hours ago [-]
It’s a spinal tap joke.
mexicocitinluez 9 hours ago [-]
You've never heard/read someone using the same word twice in the same sentence before?
sltr 21 hours ago [-]
Backing you up on this. I smelled LLM and hit cmd+w.
I’m afraid posts like this might become fleeting.
the technical parts are fresh as ever but the writing style is awful, man
I loathe LLM prose, no matter who posts it. It earns a quick cmd+w.
My prizes for spending the internet points to say this are the joy of resisting normalization of illiteracy and a tacit camaraderie with the hundreds of others who agree but won't comment or upvote.
https://github.blog/ai-and-ml/generative-ai/migrating-the-gi...
The only time I've been forced into a "culture of Windows and creaky Lenovos and Dells" recently was on a Java project. (Anecdotally, of course. Java has a similarly cross-platform culture as a whole.)
"Everything" expects you to use MSSQL, even if today there's ok official support for PostgreSQL and SQLite. Most "thought leaders" of various sorts are on Windows and expect you to use it. This pervades throughout the ecosystem.
Can't see this ever changing as it's not in MS' interest to turn other operating systems into good .NET development platforms.
These days I just use EF with Sqlite on 99% of my projects.
I'd say Microsoft's revenue related push with .NET these days is to try to subtly nudge you into Azure (where MSSQL is rare and Windows is virtually non-existent). But, I also think they know they will kill .NET if they go overboard with it as the competition is strong.
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?
The navigation system in EF is where all of the pain points originate. All of my troubles with getting the migration generator to work are because I'm trying to express rather complex relationships. For example, to store a record representing a property on an object, I need to have two foreign keys from the Properties table to the Types table: one for the type of the property and one for the type in which the property lives. Types themselves have many relationships to other types: their base type, interface types they implement, generic type parameters, constraints on generic type parameters (actually, haven't even implemented that one as is too much).
I'm generally happy with the performance and expressivity of the system I've developed so far, but damn, it came with a lot of pain.
The community is being diluted by…a different demographic!
Just curious.. what language(s) are you using now?
Just today I created e.g. 100 changes in a file, performed an undo and it rolled back 90 or so of the changes while somehow managing to keep the 5 at the start and the 5 at the end.
https://isdotnetopen.com/ has a good list of "dramas" questioning if .NET is truly open. At least there are not many new dramas from Microsoft...
For me it's not that big of a deal that some parts are not open. At least we have good competition (Microsoft (Visual Studio, VsCode c# Dev Kit) vs Jetbrais (Rider, VsCode + recent "Resharper for VsCode" extension.) that prevents one party to mess up something big.
Still I take debugger in Visual studio or Rider any day instead of VSCode debugger.
Was it? There was only Samsung debugger.
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
Usually. BRK is a breakpoint.
(Also, other architectures might use J for 'Jump' rather than 'Branch'). I don't make the rules ;)
You should learn assembly anyway, but it won't make this part any more insightful.
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 :-)
That is very handy, especially when writing macros. I only have to look at assembly when I want to know about optimizations that are not visible in the source->source optimizer.
If I ever want to know if something is reified (which I never do) I can always look at the ASM.
Advantage 2: You still get the flexibility of the vtable if you need it (for the case the type is chosen at runtime at not known). But for 90% of cases, its just as fast as the ugly C code.
Disadvantage 1: Losing a smug sense of superiority because you eschew abstractions and prefer writing verbose error-prone switch statements over clean easy to understand code.
Disadvantage 2: Writing performant code can no longer be gate kept behind archaic practices, now everyone can just use `var animal = new Dog()` and be done with it.
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.
Unless it's a runtime-only optimization, like guarded devirtualization... there's no straightforward way for an AOT compiler to do that without profiling data.
I can wind it up to 15! \||/ (is there an official ASCII art four finger devil's horns)
nob end!
Here is the "Runtime async" section: https://devblogs.microsoft.com/dotnet/performance-improvemen...
I'm not sure if this will surface as an "enabled by default" feature in .NET 11 - indeed there may not be a final decision on that yet. But it is an active area of work that will arrive sooner or later.
Case in point: extension members from C# 14 is one that LLMs commonly stumble on and requires an explicit example. It still sometimes says that this is not valid syntax.
Agents really struggle on this one for some reason.Even older releases have a few that I notice LLMs making mistakes on like use of `System.Threading.Lock` over `Object` when locking.
Because at this point I would do anything if I could get Github Copilot to understand the new language features and stop trying to constantly revert code.
The one specific thing I'm constantly having to deny is Copilot seeing this:
into this: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.
I'd be interested in hearing more.
I suspect it was done old school: Written by Stephen and passed to a LLM to fill in all those links and other garnish and then passed back for final polish by Stephen. That's how I do my write ups (but generally without the LLM bit for shorter efforts).
This is a long write up, and I'm sure it will have been assisted, but in the right way, and not a sloppy way.
I've dropped several commas before conjunctions, soz!
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.