Live data from Hacker News

The Case for C# and .NET

chrlschn.medium.com

171–180 of 376 posts

Re: The Case for C# and .NET

#171

C# and TypeScript seem to be far and away the most popular programming languages today. At least from the perspective of recruiting in Australia. Python is on the way up and third most popular but well behind C# and TypeScript. Golang is on the way up but very small in terms of number of developers. Java is on the way down but will never vanish, it's just not super popular any more. Ruby is small enough to just be a…

Perhaps in Australia, but certainly not worldwide. C# is way smaller than even Go in total, and Java is a lumbering giant. Slow perhaps, but there's no David around at the moment.

Re: The Case for C# and .NET

#172
post #163

I also think that C# and .NET are awesome. Especially latest releases dotnet 6 and upcoming 7 have a ton of new things to be even more productive. I like the fact, that you can develop command line apps, Web APIs, Desktop Apps and smartphone apps all with the same toolset, including the fact that deployment is possible on nearly every major platform for every major platform (except iOS and macOS Apps, as always only…

> that the official repo can only "unlist" packages, not delete them or that the publish times sometimes have horrible delays It's to avoid the npm left-pad problem. nuget.org packages are idempotent. For the publish times, I found out you can cut it in more than half if you tell nuget to ignore caches.

I know... but sometimes it is a bad thing for indie hackers testing around :-)

Draft releases would be awesome.

Re: The Case for C# and .NET

#173

I also think that C# and .NET are awesome. Especially latest releases dotnet 6 and upcoming 7 have a ton of new things to be even more productive. I like the fact, that you can develop command line apps, Web APIs, Desktop Apps and smartphone apps all with the same toolset, including the fact that deployment is possible on nearly every major platform for every major platform (except iOS and macOS Apps, as always only…

About the 'dependency problem': It's not as bad as in npm with node_modules, because .NET provides a lot of base functionality in the standard library. But when you start to use multiple nuget packages, sooner or later you will also enter dependency hell, where managing versions and updates of nuget packages gets very painful. All in all we have to reference about 10 external libraries. The visual studio nuget packag…

Yeah this is probably one of the biggest pain points, but modern tooling is really helping to the tide on this. Dependency management is never fun in any language, and .NET has some quirks which make it a challenge as you say. I switched to .NET from java about 5 years ago now and I'm pretty I !are the switch as .NET just keeps getting better. Dependency management is one of the last pieces of the puzzle to really solve for in terms of getting a much better experience. That said if you're starting a brand new .NET project today you can set up your CI/CD pipelines to do Continuous Deployment and use Renovate to automatically upgrade your dependencies and merge if your tests are green. In addition the trend is for smaller codebases these days which makes it far easier to upgrade major versions of dependencies due to much smaller scope of breaking changes. I think those two things in combination eliminate some of the pain we've all felt with not being able to upgrade several years out of date dependencies in huge monolithic codebases. I'm pretty excited for the future of .NET to be honest.

Re: The Case for C# and .NET

#174
post #5

> For the front-end, JavaScript is unavoidable (for now) Author really needs to give Blazor a try. I wrote some comments last week speculating that I'd use Dart or TypeScript with C# .NET on the client because WebAssembly doesn't do DOM manipulation, but turns out I should have waited to learn it better before making a comment. I've learned I can add events and event handlers to elements without ever leaving C#. Then…

I was really excited for Blazor, until I tried developing for it. The DX is not really there yet and in the mean time I stumbled up HTMX ( https://htmx.org/ ) and now I'm having an even harder time being excited for Blazor. And don't get me started on Blazor Server vs Blazor WASM... The thing is, Blazor will become the lingua franca of (web) UI development for bigcorps, so I just need to suck it up and learn it (I'm…

Its funny, after considering Blazor serverside and WASM, I also opted for HTMX + Alpine.js (when needed) + ViewComponents. Considering how nice server-side rendering story is in ASP.NET, I feel like this is a setup that really works well in a lot of situations, from low-interactivity pages to really complex UIs. It is lightweight on the client side (just load the small htmx and alpine scripts), lets me do much of rendering server-side in .cshtml views, and which needs no JS build pipeline of any kind.

Re: The Case for C# and .NET

#175

Earlier quoted context omitted.

I was really excited for Blazor, until I tried developing for it. The DX is not really there yet and in the mean time I stumbled up HTMX ( https://htmx.org/ ) and now I'm having an even harder time being excited for Blazor. And don't get me started on Blazor Server vs Blazor WASM... The thing is, Blazor will become the lingua franca of (web) UI development for bigcorps, so I just need to suck it up and learn it (I'm…

Its funny, after considering Blazor serverside and WASM, I also opted for HTMX + Alpine.js (when needed) + ViewComponents. Considering how nice server-side rendering story is in ASP.NET, I feel like this is a setup that really works well in a lot of situations, from low-interactivity pages to really complex UIs. It is lightweight on the client side (just load the small htmx and alpine scripts), lets me do much of ren…

This my exact setup and the only thing I’m missing is Blazor-style component syntax instead of the fairly convoluted way with

Re: The Case for C# and .NET

#176

This thread shows there is still a large amount of FUD around .NET and it’s community. Folks here still think it’s Windows-only and comparable to Java. Yet latest TechEmpower benchmarks shows .net running on Linux and being faster than Go, Python, Node, and Rust.

.NET core can run on any platform it wants, but as long as it's from Microsoft, the company as we know it, I won't even write "Hello, World!" with it. A language can't be the fastest at everything in today's mature language ecosystem. OTOH, Debian's "Programming Language Games" benchmarks shows it's on par with Java (which is not slow in any means), and not as fast as you claim [0]. In the page I shared, some C# benc…

Curious, what is it with Microsoft that makes it so poisonous for you that you won't touch anything they make with a ten foot pole? As an example, I'd say Facebook (Meta) is a way more toxic company but I've never heard of a developer have moral arguments against using React

Re: The Case for C# and .NET

#177

Earlier quoted context omitted.

How are collections in C# worse than in Go? In C# you have LINQ, in Go you're writing for loops around array slices.

Maybe I was using it wrong? As I recall, "the usual" APIs present in most other OO languages were not available when I tried to help a friend with a project 3 montjs ago.

You might've forgotten to reference LINQ and Collections.Generic in your project? Because C# definitely has good collection APIs that influenced many languages including Java Streams.

Re: The Case for C# and .NET

#179
post #92

Earlier quoted context omitted.

I use Rider on my Ubuntu machine and the dev experience for me, is even better than using VS2022 on Windows.

Quoted post unavailable.

Rider is free for students and that is how I started using it.

Also, VS Code with OmniSharp isn't that bad for smaller projects for development and is pretty good for debugging for apps of all sizes (my 2 year experience with it).

So to claim that you cannot debug C# on Linux for free is false.

Re: The Case for C# and .NET

#180

Earlier quoted context omitted.

Why would you ever waste time using VSCode for C# when VS and JetBrains Rider exist?

Can they develop remotely on a linux server? Last I checked VSC is the only one that can.

They have a thin client in beta:

https://www.jetbrains.com/remote-development/gateway/

Post reply on HN