Is .NET just miles ahead or am I delusional? (old.reddit.com)

So I’ll say that I absolutely echo the post and general comments.

I’ll also say, which I feel is a pariahable comment in 2024, that with 18 years of dev exp through the cycles of Web 1.0, 2.0, everything being a SPA, server-side rendering craze, and then wherever we are now, I just don’t get the hype around React for 95%+ of the scenarios it is used for. It is just so much more harder to get things done, to maintain them, to skill up. The complexity just feels superfluous. Like the Weekend at Bernie’s situation that is “agile methodologies” these days, my gut says this current world of tech must be far more shaped by economic and organisational factors.

By contrast, on face value alone, something like Svelte feels so much closer to how programming used to feel.

It's way ahead has been for some time. I saw it nearly 13 years ago in my internship and have done primarily .NET stuff in the interim. It's only gotten better with age, dotnet core and new features.

There are gaps - data ecosystem is dominated by Java/Scala/Python. Numerical computing is dominated by Python (used to be R!). Microsoft has a decent story in their own ecosystem for the former. Their work on more numerical data types, generic math, and more are what I think is the start of bringing numerical computing to dotnet.

Can't wait to see what the next 13 years hold.

Have worked with .NET for several years and I'm happy to say is an insanely good option, and it's miles ahead of competition when it comes to serving a specifc profile of programmer. UX, APIs, docs, tooling are generally of very high quality. If as a programmer you do not ever want to get involved (good luck getting a change landed), and don't care to understand much of what's under the hood just want to read good docs and get back to your usecase, if you like automation as long as it's written by someone else (how many .NET devs can build a project without VS or even care to know?), if you're happy to confine your dev skills to the inside of a box defined by MSFT, there is no close second option.

C# is great, IMHO. It's one of the main reasons that Unity did so well and continues to be so popular with indie devs even after all their mis-steps, and despite Unreal Engine offering better tech/tools in other important areas.

It completely transformed game development. No debugging of memory leaks/corruption. Far less waiting for compiling/linking (and no header files!). Generics/Collections vs templates/STL.

It's just vastly more productive, enabling tiny teams to do things that would have been impossible if everything had to be done in C/C++. (And if the alternative is not being able to make the game at all, then any performance down-sides are much less of a big deal)

Are we conflating .NET with C# and ecosystem?

My perception is lots of libraries that does serious work are just written in C and C++, in the future I imagine they will be in Rust and not C# - I am talking libraries you get from NuGet, lots of well maintained ones have a C# API that is a shell around something from elsewhere. Be it ImageMagick, lots of media decoding stuff or even proprietary things, like Flir.

It's usually hard to find a library to do some work for you in C#, in NuGet, that is also maintained - you will have an easier time grabbing the sources and adding directly in your project so you can maintain it yourself as bug appears and debug it more easily. A lot of times the bug is the developer assumed everyone uses Windows.

Most of time when using C# I am reinventing the wheel in it because of this.

I also never had a C# project that used it exclusively.

I'm considering using C# and Avalonia for cross-platform GUI application development but what holds me back at the moment is that I find it hard to evaluate how much cross-platform this combo actually is, and how dependencies generally work in the ecosystem. I've read about a dozen different confusing .NET and NET Core versions, and it wasn't clear to me how to find out which packages from the package manager NuGet work on which platforms.

All of it seems to be quite capable, but how Microsoft-centered is it?

Where .NET is today, is where I had thought Java would be many years ago. I think there's something to be said about the consistency of C#'s programming API, design and syntactic sugar, as opposed to the smorgasboard of potluck-yolo interfaces that you're greeted with depending on what you're doing in Java. Linq is an interface that is barely present in other languages, despite being one of the most intuitive; Java's implementation focuses more on trying to say "we aren't C#, promise!" rather than providing a decent developer experience, and furthermore by giving itself a confusing name (Stream... Streams...). A recent addition, I'm glad that Java introduced templating and the design and intention behind it has so much potential compared to other languages, but in the end they've released it incomplete and "left as an exercise to the reader", which I think hurts.

