Right, I have to admit I don't entirely understand the .NET kerfuffle. .NET is clearly Microsoft's language ecosystem, just as much as Swift is Apple's, and much more so than, say, Go is Google's. A lot of the value in .NET is how it works with the Microsoft ecosystem - or put another way, as someone who mostly doesn't develop on Windows (but uses Windows a lot as a desktop OS), I have never once felt that .NET was the best way to solve a problem that wasn't a Windows-specific problem.
It would be totally fine if .NET were a closed-source, Microsoft-run language. It is pretty cool that this isn't true. But the idea that Microsoft organizationally having control over the .NET open source project is somehow bad for open source is just incomprehensible to me, who grew up on .NET not being open source at all.
> It is pretty cool that this isn't true. But the idea that Microsoft organizationally having control over the .NET open source project is somehow bad for open source is just incomprehensible to me, who grew up on .NET not being open source at all.
It's not about open-source: it's more that major organizations and industries won't use a programming platform that is entirely at the whims of a company they have no real control over and without independent means to ensure it keeps on working, so a compromise position that Microsoft took is to make .NET open-source, so that in the event Microsoft disappears overnight (say, Mt. Rainier erupting and wiping out the Seattle metro area) people have something they can keep on using and build and maintain themselves. We saw the opposite with VB6: the VB6 platform was never open and shared and now all the companies that invested in VBA and VB6 in the 1990s is rightfully annoyed because VB6 is a complete dead-end with no feasible upgrade-path to .NET (VB.NET is not compatible with VB6).
--------
While my SaaS (and my current job) is a .NET shop because it originated with some "Classic" ASP 3.0 VBScripts that my boss put together himself in the late 1990s that was slowly transitioned through .NET WebForms (ew) and ASP.NET MVC, we still use it for new greenfield projects because .NET is a nice platform overall that scales really well from one-off prototype projects that can be easily transitioned to high-performance distributed applications without any major rewrites (the only thing I've had to "rewrite" was the conversion from .aspx (as an MVC View, not WebForms) to Razor .cshtml, everything else has been refactored through the years. The tooling and integration between MS products and services does save a lot of trouble otherwise (that's where the value is).
My experience from other shops, and the problems I've seen there is not that other "stacks" (I hate that word) like MySQL+PHP, Postgres+Python, Anything+NodeJS are somehow less capable (excepting PHP, it's often the opposite, actually) but that you end up with dozens of projects all with their own separate stacks and build environments, all with their own tedious onboarding processes (e.g. having one Angular project that absolutely requires Node 12, not Node 14, to run) while another project's server-side NodeJS code absolutely requires Node 16 and Python and Tomcat somewhere.
So I'm more than happy to pay the thousands of USD per year for my MSDN Subscription because it gives me a platform that saves me the trouble and headaches of a highly heterogenous environment especially given the fact we're a small shop.
> major organizations and industries won't use a programming platform that is entirely at the whims of a company they have no real control over
100% this, the biggest issue I see with dotnet and Swift is that they're spending too much time trying to be appealing to people who don't want to use them. Swift, as a language, really only makes sense to use if you're extensively targeting Apple systems and planning to skip Windows/Linux altogether. That's a pretty shit deal, from the perspective of developers who want to deliver software to the largest possible audience. Similarly, writing an entire program in dotnet used to be a death sentence until Mono finally got thrown together. Even still it's not a very attractive framework for most cases, which just goes to show how important open governance can be when developing such a complex system.
> Similarly, writing an entire program in dotnet used to be a death sentence until Mono
This is somewhat ironic, considering .NET is effectively "Java as rebuilt by Microsoft", and one of the original selling point of Java was... cross-platform support, "write once - run anywhere". BillG clearly made sure that particular aspect would not carry over to the MS version.
> BillG clearly made sure that particular aspect would not carry over to the MS version.
Heh, well .NET's cross-architecture support was/is still useful for allowing .NET to target Windows CE on SH-3, MIPS, ARM and more - also consider that at-the-time (1999-2001) even though Windows NT no-longer supported MIPS and Alpha, there was IA-64 (Itanium) looming on the horizon which was widely anticipated to replace x86 (hah), so even though it wasn't true cross-platform (i.e. cross-OS) it still made business-sense.
Another advantage of .NET's use of JIT bytecode was that Microsoft could sell it as a platform enabling "verifiable code": which is true: a "pure" CIL/MSIL assembly file literally cannot have any memory-related bugs to worry about and their consequential security vulnerabilities, which were a big deal at the time (this was related to Microsoft's "Trustworthy computing" initiative as well: you don't need to "trust" the programs you're running: the use of verifiable bytecode means you can verify its safety entirely by yourself).
Oh yeah, compared to what it was meant to replace (COM/DCOM, C++, VB6, ASP/vbscript), .NET was undoubtedly a massive step forward and a no-brainer to adopt, for anyone invested in the MS ecosystem.
The design and support for cross-platform use was there from the start, and most obviously manifested itself via Rotor. If I recall correctly it targeted FreeBSD rather than Linux though.
ROTOR was never production-quality though - I think it was there as a proof-of-concept and to try to convince some university professors to consider it as an alternative to JVM.
> it's more that major organizations and industries won't use a programming platform that is entirely at the whims of a company they have no real control over and without independent means to ensure it keeps on working,
That is a risk that is common to every single industry, and as such is a risk that is easily understood and quantifiable. We live in an interdependent world. You're always going to be dependent on suppliers, vendors, equipment etc. We have seen how covid related supply chain issues have affected everyone. Atleast with a S/W platform, what you have in-hand continues to work, and you can continue to use the compiler, libraries, etc to churn out new binaries.
> That is a risk that is common to every single industry, and as such is a risk that is easily understood and quantifiable.
Honestly: No
If it would be "easily quantifiable", you would not see in 2021 still bank ATM running damn Windows XP or nuclear power plant under Win2000 with some old deprecated crap supervisor tools.
It is a common drama with proprietary solutions, they are seducing to install and a nightmare to maintain.
This even more due to the decision to use these "vertically integrated proprietary (crap) solution" are generally taken by executive level without any long term thinking and that will be long way gone when the mess need to be cleaned-up
> If it would be "easily quantifiable", you would not see in 2021 still bank ATM running damn Windows XP or nuclear power plant under Win2000 with some old deprecated crap supervisor tools.
> It is a common drama with proprietary solutions, they are seducing to install and a nightmare to maintain.
The fact the software is "proprietary" or not is largely irrelevant to whether or not the systems-integrator who made those ATMs and Nuclear Power plants is acting responsibly. Had they chosen Linux then that ATM would still be sitting there with just-an-outdated version of some embedded Linux distro.
There is an argument that if they used a GPLv3 or other anti-Tivo license that the end owner or operator of the machine would be able to upgrade the host OS software themselves, however in both of those cases (ATMs and power-plants) what makes-the-thing-run is not the OS but the application software (BankAtm.exe and NuclearReactorMonitor.exe) which will have their own dependencies and (knowing most software) will just break when running on an updated OS - and it'd be even worse on Linux because Linux does not have a stable applications ABI between major releases: the software would need to be recompiled.
Now if the application software itself were also open-source, then I agree: that does help, but I'm not convinced that's a solution either because I can assure you that companies like banks and infrastructure operators are not going to be happy having to do patch-tuesday and recompiling their software on a regular basis for hardware they'd really prefer to leave alone and stable. Hence why they're air-gapped (or at least meant to be air-gapped).
> Had they chosen Linux then that ATM would still be sitting there with just-an-outdated version of some embedded Linux distro.
That's wrong, they would have been in a position to update / maintain themselves their own distro or dedicate that to a third party company that has the knowhow to do so. This for more than 20 years without problems. Because they would DO have the code for it if they want it.
With proprietary solutions in the embedded system world, this is impossible to do. If your providers refuses to support your OS anymore, you're fucked and that's it. And if he wants to increase the cost of your support maintenance program per 10x because it's legacy, you're fucked too, just in an other way.
> Linux because Linux does not have a stable applications ABI between major releases: the software would need to be recompiled.
I disagre and for two reasons:
- first, if it's your software stack recompiling should not be a problem
- second, it is not true. Kernel ABI is stable (mostly). And running statically compiled binary between major kernel releases never have been a problem.
> infrastructure operators are not going to be happy having to do patch-tuesday and recompiling their software on a regular basis for hardware they'd really prefer to leave alone and stable.
Do they ?
Even on ATM, client software evolves and is updated. In their case, they just do it with the pain of a legacy system without being able to touch to the platform itself because they have no control on it.
I don't understand. Is your claim that ATMs are running Windows XP because Microsoft did get buried under a pile of ash in the early '00s and released no further OS upgrades, and therefore it would have been better for the ATM manufacturer to use an open-source OS because they, unlike Windows, survived to 2021?
Nobody in this thread is arguing that everything in the world is perfect. There are a lot of bad things in the world. (The fact that we haven't figured out a reliable, scalable way to develop major F/OSS projects without the backing of companies that either sell proprietary software or do far worse things is certainly one of them!)
The specific argument in this subthread is about whether it's okay to build your business on proprietary software or whether there's too much of a risk that the vendor will stop producing updates. If they aren't interested in updates when they actually happened, then clearly this wasn't a concern for them.
(Also, have you never seen people running extremely out-of-date versions of F/OSS operating systems?)
> The specific argument in this subthread is about whether it's okay to build your business on proprietary software or whether there's too much of a risk that the vendor will stop producing updates
It has everything to do with that and I think it's a way too narrow view.
In this case Microsoft indeed did not go bankrupt. They did however stopped to provide updates to solution "Windows XP", without giving an alternative compatible on the same legacy hardware (the old ATM hardware).
And that illustrates perfectly the problem with proprietary ecosystem. You do NOT need your provider to bankrupt to put yourself in shit, you just need him to have interests diverging of your interests.
Because at the end, he is the one controlling your software stack, not you.
> They did however stopped to provide updates to solution "Windows XP", without giving an alternative compatible on the same legacy hardware (the old ATM hardware).
Hang on there… Microsoft never did stop making updates to Windows XP Embedded - they kept it on super-extended support as “Windows POSReady” (I think the pun was intentional…) and it’s replacement in “Windows IoT” is reasonable.
Your argument is valid only if ATM manufacturers were being missold XP Embedded by Microsoft on the basis that the support lifecycle of XP Embedded would outlive the ATM hardware - but I put it to you that is not the case. The support lifeycle of MS products is (surprisingly) well-documented and transparent - and to my knowledge (and saying that as a former blue-badge myself) MS has never represented XP Embedded (or other NT-family OSes) as being suitable for a 20+ year lifespan. The blame lies squarely with the systems-integrator who built the ATMs.
>If it would be "easily quantifiable", you would not see in 2021 still bank ATM running damn Windows XP or nuclear power plant under Win2000 with some old deprecated crap supervisor tools.
Why would you not see that? The risk profile is well understood, and can be mitigated. Sandboxes, firewalls, app-containers, input sanitization, Virtual Machines, etc, etc, etc.
I don't quite understand exactly what you're disagreeing with?
Honestly, I’m fine with this level of dickishness so long as it means the rest of the VS ecosystem is free-to-use.
Someone or something has to subsidise VSCode.