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.
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.
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).
There are elements of truth in this, but it is not the whole story.
While Silverlight did produce the first portable version of .NET and produces a lot of the code that allowed .NET to be portable, this code has been now retrofitted into the main CoreCLR and the VM source code has been upgraded.
What you see in the public CoreCLR is now the state of the art and while I do not know how the exact mechanics work, my understanding is that the CoreCLR and the .NET Desktop VM that ships source codes are very close to each other - modulo branches, deliverables, freeze dates and other loose ends.
On the library front, there has been a lot of rewriting for the sake of portability, cleaning up the code, and making the code more maintainable, and bringing it to the 2017 standards of coding.
Extremely rare? You did check the links I posted, right? There are many comments, and that is just the outspoken minority. It's one of the most requested outstanding items in their entire repository.
And it's not a matter of priority or security, it's a matter of transparency. The community was promised a review, and stress test, and that someone from MS would be working on it full time. They followed up with more promises multiple times. And then silence. You're completely missing the point.
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.