https://github.com/davidfowl/AspNetCoreDiagnosticScenarios/b...
https://twitter.com/davidfowl/status/1532880744732758018?lan...
https://github.com/davidwrighton/runtimelab/blob/report/docs...
The green threads research (which are those github issues I already linked to) concluded that it's not worth adding it to NET, because basically now it is too late to retrofit them into .NET, without having the issue of yet another way to color code, for little gain overall.
I also suggest watching the BUILD 2023 ASP.NET panel on the matter.
Not my conclusion at all. I am saying that tooling and base libraries have matured enough to prevent those issues from happening.
> because basically now it is too late to retrofit them into .NET
Nope, read the conclusion. There are other factors not just backwards compatibility (which isn't even a blocker).
Big if, not everyone is using .NET latest on VS, with latest version of every library using async/await.
> Nope, read the conclusion. There are other factors not just backwards compatibility.
Again, I wrote the Github issues regarding green threads on my comment, so I don't know, maybe I actually already read them?
The analyzers are part of the build, they work everywhere (command line, VS code). Either way, I am glad we finally agree that async await "works fine" for modern .NET.
> so I don't know, maybe I actually already read them?
I did, I even responded to your links with the official conclusion from the NET team on those issues. Now maybe your turn to read?
Fixing this would either be a serious break in the ecosystem, or you'd have a new capacity with way too many asterisks to be useful.
The .NET world already spent the budget for big migrations with .NET Framework -> Core (just like Java did with Java 8->9, or Python with 2->3) - as much as we might like green threads, they aren't useful enough (compared to async/await) to justify another break.