@bitbonk@JamieMagee the end reasoning is odd considering .NET has been introducing new programming models over the last decade to varying degrees of success.
@ICooper@bitbonk@JamieMagee .NET over the last five years has been so hyper focused on perf, I wouldn't think "it's gonna be confusing" would stop them. 😅
@khalidabuhakmeh@bitbonk@JamieMagee does it? Serious response: IMO nothing you listed except async/await causes pain for adoption like green threads, as implemented but the experiment, does. Maybe generics if you use a library that has generic APIs that can't work by inference, and the .NET Core migration, but only if you're migrating to 1 or 2. Yes .NET has tried lots of things, but we're also pretty good at backwards compatibility.
eg If you adopt a library that has some helpful code someone wrote for their minimal API web app, you probably can just use it from your MVC app. Is the same true if you adopt a library that uses green threads but you haven't?
@davidwengier@bitbonk@JamieMagee I guess it depends on your perspective and current situation.
.NET Core 1 and 2 were definitely not good about backwards compatibility. We can agree on that. 😅
Some decisions can only be judged as good/bad in retrospect.
The "other person's" library is not a strong one IMHO, since our OSS offerings are few and far between these days. Still good ones, but I bet I could count the modern community mission critical packages on my fingers and toes.
@khalidabuhakmeh@bitbonk@JamieMagee BCL included. Yes we introduce new UI paradigms (whole other thread!) but your old winforms apps still compile and run (and look better than your old wpf apps, but whole other thread!). Yes we add new collection types, even Span and ReadOnlySpan but you probably don't need to care until you want to do something new.
With green threads unless the team commit were to always have sync and async versions of any green threads method, it would be way more disruptive than anything we've seen in years.
@khalidabuhakmeh@davidwengier@JamieMagee I am honestly thankful that all this churn and proliferation in the .NET ecosystem (e.g. all these different rather incompatible .NET flavors, PCL, netstandard, NewtonSoft.Json diamond dependency, strongly named assemblies, and even sync vs. async APIs) has quieted down and everything feels more stabilized and „solved“ now.
I am not sure I could take yet another big overhaul of a significant part of .NET base so soon.
@bitbonk@JamieMagee
Absolutely. I'm currently faced with designing implementations of an interface where some vendors ONLY provide a sync method, and others ONLY provide an async method. The whole "deals with async under the hood" sounded awesome to me!
Add comment