
Do you worry that changes in .Net could leave people behind? - D_Guidi
https://odetocode.com/blogs/scott/archive/2019/06/24/questions-from-the-ndc-oslo-panel-discussion-on-the-future.aspx
======
UglyToad
Interested to hear of other people's experiences with async await either in C#
or other languages. It took a while to click for me in C# but now I understand
it, it seems intuitive and usable and I'd be interested to know if there are
superior alternatives.

The thing about ConfigureAwait, for those who aren't familiar with .NET is, as
far as I understand it, about the context on the thread prior to the async
call (this used to include things like the User in an HTTP context) being
restored on the thread which resumes after the call. In a sync block on async
calls this could cause deadlocking due to the waiting thread not being able to
get the context since it never got released. But as far as I'm aware in .NET
Core 2 this is no longer a problem for Web apps anyway.

I know there's been a lot of talk about Rust adopting a slightly different
approach and JavaScript seems to have gone through about 3 iterations so there
are definitely different models out there, I just find it hard to picture how
different models work so it would be good to know some guides or tutorials to
check out for other good systems.

------
qes
> I think EF needs to expand its reach far beyond relational databases.

I'm not sure I could disagree more. I don't think it's feasible to abstract
away the underlying realities of different data stores. That tends to end in a
mediocre API that handcuffs you from utilizing the advantages of choosing
varying data stores in the first place.

ORMs in general already suffer this criticism with relational data stores.
Trying to make an ORM cover documents and graphs and whatever else will be
worse.

I also thought the Microsoft and the .Net community were moving away from
stuffing everything and the kitchen sink in together.

