4 ms·

> Given many of the API additions in .NET Standard 2.1 require runtime changes in order to be meaningful, .NET Framework 4.8 will remain on .NET Standard 2.0 ra

> Given many of the API additions in .NET Standard 2.1 require runtime changes in order to be meaningful, .NET Framework 4.8 will remain on .NET Standard 2.0 rather than implement .NET Standard 2.1. .NET Core 3.0 as well as upcoming versions of Xamarin, Mono, and Unity will be updated to implement .NET Standard 2.1. At some point, is it reasonable to expect Xamarin, Mono, Unity, and .NET Core to all really be backed by .NET Core? And if/when so, is there any difference between .NET Standard and .NET Core since, after .NET Framework has been essentially maintenance-mode'd, there will be only one .NET Standard implementation? Similar question, besides just having multiple implementations, what benefit is there to having both Mono and .NET Core separate (at least for the .NET Standard impl part)?

nikofeyn 8y ago
.net standard and .net core and two separate things. the former is an api/library specification and the latter is an implementation of that specification. mono and .net framework are also implementations. https://docs.microsoft.com/en-us/dotnet/standard/net-standard https://docs.microsoft.com/en-us/dotnet/standard/net-standar... https://msdn.microsoft.com/en-us/magazine/mt842506.aspx https://msdn.microsoft.com/en-us/magazine/mt842506.aspx
- kodablah 8y ago
  I understand that, but I am asking if the implementation ends up becoming the only implementation of a specification, is there a meaningful difference between the two? I would expect Mono to use more of .NET Core (or if not, curious why not hence my last question), and .NET framework is no longer an implementation of current and future .NET standard specifications (hence the part I quoted).
  - nikofeyn 8y ago
    oh, i see what you mean now. from my understanding, .net core 3.0 will start to make .net core the primary choice of development for new projects on windows since it will include the uwp, wpf, and winforms desktop packs. but if you still need cross-platform ui and graphics, mono is still the only choice. so it does seem that microsoft is converging on trying to "get rid of", so to speak, .net framework and mono, but it seems there's still a ways to go. even a newish project in the wilderness labs meadow board used mono and not .net core for their project. i am sure it's because they started a while ago and there were technical reasons. .net core lacked features mono had for a while (and maybe still does, not for sure of the current status). moving existing projects like it, unity, and xamarin from mono to .net core is probably a huge undertaking. in terms of naming, i think it makes sense to keep the distinction between .net standard and .net core, even if .net core slowly heads towards becoming the de facto implementation. i doubt .net framework and mono ever really go away anyway, so the distinction is still needed.
oaiey 8y ago
Mono and .NET Core will never merge. But it is not a black and white thingy. .NET Core has a sub project named corefx (Base Class Library), which acts as a master for most of the class library of Mono nowadays. However, the runtime below (mono or coreclr for .NET) are different animals. Mono is highly optimized on portable code (it runs in many more places than .NET Core) while .NET Core is tuned for performance. Unity is based on Mono but also has yet another different runtime (it basically compiles the code first in C++ and then with C++ backends to the target architecture). Expect here the same as for Mono. It is specialized and will stay specialized.
- kodablah 8y ago
  That makes sense with regards to the runtimes and non-spec'd libs. But I was under the impression .NET Standard was essentially the class library spec and if .NET Core is/becomes the only impl of that class library spec it would seem strange to separate the spec from the impl when only one of each exists built by the same blessed implementer. I can definitely understand different compilers, AOT/JIT engines, GCs, etc. Even with minor .NET Standard impl differences in Mono, if they are so minor that they only augment .NET Core, it comes off as an optimization rather than a separate implementation. If the class library impl differences remain major, I would wonder why as surely, even when optimizing for portability vs performance, there is a lot of potential reuse.
  - oaiey 8y ago
    Consider e.g. the cryptography support in the .NET Standard. On Linux it is based on OpenSSL (AFAIR), on Windows based on the crypto library there, on MacOS on another one, on Android another one and let us not speak of iOS. All of them follow on the surface the same API spec. But behind the scenes all .NET implementations have different strategies to deal with. And for good reasons. In this cases you need a standard but not a shared implementation.
    - kodablah 8y ago
      I don't think deferring by platform preference is enough of a reason to separate the standard from the abstracting implementation. Most languages, with or without a "standard" and multiple implementations, defer to the platforms' preferred ways of, say, obtaining cryptographically random numbers.