Where .NET isn't so strong is its package management, have a look at the maturity and security of maven packages compared to nuget. Yes, signing packages is a pain and yes there's a bit of a barrier to signing up and pushing your packages up to maven repository, but other languages will learn this lesson over time.

Another area, relevant today, is data engineering. Python has shot ahead of everyone else thanks to its "there's one way to do it" philosophy, and thanks to pandas and its relatives. Just try writing parquet files in .NET and then see how simple and up to date it is in Python.

Comparing web technologies though, well, Javascript development has and always will be a mess compared to any language ecosystem that you choose. You really don't have to try very hard. I think this will be the case for as long as web standards are in the hands of a few large vendors (who assume JS is the be-all and end-all), and the barrier to entry remains low.

Some things like LINQ, Entity Framework and some features of ASP.NET MVC are still unmatched by most of the competition.

The one thing I really miss is the simplicity and productivity of ASP.NET WebForms.

It preceded Prototype, jQuery, PJAX, Turbolinks, Livewire, Hotwire, Next, Remix, Meteor. And it partially accomplished what lot of those only did later, but did so in the early 2000s. And it what was, IMO, a bit more "polished" and "finished" than most of what came later.

It allowed us for making our own components, and had server-side rendered HTML but it allowed for richer interactions, the kind that we needed jQuery for a while, and today we need React components for. It had a vibrant community, but with the downside that it was 100% commercial.

Visual Studio took care of everything we needed, it was indeed just about pressing F5 like someone said.

C# is hard to beat. ReSharper (and IntelliJ) really pushed Visual Studio to have a very high quality developer experience. But I don't miss csproj files, even though they no longer enumerate the contents of the project. Ugh, the conflicts.

It's not difficult being in the top 5-10 inside the lower league.

So I'd bet on "he is delusional". When .NET gets a proper M:N parallel runtime it's when they will even enter the competition. They are not even in it right now.

Golang is miles ahead of .NET and it's far from many people's favorite tech.

Yes, .NET Lang and ecosystem is Miles ahead when it comes to almost everything except perf and fancy projects like kernel/db engine/embedded/fw

I worked across various tech stack lvls - firmware, tools like compilers and web apps

Ive used c#, c, cpp, js and C#s ecosystem was by far most robust and sane to work with

C and CPP's std lib is fucking joke in compare to c#s

Not even Talking about Lang design itself

Id take dotnet cli with built in package manager, compiler, test Runner, crossplat publisher and many more, any Day over anything else

> Professionally I've only ever worked in c# code bases.

Pretty much answered their own question in sentence one.

In my opinion OP is delusional. I worked in .net for 13 years and was stoked to leave. The layers of indirection, obtuse abstraction and over application of design patterns in “idiomatic c#” is preposterous.

Not really, it is a great development experience, but so is the Java ecosystem, note the stress on ecosystem and not language grammar.

Also LINQ that so many on the thread are salivating about, were already present in Smalltalk and Common Lisp collections, were influenced by ML languages and the time Erik Meijer from Haskell fame was part of Visual Basic team.

See "Confessions of a Used language Salesman: Getting the Masses Hooked on Haskell".

Nowadays busy with Scala and Kotlin.

And since I made the reference, Java and .NET IDEs, still don't offer everything that Smalltalk or Common Lisp/Lisp Machines/Interlisp-D were capable of, and yes they also offer stuff that wasn't possible back then.

Miles ahead of what? There is a reason that we write javascript in the browser and operating systems in c or c++, and telco services in erlang, and academic works in python rather than in C# or F#.

