Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Microsoft Dependency Has Risks

blog.miloslavhomer.cz

Post reply on HN
Print view View original

231–238 of 238 posts

Re: Microsoft Dependency Has Risks

#231

Post by whatevaa »

nordsieck wrote: post #28
bob1029 wrote: post #18

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 situation…

> 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. The reason all the AAA games are on it is because they're on the Windows platform, and more importantly their customers are on the Windows platform. If 95% of gamers ran MacOS…

Are you a game dev?

Re: Microsoft Dependency Has Risks

#232

Post by whatevaa »

gerdesj wrote: post #27
bob1029 wrote: post #18

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 situation…

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

Factorio, with a custom engine and totally not a AAA game company, develops on Windows too, because of great tooling.

Re: Microsoft Dependency Has Risks

#233

Post by whatevaa »

msgodel wrote: post #125
bob1029 wrote: post #18

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 situation…

If you're not doing C++ gdb is pretty good, most people just don't know how to use it.

Game devs absolutely use c++.

Re: Microsoft Dependency Has Risks

#234

Post by herbst »

mrsmrtss wrote: post #227
herbst wrote: post #176

Earlier quoted context omitted.

That's really an insightful answer I enjoyed reading. Really brings me back! I dislike nodejs for the same reasons. But do get the feeling that rust and go, maybe even something more exotic like elixir would be good alternatives as well for your use case. I have barely anything to compare to your requirements tho. I personally would get panic attacks and couldn't sleep anymore if my dependencies aren't open source an…

> I personally would get panic attacks and couldn't sleep anymore if my dependencies aren't open source and I would depend on a company for any reason. But that's just me, it definitely sounds very mature .NET is open source.

To my understanding the "batteries" as in "batteries included" from above aren't.

Re: Microsoft Dependency Has Risks

#235

Post by mrsmrtss »

herbst wrote: post #234
mrsmrtss wrote: post #227

Earlier quoted context omitted.

> I personally would get panic attacks and couldn't sleep anymore if my dependencies aren't open source and I would depend on a company for any reason. But that's just me, it definitely sounds very mature .NET is open source.

To my understanding the "batteries" as in "batteries included" from above aren't.

That includes also all the "batteries" (https://github.com/dotnet).

Re: Microsoft Dependency Has Risks

#236

Post by cyberax »

mrcsharp wrote: post #217
cyberax wrote: post #215

Earlier quoted context omitted.

> 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_ th…

> I have a Dockerfile that contains the build instructions So what's stopping you from doing this with dotnet? Going by your logic, no other programming language reaches your ideal "deployment story" the moment you reach for docker. > Yes, and then my Linux machine that runs the server will happily run a Windows application. With all the dependencies, including the GPU toolkits. Dotnet is cross platform. If you are t…

> So what's stopping you from doing this with dotnet?

Nothing. But then it's not any different from JS+NPM, Python+uv, etc.

> Going by your logic, no other programming language reaches your ideal "deployment story" the moment you reach for docker.

Pretty much. I guess the only real contender is Go. It can easily produce single-binary self-contained executables that can contain other assets, and it supports seamless cross-compilation.

> Dotnet is cross platform. If you are targeting Linux then you can give that information using `dotnet build --os linux` and nuget packages that have platform-specific binaries would then supply the build with the correct binary.

Now do that with Python libraries that do the neural network thingie.

> That's because it is not the job of any programming language compiler to make changes to cloud infrastructure. You know single responsibility and all that.

The brag here was that Dotnet has "just copy it" deployment. And I'm showing that it's not the case, it's "click like a madman for 15 minutes to set it up and then you can copy deployments as long as they don't have anything but .NET code that can work on the target machine".

Re: Microsoft Dependency Has Risks

#237

Post by cyberax »

jiggawatts wrote: post #173
herbst wrote: post #160

Earlier quoted context omitted.

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

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 ha…

You clearly have not worked with in a competent JS-based project. Literally none of your objections are valid except for the single-threaded nature of JS.

Which is also not quite valid, given that .NET has async now, with all the same faults.

> 3) It takes minutes to start! I hope you never have an emergency update that needs to go out right now!

This clearly shows that:

1. "Just copy it" leads to messes that need sub-second deployments. Probably manual ones, because simply spinning up CI/CD and running the tests typically takes longer. Were you responsible for that CrowdStrike outage?

2. My JS project compilation takes 10 seconds from an empty directory to the compiled asset.

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

We're using PNMP and our library resolution takes seconds.

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

It's interesting that you think that not having choice of libraries is good.

I guess that's OK when your worldview has shrunk down to the confines of MSDN, and you can't see anything outside of it.

Re: Microsoft Dependency Has Risks

#238

Post by jiggawatts »

cyberax wrote: post #237
jiggawatts wrote: post #173

Earlier quoted context omitted.

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 ha…

You clearly have not worked with in a competent JS-based project. Literally none of your objections are valid except for the single-threaded nature of JS. Which is also not quite valid, given that .NET has async now, with all the same faults. > 3) It takes minutes to start! I hope you never have an emergency update that needs to go out right now! This clearly shows that: 1. "Just copy it" leads to messes that need su…

“Just deviate from the defaults and then you’ll have a good time!” is not a convincing argument for someone who’s used to being wildly productive… with the defaults.
Post reply on HN