← Back to context

Comment by wvenable

6 hours ago

> C# is a nightmare of language identities - a jack of all trades, master of none, choose your dialect language.

I honestly have no idea where you would get this idea from. C# is a pretty opinionated language and it's worst faults all come from version 1.0 where it was mostly a clone of Java. They've been very carefully undoing that for years now.

It's a far more comfortable and strict language now than before.

4 comments

wvenable

Reply
CharlieDigital  5 hours ago

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.

  • wvenable  4 hours ago

    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.

    • CharlieDigital  4 hours ago

      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.

      1 reply →