.Net is the best at being .Net I guess. It has loads of libraries that are both good and terrible. I think the .Net web ecosystem is a god-awful mess of magic DSL's and configuration, and more and more sugar syntax is being added to C# to make it harder and harder to on-board new developers, and .Net Core deciding to break backwards compatibility is probably costing my org 10's of millions of dollars. But I guess I don't need to type as much as I did 10 years ago.

  [<ReactComponent>]
  let Counter() =
      let (count, setCount) = React.useState(0)
      Html.div [
          Html.button [
              prop.onClick (fun _ -> setCount(count + 1))
              prop.text "Increment"
          ]
  
          Html.button [
              prop.onClick (fun _ -> setCount(count - 1))
              prop.text "Decrement"
          ]
  
          Html.h1 count
      ]

  [<ReactComponent>]
  let ShowGreeting(props: {| greeting : Greeting |}) =
      React.fragment [
          Html.h2 props.greeting.heading
          Html.h4 props.greeting.subheading
          Html.p props.greeting.content
      ]
  
  app.get("/", fun req res next ->
      promise {
          let! response = 
              req 
              |> gql "query { greeting { heading subheading content } }" {||}
              
          match response with
          | Ok response -> 
              let greeting : Greeting = response?greeting
              ShowGreeting ({| greeting = greeting |})
              |> res.renderComponent
          | Error message -> next()
      }   
  )

    cook meat sauce = do
       pan <- getPan
       addTo pan meat
       cookFor pan 10
       addTo pan sauce
       cookFor pan 3
       food <- contents pan
       pure food

«I’ve only ever worked with C# and .NET» «Is .NET better than anything else?»

Wy do I keep seeing posts like this? .NET seems like a religion to some.

Well, the other languages are what .NET would have been too if it only had 1/100th the resources, no dedicated IDE, no first class platform support, and no thousands-strong paid teams dedicated to quality of life improvements and tooling...

IMO the .NET and JVM camps are well ahead of the rest when it comes to ecosystem quality/tooling/support/longevity.

JVM + k8s + PostgreSQL is my current Boring Stack of choice but I think you could be equally justified with .NET.

As someone who has worked with a very wide variety of languages, libraries, and frameworks over my career, I have encountered this and the inverse nearly every time I've learned a new language.

Most languages with some amount of popularity have at least a handful of features that I wish other languages did as well and that can feel, at least in the moment, to be completely obvious and critical features that every language needs.

I agree apart from htmx recreating mvc, I don’t think mvc can do what htmx does but you can certainly add htmx into your mvc or razor pages

Most "new" languages are sponsored by orgs only interested in server side, where UI is done in the browser. Do you think Google cares about doing UIs in Go?

So of course anything made before the browser became the local platform will be millions of miles ahead for developing local applications.

Add to that that javascript libs seem to be done by a bunch of people rediscovering every screw and wheel on their own...

Of Java, the most comparable platform, well yes I would say so. Java is a terrible mess.

> Build stuff in .net is so easy, I just press F5 and I don't even know what happens, it just works

I started out with C# as de-facto my first programming language and this is exactly the thing I didn't like. I had no idea what Visual Studio does and I was lost without it. Later moving onto C and starting from the ground up with just a text editor and a compiler was quite eye opening.

Besides the one mention of Go, he seems to be comparing C# to JavaScript/TypeScript. C# is decent, but the JS/TS ecosystem does not set a high bar for comparison...

I feel this way about F#. It's so much better than C#, I'm constantly missing things from it when in C#. I go back to C# and try to explain the missing features but just get blank stares, because it's hard to imagine a feature you've never seen before.

C# is a fine server-side language, but to be honest it's only gotten there since .NET Core worked on Linux. I still have to work sometimes on crusty old framework projects that constantly break. Every week these teams are chasing down some MSBuild version error, or are dealing with an issue caused by the WCF SOAP endpoints, or some home grown ORM crap because EF was absolutely terrible until recently. So many build errors because the code runs on a windows server that just got patched and for some reason the code won't run.

