5 ms·

To paint a picture: I’ve worked with Microsoft technologies almost exclusively for decades but recently I was forced to pick up some Node.js, Docker, and Linux

To paint a picture: I’ve worked with Microsoft technologies almost exclusively for decades but recently I was forced to pick up some Node.js, Docker, and Linux tooling for a specific app. I can’t express in words what a giant step backwards it is from ASP.NET and Visual Studio. It’s like bashing things with open source rocks after working in a rocket manufacturing facility festooned with Kuka robots. It’s just… end-to-end bad. Everything from critical dependencies developed by one Russian kid that’s now getting shot at in Ukraine so “maintenance is paused” to everything being wired up with shell scripts that have fifty variants, no standards, and none of them work. I’ve spent more time just getting the builds and deployments to work (to an acceptable standard) for Node.js than I’ve spent developing entire .NET applications! [1] I have had similar experiences every few years for decades. I touched PHP once and recoiled in horror. I tried to get a stable build going for some Python ML packages and learnt that they have a half-life measured in days or hours after which they become impossible to reproduce. Etc… Keep on assuming “Microsoft is all bad” if you like. You’re tying both hands behind your back and poking the keyboard with your nose. PS: The dotnet SDK is open source and works fine on Linux, and the IntelliJ Rider IDE is generally very good and cross-platform. You're not forced to use Windows. [1] The effort required to get a NestJS app to have barely acceptable performance is significantly greater than the effort to rewrite it in .NET 9 which will immediately be faster and have a far bigger bag of performance tuning tools and technologies available if needed.

