4 ms·

>Most enterprises still don't care for .NET Core due to lack of support for WCF, EF6 (including VS UI tooling) Yes, also the UI technologies of WPF and Winform

by jasode 7y ago

>Most enterprises still don't care for .NET Core due to lack of support for WCF, EF6 (including VS UI tooling) Yes, also the UI technologies of WPF and Winforms are not getting ported to Linux: https://github.com/dotnet/wpf/issues/607#issuecomment-487360902 https://github.com/dotnet/wpf/issues/607#issuecomment-487360... It seems like the people embracing .NET Core are using it for writing backend services (scenarios where it competes with Golang usage).

cm2187 7y ago
Well the rest won’t have a choice. .Net full will become stale and legacy. I doubt enterprises will write new stuff on .Net full.
- Crinus 7y ago
  For most enterprises stale=stable and stable=good, so i'm certain as long as it works, they'll keep using it. Also see the topic of this submission (yes, some still use VB6).
  - cm2187 7y ago
    Run existing code I am sure. But write new code for it I don't think so. Not the least because even in large organisations, devs like to use the latest and greatest.
- jasode 7y ago
  > .Net full will become stale and legacy. I doubt enterprises will write new stuff on .Net full. Sorry for the misunderstanding. I agree that Windows programmers will eventually migrate to .NET Core v5+. My comment was meant to be limited to the Linux scenario. I should have written "Linux" again in the 2nd sentence so that was more obvious: - "It seems like the people embracing .NET Core on Linux are using it for writing backend services (scenarios where it competes with Golang usage)." Microsoft has no plans to include the desktop UI technology of WPF & Winforms on Linux... even in the future unified .NET Core 5+ that deprecates classic .NET Full. Because the Linux side doesn't include all the Windows tech, it doesn't quite have the same 1st class status as Windows. But that limitation does not prevent C# programmers that want to use Linux from using it to write server-side network services (because no GUI required) where others might use Golang.
pjmlp 7y ago
Given Go's features I doubt many .NET devs would feel like using it, instead of dropping into alternative languages with C#, VB.NET, F#, C++/CLI feature level. Where I am, when .NET is not possible, the alternatives are either the JVM languages or C++, no one ever thinks of Go.

by jasode 7y ago

cm2187 7y ago

Well the rest won’t have a choice. .Net full will become stale and legacy. I doubt enterprises will write new stuff on .Net full.

Crinus 7y ago
For most enterprises stale=stable and stable=good, so i'm certain as long as it works, they'll keep using it. Also see the topic of this submission (yes, some still use VB6).
- cm2187 7y ago
  Run existing code I am sure. But write new code for it I don't think so. Not the least because even in large organisations, devs like to use the latest and greatest.
jasode 7y ago
> .Net full will become stale and legacy. I doubt enterprises will write new stuff on .Net full. Sorry for the misunderstanding. I agree that Windows programmers will eventually migrate to .NET Core v5+. My comment was meant to be limited to the Linux scenario. I should have written "Linux" again in the 2nd sentence so that was more obvious: - "It seems like the people embracing .NET Core on Linux are using it for writing backend services (scenarios where it competes with Golang usage)." Microsoft has no plans to include the desktop UI technology of WPF & Winforms on Linux... even in the future unified .NET Core 5+ that deprecates classic .NET Full. Because the Linux side doesn't include all the Windows tech, it doesn't quite have the same 1st class status as Windows. But that limitation does not prevent C# programmers that want to use Linux from using it to write server-side network services (because no GUI required) where others might use Golang.

pjmlp 7y ago

Given Go's features I doubt many .NET devs would feel like using it, instead of dropping into alternative languages with C#, VB.NET, F#, C++/CLI feature level. Where I am, when .NET is not possible, the alternatives are either the JVM languages or C++, no one ever thinks of Go.