Re:Explaining .NET Standard Like I'm Five
by WorldMaker on Thursday January 12, 2017 @03:55PM
(#13386028)
«I often wonder why did they decide to introduce such complexity with all independently developed runtimes with unrelated versions and all if they went fully open source.»
Most of the runtimes were developed evolutionarily for different system niches, well before .NET was given the option to be open source by default. .NET Core tried to reboot some of the "organic" evolutionary tech debt of several runtimes it was directly replacing/built from (the Silverlight runtime; the old Windows Phone runtime; the WinRT .NET runtime).
«Python is a great example, since you have your standard library with some rather carefully selected OS-specific APIs and then you got a bunch of runtimes all under the same version; no confusion whatsoever.»
Python still has multiple runtimes and some small amounts of confusion: CPython, Pypy, Stackless, IronPython, Python on Parrot... They don't/haven't all support the same version of the language and CPython has always been the "official standard" version, but Python is an example that no language is entirely immune from multiple runtimes either.
«I am a long time .NET developer and I also was confused in the beginning of .NET Core about what was going on and I think their rush to release an unfinished product was to blame.»
I don't think .NET Core was in a rush to release an "unfinished product", though it may seem to for a long term .NET developer. .NET Core has been the first runtime allowed to develop out in the open, as open source. It took about the same development time, I'd estimate, as the most similar projects you could imagine. But instead of showing up "out of nowhere" in VS 2017 Preview 1, mostly complete, we saw a lot of the little and big decisions along the way. Because it was .NET and promising big things I think .NET Core got a lot more early scrutiny by the .NET developers in what was closer to the equivalent of Python's "PEP development" phase, to use Python as the analogy, than .NET Developers had ever seen before.
Most of the runtimes were developed evolutionarily for different system niches, well before .NET was given the option to be open source by default. .NET Core tried to reboot some of the "organic" evolutionary tech debt of several runtimes it was directly replacing/built from (the Silverlight runtime; the old Windows Phone runtime; the WinRT .NET runtime).
«Python is a great example, since you have your standard library with some rather carefully selected OS-specific APIs and then you got a bunch of runtimes all under the same version; no confusion whatsoever.»
Python still has multiple runtimes and some small amounts of confusion: CPython, Pypy, Stackless, IronPython, Python on Parrot... They don't/haven't all support the same version of the language and CPython has always been the "official standard" version, but Python is an example that no language is entirely immune from multiple runtimes either.
«I am a long time .NET developer and I also was confused in the beginning of .NET Core about what was going on and I think their rush to release an unfinished product was to blame.»
I don't think .NET Core was in a rush to release an "unfinished product", though it may seem to for a long term .NET developer. .NET Core has been the first runtime allowed to develop out in the open, as open source. It took about the same development time, I'd estimate, as the most similar projects you could imagine. But instead of showing up "out of nowhere" in VS 2017 Preview 1, mostly complete, we saw a lot of the little and big decisions along the way. Because it was .NET and promising big things I think .NET Core got a lot more early scrutiny by the .NET developers in what was closer to the equivalent of Python's "PEP development" phase, to use Python as the analogy, than .NET Developers had ever seen before.