cyberax 1y ago
I tried developing an MS .NET app and it's indescribably bad. The deployment story is non-existent, monitoring, tracing, alarming is barely there. You have to work with MS libraries that are on life-support with glaring bugs still present.
- jiggawatts 1y ago
  Unless you found yourself in some bizarre dark corner of a huge ecosystem of products, that's just not true. Deployments are just "file copy". You don't even need Docker, because Windows isn't Linux, it has stable user-land APIs so apps are portable. Not to mention that the dotnet sdk can create container images directly without even needing Docker installed: https://learn.microsoft.com/en-us/dotnet/core/containers/sdk-publish https://learn.microsoft.com/en-us/dotnet/core/containers/sdk... There are pre-built Linux and Windows ASP.NET base docker images: https://learn.microsoft.com/en-us/aspnet/core/host-and-deploy/docker/building-net-docker-images?view=aspnetcore-9.0 https://learn.microsoft.com/en-us/aspnet/core/host-and-deplo... Visual Studio's ASP.NET templates all have a literal checkbox for "Docker support" which is all it takes to have a hot-reload debugging/editing experience. The dotnet runtime has very good Docker support, including automatic memory usage tuning to prevent it getting killed by Kubernetes or whatever. The underlying "App Host" below ASP.NET has fantastic support for layered configuration, which by default supports environment variables, command line parameters, named environment configuration files, and "user secrets" in IDEs. All of it is strongly typed and supports runtime refresh instead of Linux style "restart the process and interrupt user file uploads to get a new config". There's plugins for Key Vault, AWS KMS, App Configuration, feature flags, and on-and-on. Open Telemetry is fully supported and now the default: https://learn.microsoft.com/en-us/dotnet/core/diagnostics/observability-with-otel https://learn.microsoft.com/en-us/dotnet/core/diagnostics/ob... Everything in ASP.NET uses the standard built-in ILogger interface, so wiring up any kind of audit logging or custom observability is a piece of cake: https://learn.microsoft.com/en-us/dotnet/api/microsoft.extensions.logging.ilogger?view=net-9.0-pp https://learn.microsoft.com/en-us/dotnet/api/microsoft.exten... The really fancy logging uses the high-performance ActivitySource APIs, which are used for lower-level tracing of dependencies and the like. Again, these are standardised throughout not just Microsoft libraries but most third-party packages too: https://learn.microsoft.com/en-us/dotnet/api/system.diagnostics.activitysource?view=net-9.0 https://learn.microsoft.com/en-us/dotnet/api/system.diagnost... Aspire.NET can orchestrate multiple cloud emulators, multiple apps, Node.js front-end apps, and wire up the whole thing with Open Telemetry and a free local trace viewer (with span support) with zero config: https://learn.microsoft.com/en-us/dotnet/aspire/fundamentals/dashboard/explore https://learn.microsoft.com/en-us/dotnet/aspire/fundamentals... Windows GUI App deployments use standardised installer packages (MSI) that have simple devops pipeline tooling: https://github.com/wixtoolset https://github.com/wixtoolset Now... name the one package format that you can use to distribute client apps to all Linux distros! When you run "dotnet build", the result is built, unlike Node.js where you end up with 150K tiny little files that need to be rebuilt again "in production" because oh-my-god it's a scripting language with C code blended in randomly, so it doesn't... actually... build. I just had the fun of trying to figure out why PM2 doesn't like musl or running under non-root user accounts, why starting a Node.js app takes frigging minutes whereas ASP.NET starts in milliseconds, and on and on.
  - majkinetor 1y ago
    All that, and finally, PowerShell, literary light years ahead of everything Linux has to offer. I have PTSD from bash and friends. It is so good, that I rarely even write C# nowadays for most of the critical government stuff and simply run smallish scripts as services, and change them on the server when intervention is needed in notepad, in a couple of minutes, while my colleagues still worm up their full-blown Visual Studio. I love it like it is the hottest wife that have a great job, do the dishes and cooks like a grandma (I am bad at this :))
    - bluefirebrand 1y ago
      > change them on the server when intervention is needed in notepad How is this any different than a Linux setup where you can just ssh into a box and edit your scripts in the shell using something like nano or vim if you're into that sort of thing?
      - majkinetor 1y ago
        It's not different. I am not talking about method, I talk about the language and ecosystem. Package manager for scripts? Yeah. Standardized names and params? Fuck yeah. Drop to dotNet on funky corners? Shut up and take my money. Put pwsh on linux (I do, in all of them) and I will use ssh and vim no problem.
    - mrcsharp 1y ago
      And now there is going to be support for `dotnet run app.cs` which, in my opinion, will replace most of my powershell scripts.
      - majkinetor 1y ago
        Yeah, that is a new thing, but honestly it existed a way back, its just that it is now officially supported. But you are missing a point here. It's about the language, ecosystem and practicality. In shell, you need correct abstraction that lets you work in fast and efficient way and lets you interact fast when debug is needed. What is done using c# in 10 lines can be done in a single line in pwsh. In my book, lower amount of code, ideally no code, is the most important aspect of the development. Majority of things are not constrained by the performance, so pwsh is usually a good fit. People used ruby, python etc. for infrastructure development long time ago and it was/is akward.