There's a real toxic cultural effect too. I know plenty of .NET projects that just collapsed because they followed the crowd and designed a complete mess of lasagna. I'm talking 10+ layers just to get a record out of the database and sent to an API. So many classes like "ManagerRepositoryFactoryFactoryImpl". So much indirection with event pipelines and listeners and DI. I've seen an audience give a standing applause to a C# talk where the main point was "more than one function in a file causes bugs, so every function should be in it's own file". There's so many niche cultures that celebrate what I'd call "bad code". And it's hard to buck that trend when a big chunk of your hiring pool has bought into a terrible design philosophy. Not everyone, plenty are wise and see it as nonsense, but plenty have bought into some really weird ideas, see it not work, but then blame the implementation not the philosophy. Then they move along to the next project, brimming with holy zeal to "fix" it with design patterns and event sourcing.

But yeah, today, coming into it fresh, .NET Core is pretty rad. I manage three client projects on it, and it's pretty great. It's really smooth, builds great, is fast enough for CRUD, EF is decent and I can write raw SQL for the 20% of queries that need it. I can autogenerate swagger docs with swashbuckle, then autogenerate my typescript API consumer from that. I've got my code building and running in Linux docker containers and it all just works and it's fast enough for what I need.

But it's forgetting a lot of history and culture to assume it was always this good. It definitely was the worst back in 2003-2014. Keep in mind it used to be closed source and you had to pay through the nose for Visual Studio just to build anything at all! IIS and VSS from 2008 still give me nightmares. Up until about 2020 I recommended people use other tools if they were starting a new project. Today, it's my first recommendation for a backend.

(Also I think Visual Studio still is really lacking in features, so I use Rider instead and it's awesome. But to each their own)

Currently using .NET and ASP.NET for the API of a project that I'm working on, overall it's a pretty lovely experience, especially with the JetBrains Rider as my IDE. Having worked with Java in the enterprise in the past, it feels like a more focused and sometimes more coherent experience (vs the more decentralized nature of Java), that now thankfully runs fine on Linux as well, don't even need to hope that Mono is good enough anymore.

It actually feels pretty close to Java in some respects, for example LINQ and the Stream API are both pleasant to use and let me be pretty productive.

Entity Framework Core is great, the way how they fetch related data is straightforwards: https://learn.microsoft.com/en-us/ef/core/querying/related-d...

I also really like the ability to use split queries, when needed: https://learn.microsoft.com/en-us/ef/core/querying/single-sp...

You can even scaffold your entity mappings from an existing database and manage database migrations separately (which I feel is a must unless you want to pour hours upon hours into learning yet another JPA-like), it's nice when something like that exists in a given ecosystem: https://blog.jetbrains.com/dotnet/2022/01/31/entity-framewor...

Some of the stuff in the ecosystem is also really nice, like using ActionBlocks from Dataflow for simple queues and task scheduling is very easy to get started with and pretty pleasant: https://learn.microsoft.com/en-us/dotnet/api/system.threadin...

Honestly, most of the docs that I've come across are rather pleasant and there's plenty of code examples to be had and even LLMs have enough codebases out there to be trained on and give decent output, in addition to the regular autocomplete in the IDE.

Even some third party stuff like CsvHelper is really well put together: https://joshclose.github.io/CsvHelper/getting-started/#insta...

That said, I've had issues where trying to deserialize incoming JSON requests ([FromBody]) lead to the whole object being null, due to it not matching the fields 1:1 or violating some nullability constraint, however that happened without a clear error message or as much as a warning in the logs, which felt insane and wasn't very discoverable. Now I just use JObject as the parameter and deserialize at the top of the controller method.

I've also run into some ecosystem issues where the OpenAPI codegen was a bit lacking and wouldn't actually generate code that works, but maybe that's because the spec was bad: https://openapi-generator.tech/docs/generators/csharp

I could also not get AutoMapper (https://docs.automapper.org/en/stable/index.html) working satisfactorily, so for now I'm stuck writing mappers by hand with said autocomplete sometimes doing it for me. There were issues with the runtime being unable to register the mappers or something like that, it was a while ago. Over...