Live data from Hacker News

The Case for C# and .NET

chrlschn.medium.com

271–280 of 376 posts

Re: The Case for C# and .NET

#271

Earlier quoted context omitted.

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…

Did you really mean only 10 external libraries? If you'd said 100 I could understand - I hit a version conflict issue in a recent project on adding what was probably package #60 or so, but solved it easily enough after a bit of googling. And we knew we were using a lot of quite old packages (including .NET 2.1 EF, because of a rare breaking change they introduced with 3.0 that we didn't have a good solution for).

Technically just 2 libs are enough to produce the issue...

Re: The Case for C# and .NET

#273

My understanding is that with .NET Core, the experience of developing and running on Linux is on-par with Windows(?). However, my impression is that once it comes to building web services, ASP.NET has more "windows-specific" assumptions/moving parts - can someone knowledgeable on this correct me if I'm wrong?

Any .NET NuGet packages targeting .NET Core/.NET 5+ without the -windows TFM will run on any platform that CoreCLR runs on. ASP.NET 6 is no exception. There is nothing Windows-specific in there any longer, and there hasn't been for quite some time. ASP.NET now runs by default on Kestrel, Microsoft's cross-platform web server.

You can also use the .NET CrossCore assemblies (available since .NET Framework Core 4.777.2.1) and do multi-targeting for ASP.NET Core (the Framework version of ASP.NET Core, not the Core version which since version 5.0 is incompatible). Using ASP.NET Core 6 (the new name of ASP.NET 4.2) you can also target Linux if you compile with the flag /fuckallthatshit

Re: The Case for C# and .NET

#274

Earlier quoted context omitted.

I think for swagger documentation you install the swashbuckle nuget package and then add these three lines services.AddSwaggerGen(); app.UseSwagger(); app.UseSwaggerUI();

ASP.NET configuration is one of the most arcane parts of .NET that I don't like. You have to perform the incantation thrice: add package reference, add service reference, invoke the builder extension. And there's the right order and the wrong order of invocations, and if you pick the wrong one, your app silently won't work correctly.

Arcane? What did you expect? Add a package and magically everything works? If you make it work by just adding a reference its “too much magic”, if you make it so people write everything “it’s boilerplate” and if you do something in between “its arcane”.

Re: The Case for C# and .NET

#275

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…

Right now if I type the following keywords in Seek this is what I get (in order):

  SQL - 11,425 jobs
  Java - 7,390 jobs
  Python - 6,777 jobs
  C# - 4,995 jobs
  JavaScript - 4,208 jobs
  TypeScript - 758 jobs
  Ruby - 252 jobs
  Golang - 206 jobs

Re: The Case for C# and .NET

#276
post #257

The thing I miss the most with C# and dotnet is offline documentation. With Java, I can install the java-17-openjdk-javadoc package and have the full API reference (at /usr/share/javadoc/java/index.html), and download a couple of PDF files to have also the full language and bytecode specification. With Rust, I can install the rust-doc package and have the full API and language reference (at /usr/share/doc/rust/html/i…

I use Zeal documentation browser and it has most of .NET docs available offline

Re: The Case for C# and .NET

#277
post #237

Just use F# instead and you will have Rust, typescript, Javascript, dart, python all at once https://twitter.com/FableCompiler/status/1550429007443017729...

Unfortunely not with same tooling level as C# and VB enjoy.

Rider has pretty decent F# support. Maybe not that many refactorings available, but it's IMHO worth it for the better language ;)

Re: The Case for C# and .NET

#278
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…

With blazor you need to choose Client or Server Blazor. Client will give you 10MB+ page downloads, Server will require stable and low-latency internet connection. It's fine for intranet systems, but not for general webdev

Re: The Case for C# and .NET

#279

Earlier quoted context omitted.

I've been a .NET developer professionally for seven and a half years. Rider is the way to go. Visual Studio has improved dramatically over the last decade or so, but Rider is still way ahead of it on code search/discovery, performance, and general user experience. I did a tech talk at my company where I demoed Rider vs Visual Studio 2019 performance on our bigger projects... it was embarrassing for VS. VS 2022 was su…

Rider does not have a community edition unlike IDEA. It was created due to a combined threat of VS Code and Roslyn and is the reason ReSharper is almost neglected these days.

ReSharper isn't a heavy focus because it's not worth it anymore. To get the same performance as other tools they'd need to throw out a ton of work and rewrite it for Roslyn. With Rider, they get to continue to use their existing ReSharper codebase to power it.

Re: The Case for C# and .NET

#280
post #30

I wouldn't lose a second to C# or any MS platform unless required for employment reasons. https://github.com/OmniSharp/omnisharp-vscode/issues/5276

Sorry, but OmniSharp sucks, and this is not a controversial opinion even among Microsoft employees. I am all for the .NET experience in VS Code improving greatly from where it is with OmniSharp. This will actually help increase adoption of .NET, which, I remind you, is open source.

Yes, but it works and it's open source. All the other languages have open source tooling (LSP or similar), why can't we have one for C#?
Post reply on HN