nikofeyn 8y ago

.net standard and .net core and two separate things. the former is an api/library specification and the latter is an implementation of that specification. mono and .net framework are also implementations. https://docs.microsoft.com/en-us/dotnet/standard/net-standard https://docs.microsoft.com/en-us/dotnet/standard/net-standar... https://msdn.microsoft.com/en-us/magazine/mt842506.aspx https://msdn.microsoft.com/en-us/magazine/mt842506.aspx

kodablah 8y ago
I understand that, but I am asking if the implementation ends up becoming the only implementation of a specification, is there a meaningful difference between the two? I would expect Mono to use more of .NET Core (or if not, curious why not hence my last question), and .NET framework is no longer an implementation of current and future .NET standard specifications (hence the part I quoted).
- nikofeyn 8y ago
  oh, i see what you mean now. from my understanding, .net core 3.0 will start to make .net core the primary choice of development for new projects on windows since it will include the uwp, wpf, and winforms desktop packs. but if you still need cross-platform ui and graphics, mono is still the only choice. so it does seem that microsoft is converging on trying to "get rid of", so to speak, .net framework and mono, but it seems there's still a ways to go. even a newish project in the wilderness labs meadow board used mono and not .net core for their project. i am sure it's because they started a while ago and there were technical reasons. .net core lacked features mono had for a while (and maybe still does, not for sure of the current status). moving existing projects like it, unity, and xamarin from mono to .net core is probably a huge undertaking. in terms of naming, i think it makes sense to keep the distinction between .net standard and .net core, even if .net core slowly heads towards becoming the de facto implementation. i doubt .net framework and mono ever really go away anyway, so the distinction is still needed.

oaiey 8y ago

Mono and .NET Core will never merge. But it is not a black and white thingy. .NET Core has a sub project named corefx (Base Class Library), which acts as a master for most of the class library of Mono nowadays. However, the runtime below (mono or coreclr for .NET) are different animals. Mono is highly optimized on portable code (it runs in many more places than .NET Core) while .NET Core is tuned for performance. Unity is based on Mono but also has yet another different runtime (it basically compiles the code first in C++ and then with C++ backends to the target architecture). Expect here the same as for Mono. It is specialized and will stay specialized.

kodablah 8y ago
That makes sense with regards to the runtimes and non-spec'd libs. But I was under the impression .NET Standard was essentially the class library spec and if .NET Core is/becomes the only impl of that class library spec it would seem strange to separate the spec from the impl when only one of each exists built by the same blessed implementer. I can definitely understand different compilers, AOT/JIT engines, GCs, etc. Even with minor .NET Standard impl differences in Mono, if they are so minor that they only augment .NET Core, it comes off as an optimization rather than a separate implementation. If the class library impl differences remain major, I would wonder why as surely, even when optimizing for portability vs performance, there is a lot of potential reuse.
- oaiey 8y ago
  Consider e.g. the cryptography support in the .NET Standard. On Linux it is based on OpenSSL (AFAIR), on Windows based on the crypto library there, on MacOS on another one, on Android another one and let us not speak of iOS. All of them follow on the surface the same API spec. But behind the scenes all .NET implementations have different strategies to deal with. And for good reasons. In this cases you need a standard but not a shared implementation.
  - kodablah 8y ago
    I don't think deferring by platform preference is enough of a reason to separate the standard from the abstracting implementation. Most languages, with or without a "standard" and multiple implementations, defer to the platforms' preferred ways of, say, obtaining cryptographically random numbers.