.NET Core is slowly reimplementing/integrating all truly cross platform .NET classic APIs (https://github.com/dotnet/core/blob/master/roadmap.md). My guess is that at this point they didn't have the bandwidth to include what you're talking about in the first version but they will include it later on.
Long term Mono is probably just going to become a sort of .NET "distribution" on top of .NET Core, it will include things which Microsoft deprecated such as Winform. And it will probably be not maintained at the same level .NET Core itself is. I don't think there will be any reason to use Mono in the future, except for legacy Mono apps...
In the last presentation that I saw, the line was that Mono would continue to exist as a full .NET implementation to support Xamarin mobile apps. The reason given was that .NET Core was scoped as a run-time for server applications, so no work had been done on making it run on mobile devices, whilst Mono has been used in production on those platforms for some time.
That seems valid now. But developing two runtimes in parallel doesn't seem that great of an investment. Plus there are already dotnet core contributions regarding portability, for example from Samsung, it seems reasonable to think that 2-3-5 years from now dotnet core will power Mono as well.
You could be right, the current situation is unsettled, so I'm personally reluctant to predict anything much. The argument for Mono seems to boil down to the MS teams not having enough capacity to get .NET Core production-ready for mobile whilst doing everything else.
I'm going to be learning ASP.NET Core, but not even think about possible production use until after the next release. We will probably continue to avoid .NET for mobile, and I would not consider Mono for any other use case.
Well, .NET Core is probably still 1-1.5 years away from being fully production "friendly". Common Open Source .NET libraries have to be ported, .NET Core itself needs to reach base class library parity at least as far as its scope is concerned (including things such as System.Drawing based on Skia# or similar), the tooling around it needs to mature.
Anything outside of ASP.NET Core or small command-line tools is probably premature in 2016.
Comments
.NET Core is slowly reimplementing/integrating all truly cross platform .NET classic APIs (https://github.com/dotnet/core/blob/master/roadmap.md). My guess is that at this point they didn't have the bandwidth to include what you're talking about in the first version but they will include it later on.
Long term Mono is probably just going to become a sort of .NET "distribution" on top of .NET Core, it will include things which Microsoft deprecated such as Winform. And it will probably be not maintained at the same level .NET Core itself is. I don't think there will be any reason to use Mono in the future, except for legacy Mono apps...
In the last presentation that I saw, the line was that Mono would continue to exist as a full .NET implementation to support Xamarin mobile apps. The reason given was that .NET Core was scoped as a run-time for server applications, so no work had been done on making it run on mobile devices, whilst Mono has been used in production on those platforms for some time.
That seems valid now. But developing two runtimes in parallel doesn't seem that great of an investment. Plus there are already dotnet core contributions regarding portability, for example from Samsung, it seems reasonable to think that 2-3-5 years from now dotnet core will power Mono as well.
You could be right, the current situation is unsettled, so I'm personally reluctant to predict anything much. The argument for Mono seems to boil down to the MS teams not having enough capacity to get .NET Core production-ready for mobile whilst doing everything else.
I'm going to be learning ASP.NET Core, but not even think about possible production use until after the next release. We will probably continue to avoid .NET for mobile, and I would not consider Mono for any other use case.
Well, .NET Core is probably still 1-1.5 years away from being fully production "friendly". Common Open Source .NET libraries have to be ported, .NET Core itself needs to reach base class library parity at least as far as its scope is concerned (including things such as System.Drawing based on Skia# or similar), the tooling around it needs to mature.
Anything outside of ASP.NET Core or small command-line tools is probably premature in 2016.