Earlier quoted context omitted.
I think he's referring to all of the clicking required on Windows. For example, on Linux, I can create a project folder, files, etc. and open the project all from the terminal. On windows, I have to click into the file explorer, find the project folder, double click it to open it within the browser. So much clicking. I admit, it's probably a skill issue. I've been using Linux distros for the last ~10 years, and am no…
Precisely. The abstraction of knowledge is a cultural staple of that ecosystem. It's great and all, but you end up with developers who have no understanding of what is happening when they click "next next next next yes finish". On Linux, that understanding is a core pillar of the culture. Stark contrasts.
Ask HN: Node vs. .NET Core (2024 edition)
41–50 of 53 posts
Re: Ask HN: Node vs. .NET Core (2024 edition)
#42I used to be pretty excited about node. It’s stupidly cheap to get started and deploy anywhere, using one language for front and backend can be a boon for teams that mix junior talent or folks that just want to reduce complexity and maximize reuse, has a low barrier to entry and wide open community, and was surprisingly scrappy in concurrency, pound for pound.
Coming back to node, I’m fucking miserable, to be honest. The headless community has actually become a liability, where the lack of built-in solutions for essential tasks–particularly the toolchain– has led to something worse than design-by-committee, more akin to design-by-vibes or meme, because the core group is painfully behind the needs of the community and tends to fracture (see bun, demo, etc) rather than evolve. We can’t even decide on a god damned package manager, and all of them are a dumpster fire. Meanwhile your project’s dependency tree is a katamari ball of potential supply chain vectors or abandonware, and all you’ve done is fucking boilerplate a project! Which by the way, will break sometime in the near future and require you to painfully hand roll it back up or go through the expensive and arduous task of replacing.
So, about dotnet. I think the toolchain is good. The core libraries get you most of the way there. You can run it inexpensively almost anywhere these days. C# isn’t perfect but it’s a damned good OOP language. You can squeeze a lot of performance out of it, but even the default, basic approaches will get you far. I worry about the ecosystem as I’m not sure it’s as competitive or desirable as the competition, and I don’t feel great about Microsoft either. But my team expressed interest in dumping node for it and I would take it in a heartbeat.
Re: Ask HN: Node vs. .NET Core (2024 edition)
#43Earlier quoted context omitted.
I think he's referring to all of the clicking required on Windows. For example, on Linux, I can create a project folder, files, etc. and open the project all from the terminal. On windows, I have to click into the file explorer, find the project folder, double click it to open it within the browser. So much clicking. I admit, it's probably a skill issue. I've been using Linux distros for the last ~10 years, and am no…
Precisely. The abstraction of knowledge is a cultural staple of that ecosystem. It's great and all, but you end up with developers who have no understanding of what is happening when they click "next next next next yes finish". On Linux, that understanding is a core pillar of the culture. Stark contrasts.
I see Linux users copy and paste commands into their terminals all the time, sometimes without understanding what they’re doing. How is that different from clicking “next, next, next” in a GUI?
Interacting with a computer using ZSH instead of a GUI isn’t inherently better. It’s just different. Knowing how to run basic shell commands doesn’t tell you anything about a person’s understanding of how computers work.
Plenty of non-technical people can run basic shell commands. It doesn’t mean they understand how virtual memory works, or what DNS is, or how computers store files on disk.
Re: Ask HN: Node vs. .NET Core (2024 edition)
#44Earlier quoted context omitted.
Precisely. The abstraction of knowledge is a cultural staple of that ecosystem. It's great and all, but you end up with developers who have no understanding of what is happening when they click "next next next next yes finish". On Linux, that understanding is a core pillar of the culture. Stark contrasts.
Create react app.
Okay. How about ...
* dotnet new mvc
* dotnet new api
* dotnet new blazor
* dotnet new grpc
I like (and use) Node, but modern DotNet can easily hold it's own.
Re: Ask HN: Node vs. .NET Core (2024 edition)
#45The correct answer is Go
I use Go, Node, and C# (also Python, Ruby, and PHP currently) and the correct answer is there is no correct answer.
The closest you can get is to use what you know.
If what you know can't do the job, then presumably having reached that conclusion you're armed with the knowledge of the missing functionality that lets you do a proper technical assessment of the alternatives with your specific use case in mind.
Re: Ask HN: Node vs. .NET Core (2024 edition)
#46The correct answer is Go
> The correct answer is Go I use Go, Node, and C# (also Python, Ruby, and PHP currently) and the correct answer is there is no correct answer . The closest you can get is to use what you know . If what you know can't do the job, then presumably having reached that conclusion you're armed with the knowledge of the missing functionality that lets you do a proper technical assessment of the alternatives with your specif…
If you’re just building services and you want something that gives you solid computational performance and also runs anywhere you can just use go and solve your customer problems.
Leave the rest to boot camp devs or enterprise sales trapped companies.
Re: Ask HN: Node vs. .NET Core (2024 edition)
#47Earlier quoted context omitted.
> The correct answer is Go I use Go, Node, and C# (also Python, Ruby, and PHP currently) and the correct answer is there is no correct answer . The closest you can get is to use what you know . If what you know can't do the job, then presumably having reached that conclusion you're armed with the knowledge of the missing functionality that lets you do a proper technical assessment of the alternatives with your specif…
It was tongue in cheek. Both .net and node bring a ton of baggage. If you’re just building services and you want something that gives you solid computational performance and also runs anywhere you can just use go and solve your customer problems. Leave the rest to boot camp devs or enterprise sales trapped companies.
Re: Ask HN: Node vs. .NET Core (2024 edition)
#48Earlier quoted context omitted.
It was tongue in cheek. Both .net and node bring a ton of baggage. If you’re just building services and you want something that gives you solid computational performance and also runs anywhere you can just use go and solve your customer problems. Leave the rest to boot camp devs or enterprise sales trapped companies.
go is an all around worse choice that requires more effort and LOC per unit of functionalty
Re: Ask HN: Node vs. .NET Core (2024 edition)
#49Earlier quoted context omitted.
It was tongue in cheek. Both .net and node bring a ton of baggage. If you’re just building services and you want something that gives you solid computational performance and also runs anywhere you can just use go and solve your customer problems. Leave the rest to boot camp devs or enterprise sales trapped companies.
go is an all around worse choice that requires more effort and LOC per unit of functionalty
What matters is quality and maintainability of code, not brevity of code.
I prefer the expressiveness of C# or Ruby, for example, but do a lot of stuff in Go for the clarity/obviousness of the code and the power of the tooling/libraries/ecosystem.
Re: Ask HN: Node vs. .NET Core (2024 edition)
#50Earlier quoted context omitted.
> The correct answer is Go I use Go, Node, and C# (also Python, Ruby, and PHP currently) and the correct answer is there is no correct answer . The closest you can get is to use what you know . If what you know can't do the job, then presumably having reached that conclusion you're armed with the knowledge of the missing functionality that lets you do a proper technical assessment of the alternatives with your specif…
It was tongue in cheek. Both .net and node bring a ton of baggage. If you’re just building services and you want something that gives you solid computational performance and also runs anywhere you can just use go and solve your customer problems. Leave the rest to boot camp devs or enterprise sales trapped companies.
Basically I agree with everything you said there, but with just one amendment - the baggage in .Net was sort of reset not too many years ago with the introduction of Core, and how much you bring into your codebase/tooling is often a personal choice now (depending upon your project) rather than it being forced on you. For example a .Net API can be very clean, fast, free of cruft, and run anywhere from a single binary. A .Net MVC website less so unless you're careful (though I still prefer Razor over Go's default templating).