- herbst 1y ago
  I feel you. Having done sane programming before I tried it all the .NET stuff didn't feel right. Like they made Java even more ugly and brought nothing new to the table that works outside of their weird ecosystem. (At least that was the state 10-15 years ago, coding .NET on/for Linux)
  - jiggawatts 1y ago
    It’s wildly different now. The first release that would run at all on Linux was 9 years ago and was essential a beta or maybe just a proof of concept. The current .NET 9 version has trivialised my development projects to the point that I feel bad for taking the customer’s money. The only problem I’ve had with .NET is that it doesn’t have the same breadth of third party libraries that Java has. If you need something really obscure it either exists in Java or nowhere else.
    - herbst 1y ago
      That sounds magical. What makes it so superior tho? You mean in terms of ready made libraries doing the heavy lifting? If so would nodejs or rails not be even easier? Or do you mean specific on desktop applications? I have no idea about that field
      - jiggawatts 1y ago
        ASP.NET Just Works and has Batteries Included. As an example, just over the last few days, I hit all of these common issues with Node.js apps (that don't happen with ASP.NET): 1) Node apps are typically a "transpiled language on a language" because JavaScript is unusable for large-scale software development so everyone uses TypeScript compiled to JavaScript instead. But this is a hack! A clever, useful hack, but a hack nonetheless. You can't go two steps without finding the rough edges, such as "any" everywhere or the use of "monkeypatching" which makes static analysis impossible for either tools or humans. (This reminds me of the earliest days of C++ where compilers like Cfront transpiled C++ to C.) 2) It's single-threaded! Sure, this is simpler, right up until it's not. It means you need about one process per core. Which means that on typical hardware you get a max of 4-8 GB of memory per process, because that's what most hardware has per core. This means in-memory caching is generally too inefficient. (I finally understand why Redis is so popular!) 2b) Okay, let's take a look at Redis! What do you mean it doesn't properly support multiple databases per cluster!? It's single threaded too!? Wat!? Is this a database for children? 3) It takes minutes to start! I hope you never have an emergency update that needs to go out right now!. ASP.NET takes seconds at most. This is largely because it's precompiled and ships as a small number of large binary files instead of millions (literally!) of tiny files that are very slow on almost all server-grade storage. There's now ahead-of-time (AoT) compilation modes for ASP.NET that make it comparable to C++, Rust, or Go in startup performance! 4) I'm sure Node people have heard of certificates and HTTPS, but I'm fairly certain they think it's a fad and it'll just "go away" eventually. 5) NPM libraries are under constant churn. Just updating packages requires minutes of 100% computer power to resolve the dependency graph logic... which has changed. In a breaking way. Either way, it can be mathematically impossible to disentangle the mess before the heat death of the universe. I'm not kidding! It's possible to get into a situation where "error: timed out" doesn't quite do it justice. 6) In .NET land there's basically only two ORMs used: Entity Framework from Microsoft and Dapper from StackOverflow. They work fine. Someone at $dayjob picked "typeorm" for Node. Is it the best? Who knows! There's dozens to pick from! None of them work properly, of course. I do know that typeorm doesn't allow me to pick my own database driver. Why? Because they're too busy, according to the GitHub issue tickets. Entity Framework uses a pluggable interface with dozens of well-supported implementations. This is because the entire platform, all of its database support, and the ORM on top were written by one vendor in a coordinated way and is pluggable via interfaces in the standard library instead of a hodge-podge of random code thrown together by literal children. [2] Etc, etc... [1] Under-funded is the more generous reason. [2] A very significant portion of NPM packages were written by people under the age of 18. This is either commendable or horrifying depending on your perspective. It's hard to prove though, because contributions are effectively anonymous.
- mrcsharp 1y ago
  > The deployment story is non-existent Wrong! it is as simple as executing `dotnet publish`, zipping up the output folder and sending that package somewhere using whichever protocol and shell utility you like. > monitoring, tracing, alarming is barely there Also wrong. OpenTelemetry is fully supported by first-class packages and the dotnet runtime itself exposes a lot of counters. There are a lot of tools to monitor and collect traces of running dotnet processes [1] > You have to work with MS libraries that are on life-support with glaring bugs still present You don't have to. Every Microsoft.* library follows strict semantic versioning and is clearly labeled when it is deprecated. If you don't have a plan in place on how to manage your dependencies then this is on you. [1] https://learn.microsoft.com/en-us/dotnet/core/diagnostics/tools-overview https://learn.microsoft.com/en-us/dotnet/core/diagnostics/to...
  - cyberax 1y ago
    > Wrong! it is as simple as executing `dotnet publish` Yeah. And now add a C/C++ component there. Or maybe a neural network in Python? In my case, it was a ray tracer that used a GPU. "Just zip it", yea sure.
    - mrcsharp 1y ago
      > Yeah. And now add a C/C++ component there. Or maybe a neural network in Python? How do you compile and package those components up? Answer that and you have your answer for this scenario. >"Just zip it", yea sure. I don't understand this. You can zip it. You can XCopy it. You can RSync it. Doesn't matter. What's your objection to that statement?
      - cyberax 1y ago
        > How do you compile and package those components up? Answer that and you have your answer for this scenario. I have a Dockerfile that contains the build instructions? How would I do that with MSVS? > I don't understand this. You can zip it. Yes, and then my Linux machine that runs the server will happily run a Windows application. With all the dependencies, including the GPU toolkits. But even if we stay _within_ the MS ecosystem, the "just copy it" deployment doesn't cover everything. E.g. it can't change the settings of the "App Service Logs" from within the app itself. Of course you can also use Terraform for the infra, but at this point you're way off the "just copy a folder". MSVS also supports containers, but if you do that it just becomes a UI for their configuration, not really any different from JetBrains.
