> 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.
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
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.
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.
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.
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?
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?
Unfortunately developers who don’t know better judge it by it’s historical association with Windows rather than how powerful it is today.