Do you worry that changes in .Net could leave people behind?

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.

> 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.