←back to thread

Microsoft Dependency Has Risks

(blog.miloslavhomer.cz)
151 points ArcHound | 7 comments | | HN request time: 0.828s | source | bottom
Show context
bob1029 ◴[] No.44382065[source]
The trick with Microsoft is to very carefully separate the good parts from the bad ones.

Labeling all of Microsoft as banned is really constraining your technology options. This is a gigantic organization with a very diverse set of people in it.

There aren't many things like .NET, MSSQL and Visual Studio out there. The debugger experience in VS is the holy grail if you have super nasty real world technology situations. There's a reason every AAA game engine depends on it in some way.

Azure and Windows are where things start to get bad with Microsoft.

replies(9): >>44382293 #>>44382372 #>>44382784 #>>44383037 #>>44383467 #>>44385139 #>>44385191 #>>44385341 #>>44385567 #
gerdesj ◴[] No.44382293[source]
"There aren't many things like .NET, MSSQL and Visual Studio out there. The debugger experience in VS is the holy grail if you have super nasty real world technology situations. There's a reason every AAA game engine depends on it in some way."

I'm not interested in AAA games engines writing and nor is most of the world. If that is it, then you have damned MS with (very) faint praise.

replies(4): >>44382385 #>>44382410 #>>44383208 #>>44384422 #
jiggawatts ◴[] No.44382410[source]
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.

replies(4): >>44382506 #>>44382561 #>>44384745 #>>44384883 #
cyberax ◴[] No.44382506[source]
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.
replies(3): >>44382601 #>>44385368 #>>44385426 #
jiggawatts ◴[] No.44382601[source]
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...

There are pre-built Linux and Windows ASP.NET base docker images: 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/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.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.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...

Windows GUI App deployments use standardised installer packages (MSI) that have simple devops pipeline tooling: 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.

replies(3): >>44384289 #>>44385925 #>>44387988 #
1. majkinetor ◴[] No.44384289[source]
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 :))

replies(2): >>44384638 #>>44385441 #
2. bluefirebrand ◴[] No.44384638[source]
> 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?

replies(1): >>44385607 #
3. mrcsharp ◴[] No.44385441[source]
And now there is going to be support for `dotnet run app.cs` which, in my opinion, will replace most of my powershell scripts.
replies(1): >>44385601 #
4. majkinetor ◴[] No.44385601[source]
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.

replies(1): >>44386931 #
5. majkinetor ◴[] No.44385607[source]
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.

6. mrcsharp ◴[] No.44386931{3}[source]
> What is done using c# in 10 lines can be done in a single line in pwsh

Mostly, yes. The problem is that the moment I need something more than what a single cmdlet or bash utility can provide, now I have to use an awkward looking scripting language (bash is the worst offender here). Almost every time I found myself having to write a somewhat long script file, I wish I could just do it with a C like language instead.

For simpler tasks, I fully agree. It is better to use something immediately available like an OS shell utility over coding one myself.

replies(1): >>44388523 #
7. majkinetor ◴[] No.44388523{4}[source]
There are many simple tasks in a typical multiyear project. Most of my scripts are between 100 and 1000 lines of code.

Example: https://github.com/majkinetor/SSImport

That script made noticeable difference in speed, quality and pleasure on our recent project (production tests on payment gateway for half of the country) as before I wrote it, devs did it by hand which took 10s of minutes every day with awkward tools (if they made an error, even more) and they complained about the chore. The script literarry replaces entire feature of the Sql Server Management Studio and I did it during the weekend.

Regarding syntax, not sure why would you consider that awkward. IMO, it can't be easier to read in any language, both configuration and code.