Hacker News Reader

Comment by flyinglizard | Hacker News Reader

I say modern .NET is a marvel of features, development tools, interoperability, performance and even ships with its own cloud environment (Azure).

Unfortunately developers who don’t know better judge it by it’s historical association with Windows rather than how powerful it is today.

View on HN

> Unfortunately developers who don’t know better judge it by it’s historical association with Windows rather than how powerful it is today.

Some of us actually got to experience the entire journey from the old to new world first-hand. We started out as a .NET 3.5 Framework solution (windows only), and are now looking at a .NET 6 upgrade (any platform). Over the course of 7+ years, we went through all of the following frameworks:

3.5 => 4.0 => 4.5 => 4.6.2 => [netcore convert]

2.0 => 2.2 => 3.0 => 3.1 => 5.0 => ...

Some of the transitions were a little painful, but the same fundamental product survived the entire trip.

I don't know of many other development ecosystems where you can get away with something like this. If we didn't have the stability this ecosystem has to offer, we would not be in business today.

I’m on a project I created in .NET 1 and then migrated to 2.0 (to generics) early on. It’s moved through VSS via svn to git. It has gone from VS 2002 on CD’s to VS2019/2022. It has over 100k commits. Still work full time on it today. I share your experience with the migrations. Never an issue. The new sdk (“core”) style project system was probably the largest blessing of this whole journey.

I actually created a .Net Enterprise app that went on to become an industry leading application.

At the time I was hired, it was to modernize an Access application used internally, to try to sell it as a product.

.Net was still in beta at the time (this was early in 2001). I figured I might as well go with the flow and try it out.

It was a crazy ride, and I've since left the company ... but we went through every version from beta through 4.8 before I left.

I'm now using .Net 5 in Azure to power my new company's REST APIs.

Well, without starting a flamewar (.NET is an impressive runtime), the JVM is better at backwards compatibility, I think.

I can totally see this being a thing based on my understanding of that ecosystem. Java has always been the "runs anywhere" technology.

In the space we work in, a vast majority of systems are written for either Java or .Net

Can you now get the full .NET development experience in a Linux-only environment? I haven't used it in a while, but from using Unity (game engine) it seemed like C# on Linux was a bit crippled

Yes, use Rider and .net core - everything works on non-windows platforms (working on .net from osx right now, deploying to linux)

Avoid vscode for C# development, unlike TS/JS (which is top of the line), the support for C# even in core is toy level.

What do you think is lacking in C# extension for VS Code vs TypeScript? I would expect a better experience with C# (in terms of tooling) because the language is typed.

It just doesn't work nearly as well - even on simple .NET core solutions created from CLI intellisense chokes up, refactoring doesn't work, it's nowhere near the quality level of TS.

Even TS support is pretty lackluster compared to Rider's and VS' C# support.

Yes, JetBrains rider is IMO superior to VisualStudio these days, and I run a huge amount of C# code in production on Linux. It was definitely crippled in the past but it's a first class citizen in the .NET ecosystem now.

Rider is incredibly fast and superior to VS in all aspects but one - its debugger is terribly broken. VS will break on my line of code that crashes. Rider will crash somewhere completely unrelated. My code is very much async, that might be what kills it. I ended up doing everything in Rider, but debugging in VS.

Rider also doesn't allow you to move the current instruction to somewhere else on getting an exception IME.

I'm actually use both. Debugging story in Rider is a bit flawed compared to VS. But due to very large codebase Rider is a bit better in performance.

Also relevant... can you learn it, build it and deploy it for free?

I've always thought the whole ecosystem looked really productive, and the code I've had to review occasionally looked well structured and readable. But when I was starting out MSDN cost a fortune and I've never really considered trying to learn it.

Especially with lsp-mode, C# on Linux (or Mac) is a great experience.

https://0x85.org/csharp-emacs.html

I use Sublime and it works well.

Not really. And the allure of Go over .NET has very little to do with performance.

Most applications I develop these days are web services. I write most things today in Go, but I used to work quite a bit with C#/Asp.NET applications.

Here's what I do to build a Go web application:

  - go build .

What I get out of it is a single, statically-linked, self-contained ELF binary for which deployment is as simple as scp, if I want to. It will run on any x64 linux box, without dependencies, since it contains its own webserver. I don't need to dump it into IIS to make sure the build works.

Here's what I used to do with .NET:

  - Open VS, wait about 30 seconds for it to finally start working
  - Set the target, Rebuild All
  - Publish to file, wait
  - Eventually get a packaging error, predicated on some obscure tools dependency issue somewhere inside my 98KB .csproj file, which I have to fix by closing down VS, manually editing in Notepad, and re-opening VS
  - Finally get a working build+publish, ok, let's take a look
  - Oh, very nice, the publish directory weighs in at nearly a QUARTER GIGABYTE, and contains about 60 dll dependencies and a ton of entirely useless descriptor files.
  - Well, okay, let's at least get this deployed to the test server to make sure it still plays nice with IIS, xcopy this over.
  - Oh, IIS doesn't like this at all, now let's spend the next couple hours tracking down this insane .net framework dependency hell.
  - Screw it, where's my whiskey?

dotnet publish -r linux-x64

Seems pretty simple. Though the binary size is definitely not on par with go.

> even ships with its own cloud environment (Azure)

Can you elaborate on this? What does it mean that ".Net ships with Azure"?

Microsoft created .NET and Azure and a lot of the tooling so the integration is tight, now that it's multi platform and with Rider (multiplatform .NET IDE) being as good as if not better than Visual Studio there is nothing stopping it.

Azure integration is not that great actually. For example .NET 5 support for Azure Functions is a huge breaking change with random issues, missing features and terrible IDE support (you have to launch it through CLI and attach to a PID printed out by the host process to debug a function, you could just debug 3.1 functions) - it's beta quality.

I find this a common theme with Azure support and .NET

I agree, the functions story with .NET 5 is a right pain in the arse at the moment. I understand why it's happened, but I want my .NET 5 durable functions!

Azure functions are one small part of Azure. Im talking about Azure Dev ops for example which is deeply integrated in the tooling. Including source control/product backlogs/pipelines/testing etc.

What does it mean "the integration is tight"? Are we talking about good Azure libraries, or is there some runtime integration (e.g., a .Net orchestrator i.e., Kubernetes but for .Net applications rather than containers)? Or does it just mean that Azure is better than other clouds at running .Net because it's a first-class citizen where it's usually second-tier on AWS/GCP?

Alternative take, the Azure documentation is shit if you are not using dot net... but pretty good if that's your toolchain.

C# was always the better Java, F# the better Scala.

But for many years, the per seat cost was higher, which scared many away

In what way do you consider F# better than scala? Especially with the recently released, revamped Scala 3?

Reply on news.ycombinator.com