I can see where he's coming from. For example, `dynamic` was initially introduced to support COM interop when Office add-in functionality was introduced. Should I use it in my web API? I can, but I probably shouldn't.

`.ConfigureAwait(bool)` is another where it is relevant, but only in some contexts.

This is precisely because the language itself operates in many runtime scenarios.

I guess that's a good point. I admit haven't used or seen `dynamic` in so long that I completely forgot about it.

But I'm not sure that's really a problem. Does the OP expect everyone to use an entirely different languages every single context? I have web applications and desktop applications that interact with Office that share common code.

Even `dynamic` is pretty nice as far as weird dynamic language features are concerned.

Interestingly enough `.ConfigureAwait(bool)` is entirely the opposite of `dynamic` -- it's not a language feature at all but instead a library call. I could argue that might instead be better as a keyword.

It is a library call, but one that is tied to the behavior of a language feature (async/await).

The reason I bring it up is that it is another one of those things where it matters in some cases depending on what you're doing.

Look at the depths that Toub had to go through to explain when to use it: https://devblogs.microsoft.com/dotnet/configureawait-faq/

David Fowl concludes in the comments:

    > That’s correct, most of ASP.NET Core doesn’t use ConfigureAwait(false) and that was an explicit decision because it was deemed unnecessary. There are places where it is used though, like calls to bootstrap ASP.NET Core (using the host) so that scenarios you mention work. If you were to host ASP.NET Core in a WinForms or WPF application, you would end up calling StartAsync from the UI thread and that would do the right thing and use ConfigureAwait(false) internally. Request processing on the other hand is dispatching to the thread pool so unless some other component explicitly set a SynchronizationContext, requests are running on thread pool threads.
    > 
    > Blazor on the other hand does have a SynchronizationContext when running inside of a Blazor component.

So I bring this up as a case of how supporting multiple platforms and runtime scenarios does indeed add some layer of complexity.

> It is a library call, but one that is tied to the behavior of a language feature (async/await).

This is a good example of C# light-touch on language design. Async/await creates a state machine out of your methods but that's all it does. The language itself delegates entirely to platform/framework for the implementation. You can swap in your own implementation (just as it possible with this union feature)

> So I bring this up as a case of how supporting multiple platforms and runtime scenarios does indeed add some layer of complexity.

I agree that's true. A language that doesn't support multiple platforms and runtime scenarios can, indeed, be simpler. However that doesn't make the task simpler -- now you just have to use different languages entirely with potentially different semantics. If your task is just one platform and one runtime scenario, the mental cost here is still low. You don't actually need to know those other details.

> This is a good example of C# light-touch on language design.

Is it? F# code doesn't even need ConfigureAwait(false), one simply uses backgroundTask{} instead of task{} to ignore SynchronizationContext.Current, and this didn't require any language design changes at all (both are computation expressions), but it would for C# precisely because it delegates this choice to the framework.

dynamic was also added as part of DLR, initially designed for IronPython and IronRuby support.

This inspired the invokedynamic bytecode in the JVM, which has brought many benefits and much more use than the original .NET features, e.g. how lambdas get generated.