th0ma5 1y ago
I have a lot of respect for organizations that get a lot done with Microsoft technologies. I think your perspective could be thought of as the benefits of vertical integration and vendor lock in. These do help people get things done! In the academic and open source world those things are fought against because you don't want to be at the mercy of the software developer in the context of certain rights. I think for every negative you mention on either side a positive could be found on either side. And like many things on the net, you're not wrong but not necessarily talking about the same kinds of things. My remaining complaints about Microsoft are the inflexibility of their solutions that command abstractions that just don't work for many organizations, and the general viral nature of software sales in general of which they are one of many with similar issues, however Oracle is the worst of course.
- jiggawatts 1y ago
  Perfectly valid points. I've worked in academia, and their insistence on non-Microsoft technologies was helpful in certain fields where openness and long-term reproducibility is critical. The downside is that this produces a microcosm of obscure technologies that can have... strange effects on industry. Some FAANG-like companies have a habit of hiring only recent graduates, so their entire staff is convinced that what they saw at their University is how everybody else does things. It leads to Silicon Valley clique that has a fantastically distorted perspective of the rest of the world. Some comments I've seen here on HN are downright hilarious to anyone from the "rest of the world", such as: "Does anyone still use Windows Server!?" -- yes, at least 60% of all deployed servers world wide, and over 80% in many industries. "Supports all popular directory servers such as OpenLDAP, ApacheDS, Kopano, ..." -- hello!? Active Directory! Have you heard of it!? It's something like 95% of all deployed LDAP deployments no matter how you count it! The other 5% is Oracle Directory and/or Novell eDirectory and then all of the rest put together is a rounding error.
  - ArcHound 1y ago
    I agree with this, I see the AD as critical. Do you please have a source for these numbers? Would love to include it in the article.
dismalaf 1y ago
Everything you describe has more to do with the state of JavaScript development than MS vs. Linux tooling. I wouldn't touch .NET for ideological reasons (and fear of a rug pull) but I also wouldn't touch any server side JS because I value my sanity.
m_st 1y ago
Thanks for writing this. I couldn't agree any more. We've worked with .NET for decades and it really just works or lets you debug easily. Then we've started working on projects with Angular, React and Docker and it's just a nightmare to get a stable version.
- jsiepkes 1y ago
  Comparing .Net to Angular and Docker is comparing apples to oranges. Now if you moved from .Net to say Linux and the Java ecosystem (Maven, Intellij, etc.) that would be something you can compare.
- jiggawatts 1y ago
  There was a study comparing the “half life” of code in different codebases as a measure of “churn”. Linux unsurprisingly is pretty stable. Meanwhile Angular is the worst with code lasting just months before it’s rewritten. Then again months later. And again. And again. This is why it has so many breaking changes.

cyberax 1y ago

I tried developing an MS .NET app and it's indescribably bad. The deployment story is non-existent, monitoring, tracing, alarming is barely there. You have to work with MS libraries that are on life-support with glaring bugs still present.

