3 ms·
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 ope
by pllbnk 10y ago
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. This problem that they have solved in their own unique way has been solved before countless times. 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.
Now we have so many different versions to follow that I am really worried it will be impossible to keep any level of uniformity and compatibility between them. There are .NET Standard, Canadian, .NET Core, Mono, .NET Framework with .NET Standard's compatibility shim and .NET Core tooling. I hope I didn't forget anything else. It's already crazy as it is.
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.
- WorldMaker 10y ago«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.
- rpeden 10y ago> .NET Standard, Canadian, .NET Core, Mono, .NET Framework Ahh yes, good old .NET Canadian. It's exactly the same as normal .NET, except all methods and properties referring to 'Color' have been changed to 'Colour'. As a Canadian .NET developer, this has caused me endless headaches when trying to pull in American graphics libraries via NuGet.
- deleted 10y ago[deleted]
- pllbnk 10y agoAutocorrect got me there and I could not figure out how to edit the comment. I forgot what I meant to write there if anything but the point stays the same.
- rpeden 10y agoI figured you were a victim of autocorrect. I was just having a bit of fun with it. I thought you might have been taking about the .NET Foundation but made a typo and it got mangled by autocorrect. Regardless, I agree with your point. The name of things in the .NET ecosystem is a bit confusing right now.