7 ms·

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 muc

by geofft 5y ago

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.

DaiPlusPlus 5y ago
> 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.
- smoldesu 5y ago
  > 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.
  - toyg 5y ago
    > 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.
    - DaiPlusPlus 5y ago
      > 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).

by geofft 5y ago

DaiPlusPlus 5y ago

> 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.

smoldesu 5y ago
> 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.
- toyg 5y ago
  > 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.
  - DaiPlusPlus 5y ago
    > 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).