jiggawatts 1y ago
Unless you found yourself in some bizarre dark corner of a huge ecosystem of products, that's just not true. Deployments are just "file copy". You don't even need Docker, because Windows isn't Linux, it has stable user-land APIs so apps are portable. Not to mention that the dotnet sdk can create container images directly without even needing Docker installed: https://learn.microsoft.com/en-us/dotnet/core/containers/sdk-publish https://learn.microsoft.com/en-us/dotnet/core/containers/sdk... There are pre-built Linux and Windows ASP.NET base docker images: https://learn.microsoft.com/en-us/aspnet/core/host-and-deploy/docker/building-net-docker-images?view=aspnetcore-9.0 https://learn.microsoft.com/en-us/aspnet/core/host-and-deplo... Visual Studio's ASP.NET templates all have a literal checkbox for "Docker support" which is all it takes to have a hot-reload debugging/editing experience. The dotnet runtime has very good Docker support, including automatic memory usage tuning to prevent it getting killed by Kubernetes or whatever. The underlying "App Host" below ASP.NET has fantastic support for layered configuration, which by default supports environment variables, command line parameters, named environment configuration files, and "user secrets" in IDEs. All of it is strongly typed and supports runtime refresh instead of Linux style "restart the process and interrupt user file uploads to get a new config". There's plugins for Key Vault, AWS KMS, App Configuration, feature flags, and on-and-on. Open Telemetry is fully supported and now the default: https://learn.microsoft.com/en-us/dotnet/core/diagnostics/observability-with-otel https://learn.microsoft.com/en-us/dotnet/core/diagnostics/ob... Everything in ASP.NET uses the standard built-in ILogger interface, so wiring up any kind of audit logging or custom observability is a piece of cake: https://learn.microsoft.com/en-us/dotnet/api/microsoft.extensions.logging.ilogger?view=net-9.0-pp https://learn.microsoft.com/en-us/dotnet/api/microsoft.exten... The really fancy logging uses the high-performance ActivitySource APIs, which are used for lower-level tracing of dependencies and the like. Again, these are standardised throughout not just Microsoft libraries but most third-party packages too: https://learn.microsoft.com/en-us/dotnet/api/system.diagnostics.activitysource?view=net-9.0 https://learn.microsoft.com/en-us/dotnet/api/system.diagnost... Aspire.NET can orchestrate multiple cloud emulators, multiple apps, Node.js front-end apps, and wire up the whole thing with Open Telemetry and a free local trace viewer (with span support) with zero config: https://learn.microsoft.com/en-us/dotnet/aspire/fundamentals/dashboard/explore https://learn.microsoft.com/en-us/dotnet/aspire/fundamentals... Windows GUI App deployments use standardised installer packages (MSI) that have simple devops pipeline tooling: https://github.com/wixtoolset https://github.com/wixtoolset Now... name the one package format that you can use to distribute client apps to all Linux distros! When you run "dotnet build", the result is built, unlike Node.js where you end up with 150K tiny little files that need to be rebuilt again "in production" because oh-my-god it's a scripting language with C code blended in randomly, so it doesn't... actually... build. I just had the fun of trying to figure out why PM2 doesn't like musl or running under non-root user accounts, why starting a Node.js app takes frigging minutes whereas ASP.NET starts in milliseconds, and on and on.
- majkinetor 1y ago
  All that, and finally, PowerShell, literary light years ahead of everything Linux has to offer. I have PTSD from bash and friends. It is so good, that I rarely even write C# nowadays for most of the critical government stuff and simply run smallish scripts as services, and change them on the server when intervention is needed in notepad, in a couple of minutes, while my colleagues still worm up their full-blown Visual Studio. I love it like it is the hottest wife that have a great job, do the dishes and cooks like a grandma (I am bad at this :))
  - bluefirebrand 1y ago
    > change them on the server when intervention is needed in notepad How is this any different than a Linux setup where you can just ssh into a box and edit your scripts in the shell using something like nano or vim if you're into that sort of thing?
    - majkinetor 1y ago
      It's not different. I am not talking about method, I talk about the language and ecosystem. Package manager for scripts? Yeah. Standardized names and params? Fuck yeah. Drop to dotNet on funky corners? Shut up and take my money. Put pwsh on linux (I do, in all of them) and I will use ssh and vim no problem.
  - mrcsharp 1y ago
    And now there is going to be support for `dotnet run app.cs` which, in my opinion, will replace most of my powershell scripts.
    - majkinetor 1y ago
      Yeah, that is a new thing, but honestly it existed a way back, its just that it is now officially supported. But you are missing a point here. It's about the language, ecosystem and practicality. In shell, you need correct abstraction that lets you work in fast and efficient way and lets you interact fast when debug is needed. What is done using c# in 10 lines can be done in a single line in pwsh. In my book, lower amount of code, ideally no code, is the most important aspect of the development. Majority of things are not constrained by the performance, so pwsh is usually a good fit. People used ruby, python etc. for infrastructure development long time ago and it was/is akward.
