37 ms·

In isolation, yes, I agree with you. But in the context of the cornucopia of other "carefully evaluated" features mixed into the melting pot, C# is a nightmare

In isolation, yes, I agree with you. But in the context of the cornucopia of other "carefully evaluated" features mixed into the melting pot, C# is a nightmare of language identities - a jack of all trades, master of none, choose your dialect language. No thanks.

DeathArrow 5mo ago
>a jack of all trades Yes, C# is a jack of all trades and can be used at many things. Web, desktop mobile, microservices, CLI, embedded software, games. Probably is not fitted for writing operating systems kernels due to the GC but most areas can be tackled with C#.
- Izikiel43 5mo ago
  > Probably is not fitted for writing operating systems kernels Midori would like to have a word with you: https://en.wikipedia.org/wiki/Midori_(operating_system) https://en.wikipedia.org/wiki/Midori_(operating_system) https://joeduffyblog.com/2015/11/03/blogging-about-midori/ https://joeduffyblog.com/2015/11/03/blogging-about-midori/
- pjmlp 5mo ago
  Many systems programming languages with GC have existed since the 1970's, we don't seem most adoption mostly due to developer culture, and monetary issues with management.
LunicLynx 5mo ago
If it’s not for you I guess that is ok. But from your comment I would also deduct that you never professionally used it. After so many different languages it’s the only one I always comeback to. The only things that I wish for are: rusts borrow-checker and memory management. And the AOT story would be more natural. Besides that, for me, it is the general purpose language.
- owlstuffing 5mo ago
  General purpose != multiple dialects, that is the trouble with languages like this - C# is a tower of babel.
wvenable 5mo 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.
- CharlieDigital 5mo 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 5mo 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 5mo 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/ 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.
resonancel 5mo ago
C# is a perfect example of feature envy, but because "Java sucks" C# must be the best thing ever in the world of computing. Orthogonality and coherence be damned.

DeathArrow 5mo ago

>a jack of all trades Yes, C# is a jack of all trades and can be used at many things. Web, desktop mobile, microservices, CLI, embedded software, games. Probably is not fitted for writing operating systems kernels due to the GC but most areas can be tackled with C#.

Izikiel43 5mo ago
> Probably is not fitted for writing operating systems kernels Midori would like to have a word with you: https://en.wikipedia.org/wiki/Midori_(operating_system) https://en.wikipedia.org/wiki/Midori_(operating_system) https://joeduffyblog.com/2015/11/03/blogging-about-midori/ https://joeduffyblog.com/2015/11/03/blogging-about-midori/
pjmlp 5mo ago
Many systems programming languages with GC have existed since the 1970's, we don't seem most adoption mostly due to developer culture, and monetary issues with management.

LunicLynx 5mo ago

If it’s not for you I guess that is ok. But from your comment I would also deduct that you never professionally used it. After so many different languages it’s the only one I always comeback to. The only things that I wish for are: rusts borrow-checker and memory management. And the AOT story would be more natural. Besides that, for me, it is the general purpose language.

owlstuffing 5mo ago
General purpose != multiple dialects, that is the trouble with languages like this - C# is a tower of babel.

wvenable 5mo 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.

CharlieDigital 5mo 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 5mo 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 5mo 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/ 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.

resonancel 5mo ago

C# is a perfect example of feature envy, but because "Java sucks" C# must be the best thing ever in the world of computing. Orthogonality and coherence be damned.