6 ms·

I think you're right to call out that it's not competing in every way, but there are some cases in which it is competing directly—and it's in those cases where

I think you're right to call out that it's not competing in every way, but there are some cases in which it is competing directly—and it's in those cases where it can be a frustrating developer experience.

Nuzzerino 9y ago
I've been a (mostly) C# developer for 10 years, and am terribly disappointed with the way .NET Core is being managed. Something is definitely wrong when promises are made to assign a developer to the issue, full-time, and then no communication happens after that, for months. All they needed to do is test and merge the hard work done by a volunteer! These problems are eclipsed by the the marginal success of the 95-99% of use cases that are covered by .NET Core. One of the lesser-known areas that C# and .NET has shined, involves plugin and modular development. AppDomains and secure code regions are a feature of the runtime. For more esoteric use cases, the classic .NET runtime itself is customizable, with replaceable COM interfaces using the C++ hosting API. This is how SQL Server implemented stored procedures that could be written with C#. The way .NET Core has treated the issue is tantamount to a betrayal of trust. I understand that they are trying to take things in a different direction, but doing so undermines the other features that .NET provides, and does so well with. Not to mention they did promise to work on, and merge the feature, before leaving people hanging with no further updates in communication. A cross-platform .NET Core that doesn't have this kind of feature is not going to do much that Python or Java cannot do. We should be far more worried about .NET Core competing with .NET Framework, than .NET Core competing with Mono. Is Microsoft trying to provide a good tool, to empower developers to build things that could not be easily built before? Or is the primary goal to be seen as friendly to the Open Source Community, by providing yet another dumbed down, cookie cutter cross-platform SDK that deserves no relevance? Are they intentionally omitting or delaying features that one would use in more advanced scenarios, forcing developers to make a choice to use classic .NET Framework (Windows/Mono)? It is starting to seem like the same old tricks by Microsoft, just more cleverly hidden.
- pjmlp 9y ago
  I enjoy .NET a lot, but as polyglot consultant we currently are only focused on .NET for straight Windows development. For us to consider to use .NET Core instead of Java or C++ for UNIX-like OSes, it still needs to catch up a bit with its bigger brother.
- AdeptusAquinas 9y ago
  I think it's pretty weak to assume that because MS isn't supporting your extremely rare and complicated scenario they are obviously malicious. .NET Core has been a huge rewrite of the old framework, focusing on common scenarios which are easily cross-platform first, then the harder ones later. E.g. System.Drawing, which they eventually included (in 2.0 in believe) via incorporating several implementations for each target architecture, including one from Mono. They'll probably get to AppDomains eventually, assuming it isnt outright impossible on linux/osx or introduces a massive security hole. But not doing it right now cause you want it isnt evil: which is more important? Full support for System.Crytography, or say Oracle Ado.NET, or runtime loading/unloading of dlls? Hint, the answer isnt dll unloading.
  - oaiey 9y ago
    I would be careful with the term "rewritten". CoreCLR is really old (Silverlight), before it was bound to UWP(x86/arm) and before it was cross platform ported to other operating systems. There was heavy code stealing from the .NET Framework, but the split is already long time ago (like 2005).
    - AdeptusAquinas 9y ago
      Perhaps remixed, trimmed and partially augmented are better terms
      - oaiey 9y ago
        Yeah. I just commented it to avoid confusion. .NET history is more complicated but also more rational than often seen

Nuzzerino 9y ago

I've been a (mostly) C# developer for 10 years, and am terribly disappointed with the way .NET Core is being managed. Something is definitely wrong when promises are made to assign a developer to the issue, full-time, and then no communication happens after that, for months. All they needed to do is test and merge the hard work done by a volunteer! These problems are eclipsed by the the marginal success of the 95-99% of use cases that are covered by .NET Core. One of the lesser-known areas that C# and .NET has shined, involves plugin and modular development. AppDomains and secure code regions are a feature of the runtime. For more esoteric use cases, the classic .NET runtime itself is customizable, with replaceable COM interfaces using the C++ hosting API. This is how SQL Server implemented stored procedures that could be written with C#. The way .NET Core has treated the issue is tantamount to a betrayal of trust. I understand that they are trying to take things in a different direction, but doing so undermines the other features that .NET provides, and does so well with. Not to mention they did promise to work on, and merge the feature, before leaving people hanging with no further updates in communication. A cross-platform .NET Core that doesn't have this kind of feature is not going to do much that Python or Java cannot do. We should be far more worried about .NET Core competing with .NET Framework, than .NET Core competing with Mono. Is Microsoft trying to provide a good tool, to empower developers to build things that could not be easily built before? Or is the primary goal to be seen as friendly to the Open Source Community, by providing yet another dumbed down, cookie cutter cross-platform SDK that deserves no relevance? Are they intentionally omitting or delaying features that one would use in more advanced scenarios, forcing developers to make a choice to use classic .NET Framework (Windows/Mono)? It is starting to seem like the same old tricks by Microsoft, just more cleverly hidden.

pjmlp 9y ago
I enjoy .NET a lot, but as polyglot consultant we currently are only focused on .NET for straight Windows development. For us to consider to use .NET Core instead of Java or C++ for UNIX-like OSes, it still needs to catch up a bit with its bigger brother.
AdeptusAquinas 9y ago
I think it's pretty weak to assume that because MS isn't supporting your extremely rare and complicated scenario they are obviously malicious. .NET Core has been a huge rewrite of the old framework, focusing on common scenarios which are easily cross-platform first, then the harder ones later. E.g. System.Drawing, which they eventually included (in 2.0 in believe) via incorporating several implementations for each target architecture, including one from Mono. They'll probably get to AppDomains eventually, assuming it isnt outright impossible on linux/osx or introduces a massive security hole. But not doing it right now cause you want it isnt evil: which is more important? Full support for System.Crytography, or say Oracle Ado.NET, or runtime loading/unloading of dlls? Hint, the answer isnt dll unloading.
- oaiey 9y ago
  I would be careful with the term "rewritten". CoreCLR is really old (Silverlight), before it was bound to UWP(x86/arm) and before it was cross platform ported to other operating systems. There was heavy code stealing from the .NET Framework, but the split is already long time ago (like 2005).
  - AdeptusAquinas 9y ago
    Perhaps remixed, trimmed and partially augmented are better terms
    - oaiey 9y ago
      Yeah. I just commented it to avoid confusion. .NET history is more complicated but also more rational than often seen