herbst 1y ago
I feel you. Having done sane programming before I tried it all the .NET stuff didn't feel right. Like they made Java even more ugly and brought nothing new to the table that works outside of their weird ecosystem. (At least that was the state 10-15 years ago, coding .NET on/for Linux)
- jiggawatts 1y ago
  It’s wildly different now. The first release that would run at all on Linux was 9 years ago and was essential a beta or maybe just a proof of concept. The current .NET 9 version has trivialised my development projects to the point that I feel bad for taking the customer’s money. The only problem I’ve had with .NET is that it doesn’t have the same breadth of third party libraries that Java has. If you need something really obscure it either exists in Java or nowhere else.
  - herbst 1y ago
    That sounds magical. What makes it so superior tho? You mean in terms of ready made libraries doing the heavy lifting? If so would nodejs or rails not be even easier? Or do you mean specific on desktop applications? I have no idea about that field
    - jiggawatts 1y ago
      ASP.NET Just Works and has Batteries Included. As an example, just over the last few days, I hit all of these common issues with Node.js apps (that don't happen with ASP.NET): 1) Node apps are typically a "transpiled language on a language" because JavaScript is unusable for large-scale software development so everyone uses TypeScript compiled to JavaScript instead. But this is a hack! A clever, useful hack, but a hack nonetheless. You can't go two steps without finding the rough edges, such as "any" everywhere or the use of "monkeypatching" which makes static analysis impossible for either tools or humans. (This reminds me of the earliest days of C++ where compilers like Cfront transpiled C++ to C.) 2) It's single-threaded! Sure, this is simpler, right up until it's not. It means you need about one process per core. Which means that on typical hardware you get a max of 4-8 GB of memory per process, because that's what most hardware has per core. This means in-memory caching is generally too inefficient. (I finally understand why Redis is so popular!) 2b) Okay, let's take a look at Redis! What do you mean it doesn't properly support multiple databases per cluster!? It's single threaded too!? Wat!? Is this a database for children? 3) It takes minutes to start! I hope you never have an emergency update that needs to go out right now!. ASP.NET takes seconds at most. This is largely because it's precompiled and ships as a small number of large binary files instead of millions (literally!) of tiny files that are very slow on almost all server-grade storage. There's now ahead-of-time (AoT) compilation modes for ASP.NET that make it comparable to C++, Rust, or Go in startup performance! 4) I'm sure Node people have heard of certificates and HTTPS, but I'm fairly certain they think it's a fad and it'll just "go away" eventually. 5) NPM libraries are under constant churn. Just updating packages requires minutes of 100% computer power to resolve the dependency graph logic... which has changed. In a breaking way. Either way, it can be mathematically impossible to disentangle the mess before the heat death of the universe. I'm not kidding! It's possible to get into a situation where "error: timed out" doesn't quite do it justice. 6) In .NET land there's basically only two ORMs used: Entity Framework from Microsoft and Dapper from StackOverflow. They work fine. Someone at $dayjob picked "typeorm" for Node. Is it the best? Who knows! There's dozens to pick from! None of them work properly, of course. I do know that typeorm doesn't allow me to pick my own database driver. Why? Because they're too busy, according to the GitHub issue tickets. Entity Framework uses a pluggable interface with dozens of well-supported implementations. This is because the entire platform, all of its database support, and the ORM on top were written by one vendor in a coordinated way and is pluggable via interfaces in the standard library instead of a hodge-podge of random code thrown together by literal children. [2] Etc, etc... [1] Under-funded is the more generous reason. [2] A very significant portion of NPM packages were written by people under the age of 18. This is either commendable or horrifying depending on your perspective. It's hard to prove though, because contributions are effectively anonymous.
mrcsharp 1y ago
> The deployment story is non-existent Wrong! it is as simple as executing `dotnet publish`, zipping up the output folder and sending that package somewhere using whichever protocol and shell utility you like. > monitoring, tracing, alarming is barely there Also wrong. OpenTelemetry is fully supported by first-class packages and the dotnet runtime itself exposes a lot of counters. There are a lot of tools to monitor and collect traces of running dotnet processes [1] > You have to work with MS libraries that are on life-support with glaring bugs still present You don't have to. Every Microsoft.* library follows strict semantic versioning and is clearly labeled when it is deprecated. If you don't have a plan in place on how to manage your dependencies then this is on you. [1] https://learn.microsoft.com/en-us/dotnet/core/diagnostics/tools-overview https://learn.microsoft.com/en-us/dotnet/core/diagnostics/to...
- cyberax 1y ago
  > Wrong! it is as simple as executing `dotnet publish` Yeah. And now add a C/C++ component there. Or maybe a neural network in Python? In my case, it was a ray tracer that used a GPU. "Just zip it", yea sure.
  - mrcsharp 1y ago
    > Yeah. And now add a C/C++ component there. Or maybe a neural network in Python? How do you compile and package those components up? Answer that and you have your answer for this scenario. >"Just zip it", yea sure. I don't understand this. You can zip it. You can XCopy it. You can RSync it. Doesn't matter. What's your objection to that statement?
    - cyberax 1y ago
      > How do you compile and package those components up? Answer that and you have your answer for this scenario. I have a Dockerfile that contains the build instructions? How would I do that with MSVS? > I don't understand this. You can zip it. Yes, and then my Linux machine that runs the server will happily run a Windows application. With all the dependencies, including the GPU toolkits. But even if we stay _within_ the MS ecosystem, the "just copy it" deployment doesn't cover everything. E.g. it can't change the settings of the "App Service Logs" from within the app itself. Of course you can also use Terraform for the infra, but at this point you're way off the "just copy a folder". MSVS also supports containers, but if you do that it just becomes a UI for their configuration, not really any different from JetBrains.

th0ma5 1y ago

I have a lot of respect for organizations that get a lot done with Microsoft technologies. I think your perspective could be thought of as the benefits of vertical integration and vendor lock in. These do help people get things done! In the academic and open source world those things are fought against because you don't want to be at the mercy of the software developer in the context of certain rights. I think for every negative you mention on either side a positive could be found on either side. And like many things on the net, you're not wrong but not necessarily talking about the same kinds of things. My remaining complaints about Microsoft are the inflexibility of their solutions that command abstractions that just don't work for many organizations, and the general viral nature of software sales in general of which they are one of many with similar issues, however Oracle is the worst of course.

jiggawatts 1y ago
Perfectly valid points. I've worked in academia, and their insistence on non-Microsoft technologies was helpful in certain fields where openness and long-term reproducibility is critical. The downside is that this produces a microcosm of obscure technologies that can have... strange effects on industry. Some FAANG-like companies have a habit of hiring only recent graduates, so their entire staff is convinced that what they saw at their University is how everybody else does things. It leads to Silicon Valley clique that has a fantastically distorted perspective of the rest of the world. Some comments I've seen here on HN are downright hilarious to anyone from the "rest of the world", such as: "Does anyone still use Windows Server!?" -- yes, at least 60% of all deployed servers world wide, and over 80% in many industries. "Supports all popular directory servers such as OpenLDAP, ApacheDS, Kopano, ..." -- hello!? Active Directory! Have you heard of it!? It's something like 95% of all deployed LDAP deployments no matter how you count it! The other 5% is Oracle Directory and/or Novell eDirectory and then all of the rest put together is a rounding error.
- ArcHound 1y ago
  I agree with this, I see the AD as critical. Do you please have a source for these numbers? Would love to include it in the article.

dismalaf 1y ago

Everything you describe has more to do with the state of JavaScript development than MS vs. Linux tooling. I wouldn't touch .NET for ideological reasons (and fear of a rug pull) but I also wouldn't touch any server side JS because I value my sanity.

m_st 1y ago

Thanks for writing this. I couldn't agree any more. We've worked with .NET for decades and it really just works or lets you debug easily. Then we've started working on projects with Angular, React and Docker and it's just a nightmare to get a stable version.

jsiepkes 1y ago
Comparing .Net to Angular and Docker is comparing apples to oranges. Now if you moved from .Net to say Linux and the Java ecosystem (Maven, Intellij, etc.) that would be something you can compare.
jiggawatts 1y ago
There was a study comparing the “half life” of code in different codebases as a measure of “churn”. Linux unsurprisingly is pretty stable. Meanwhile Angular is the worst with code lasting just months before it’s rewritten. Then again months later. And again. And again. This is why it has so many breaking changes.