dotnet tool install --global dotnet-ef --version 8.0.8

Edit. I was not aware that the gap between System.Text.Json and Newtonsoft narrowed, take my comment with a grain of salt, please!

Yes, a lot of great features have been added over the years. But it also introduces some amount of cognitive load and confusion. Take the first new feature in the example:

> Field-backed properties simplify property declarations by eliminating the need for explicit backing fields. The compiler generates the backing field automatically, making your code cleaner and more maintainable.

Huh, I thought we have had this for years, what were they called, ah Auto-Implemented Properties- so why is there a need for this? In this example:

  // Automatic backing field with custom logic
  public string Name
  {
      get => field;
      set => field = value?.Trim() ?? string.Empty;
  }

  get;

I feel like the documentation is always somewhat lacking in explaining the reasoning behind new features and how it evolves the language from earlier versions.

Since Nadella took over, MS made some substantial steps forward: On Azure, around 30% is Linux; MS went cross platform with some of its most successful apps/ecosystems. Its not that MS behaving like a friend today, but their Dev-tools are really great - at least they care for Devs, i wish they would care for Office users as well.

C# + .NET is from my perspective the most developed and most mature eco system when it comes to business applications.

I really like it!

Those older stuff are likely running newtonsoft.Json anyway.

There's also a load of .NET Framework applications still running Newstonsoft.

Because there's a boatload of older .NET apps that have been using Newtonsoft for over a decade already and aren't in a rush to switch. Anything built on .NET Framework is likely to still use Newtonsoft.

https://learn.microsoft.com/en-us/dotnet/csharp/whats-new/cs...

    const [a, b] = await Promise.all([fetchA(), fetchB()]); // => a: A, b: B

I haven't tried it because it has generally seemed easiest to use the new attributes. Though a large part of that is the shift from the WCF-era "opt-in" approach of DataContract/DataMember [0] versus the "opt-out" JsonIgnore approach where most of the transition is deleting lines because JsonIgnore is the exception rather than the rule. You could even keep DataContract/DataMember during the transition and just take an additive approach for JsonIgnore.

[0]: It was a good idea, in theory, but so annoying in practice.

Go and Rust produce native binaries, I wish C# had an official native compiler without the big runtime needs of .Net.

It's a force multiplier when you have a small team of strong developers.

And when the front-end is C#, it only makes sense to do the backend in .NET too so you can share classes easily.

C# is extremely popular in Western/Northern Europe. (Sweden/Denmark/Germany ironically in particular).

These are real Microsoft strongholds.

So much DDD-this, Clean-that, CQRS-this, architecture-that.

I get all that stuff is for enterprise with bigger teams. But there wasn't much content/guidance on how to build apps 'quickly' for startups.

I am sure experienced .NET devs know this, but less experience .NET devs don't.

I ended up dropping it because I could work faster in PHP.

Too hard to ignore the benefits of cross-stack gains in Typescript/Python. The C# native phone, Blazor, etc just isn't quite there yet. Tried it at the last company, and full stack TS was just so much easier to do.

The reality is that the vast majority of startups don't make it. The #1 thing startups should be focusing on is hiring the right people and product velocity. TS just makes that easier in my experience.

For me C#'s value is obvious in the frontend and also games compared to Java (except for mobile, where Java can be used but Kotlin seems best).

But for the backend I always wonder if I should invest more on C# or Java as I go.

Also, it worries me that Java is a memory hog, which C# seems not to be. I like to have lean server-side software, to the point that my usual approach has been to use C++ paired with Capnproto, but if I had to go with something a bit more high-level for web work, I am not sure.

Currently I am investigating Clojure for non-critically-fast backend. It seems to be a lot of fun and since I am using https://fennel-lang.org/ (replacing part of my Lua code) and I expect https://jank-lang.org/ to become something at some point, maybe it is worth to stick to it?

How would someone that has more data than me compare Java vs C# in terms of performance as-in "what machine you need in the cloud" to do useful stuff, mainly for backend work, asynchronous, in terms of CPU and memory for both?

I can say that it has gone waaaaaay smoother than anyone would have thought. This is a decision (language switch) that the team has been putting off for a long time and simply suffering through some big time jank and complexity with TypeScript (yes, TS at scale becomes complex in a very different way from C# because it becomes complex at the tooling layer in an "unbounded" way whereas C#'s language complexity is "bounded").

Indeed, I think more teams should give C# a shot. My own experience is that C# and TypeScript at a language level are remarkably alike[0] that if you know one well, you can probably quickly learn the other. But the C# ecosystem tooling is more cohesive, easier to grok, and less fickle compared to JS/TS (as is the case with Go, Java, etc. as well).

There still remains a lot of mis-perceptions about C# and .NET in general and I think that many startups should spend the time to give EF Core a shot and realize how every option in JS-land ends up feeling like a toy. EF Core itself is worth the price of admission, IMO.

[0] https://typescript-is-like-csharp.chrlschn.dev/

same as c# - seems asp.net comes with a lot of stuff - but to use that stuff a lot of ceremony is baked in.

with Ruby | Rails i'm one or two commands away from most things I need. I understand the language & the ecosystem.

I personally won't be using it, given the choice, again. I don't like exceptions, but can live with them. I don't like null, but can live with it. Nuget is complete and utter garbage. You still have to resort to all forms of unreliable hacks in order to redirect it to a locally clone (and if you do use a feed to avoid that, good luck with getting the local cache to not be completely moronic).

(Look, it certainly didn't help that the project itself was heavily enterprisey because the developers hadn't kicked those habits)

There's that, but there's also the developer experience and functionality for people to run it on Mac and Linux.

We have a small C# service that we run locally via Docker (which I think is usually the optimal setup anyways) and develop with VSCode. Since it's small, it has worked well. Would it work well if that was our main backend? Not sure.

Wish I had the option of full Visual Studio on Mac for it regardless.

I expect the baker who sells me his bread pays for the flour.

My comment is NOT talking about 'decent C# devs'

It is a RESPONSE as to why more people are not using C# for startups. For those who are not familiar with C# MAY be put off using it for those reasons... and why another language might be used.

People who already are familiar with C# know this. To programmers that do not, may prefer to stick with another language to keep away from Microsoft in general.

Again - my comment is a response about why C# is not used more for startups. I am not suggesting it isn't, but there are plenty of reasons, and this is likely just one.

Rest web api will be migrated.

Razor — also.

The oldest version of .Net I could find on Windows 11 was .Net 4, but it still compiles just great without a project file since it has since v1:

https://www.youtube.com/watch?v=KmIwGxcMOLg

[1] https://devblogs.microsoft.com/dotnet/dotnet-sts-releases-su...

It's probably a good thing because far from your "secret sauce" so much programming work is companies doing the same very boring things over and over connecting pipes together and making extremely similar design decisions for mundane tasks.

I’m partly convinced now! I still worry a bit about property authors who don’t follow the “cheap, non-side-effectful, externally cacheable” rules, though. Perhaps there are linters in property-ful languages which would help with that.

Similarly, I'm not a fan of "Enterprise" development regardless... I find a lot of .Net shops, like Jave, just create a lot of layers of indirection and abstraction that only lead to excess complexity, cost and difficulty in both maintenance and enhancement. The older I get, the more my mindset shifts to make things that are easy to replace without adding undue complexity or patterns.

Especially when even its advocates somehow use that as an "upside". It might very well be for a lot of people! But it's also a massive turn off for others. I have never worked in a startup or big tech, and work on very concrete and critical products yet I'd very much rather work on even outlandish SV stuff (at least the pay is usually great and the job environment could be good!) rather than on some SMB CRUD or some generic backend service. If I don't have a choice I could do it but it's not super enticing.

† And Neovim occasionally, but I mostly use it for Typescript or anything that isn't F#/C#.

‡ https://github.com/nozzlegear/shopifysharp

There are so many things that are like this in the .Net ecosystem.

Yeah, it runs on Linux. Kind of. Mostly.

As long as Microsoft is at the helm, I don't expect that to change.

https://learn.microsoft.com/en-us/dotnet/core/diagnostics/de...

— We haven’t found the source for this story yet."

From https://blog.jetbrains.com/dotnet/2022/08/03/happy-5th-birth...

Ironically dotnet runs better on Linux/Mac systems in my experience. All our devs who use Windows for dotnet dev now use WSL2 as it matches production. We don't use any other 'commercial' Microsoft products like SQL Server or Azure. All postgres/redis/etc and deploy onto docker containers.

Again, my comment is focusing on someone on the outside looking in.. and WHY people end up making decisions away from C# in favour of (something like) Go.

I am aware of deploying to Linux containers, etc.

The overhead argument seems fairly objective to me - clean code with low coupling in C# et al. requires separate definitions of interfaces and implementations, explicit conversion methods between compatible interfaces etc. This adds up over time and makes refactoring pretty annoying.

The tight coupling happens when people don't bother to define interfaces. Suddenly I have to couple class hierarchy to classes from unrelated modules, all so the compiler is happy when I pass structurally equivalent data. To keep my own modules clean I have to add yet more interfaces, conversion methods etc!

Then if you have the chance, you'll find C# an easy transition from TypeScript, IME. Learning C# first, on the other hand, will make you a better TS developer, in my opinion, because it will shape your approach to be more diligent about using types. This is something most JS/TS devs do very poorly and at scale, it's very hard to reason about code when it requires digging down several layers to find the actual types/shapes.

"Enterprise" frameworks like Nest.js are much more similar to ASP.NET or Spring Boot than they are to Express, Hono, or Elysia so once having experience with .NET Web APIs (or Spring Boot) will make Nest.js (for example) easier to pick up.

They are created by the same person but they are very different in my opinion.

TypeScript is "a tool" for JS, it is possible to compile without errors but still fail in runtime (e.g. wrong object type returned from API), on the other hand parsing JSON with C# will give you correct object type, it may fail if some properties are missing but it will fail at parsing call, not further down when you try to use missing property. In other words typing is not glued on top of the language it's core of the language.

The main issue with EF is ultimately there is an expression builder that maps linq expressions to sql. This mostly works, until it doesn't, or it does but has strange generated sql and performance. If all you are doing is CRUD or CRUD adjacent then it's fine. But for some complex stuff you spend a lot of time learning the innards of EF, logging generated statements, etc. It is time better spent writing good sql, which something like Dapper allows.

C# has come a long way in the last 10 years. This much is clear, providing better support outside of the Windows ecosystem. However, many outside of the Windows/Microsoft ways are likely to be using languages like Go.

> What are you talking about C# being tied to Visual Studio? This is 2025 not 1995.

There was no C# in 1995. (See it's easy attacking a sentence)

> Just install

Not on Debian? Have fun with that. You'll also need the Azure SDK. And what about openssl-dev? Oh no, you installed dotnet on Windows instead of within WSL? Start again.

No, you don't "just install" the SDK. There is a lot that the IDEs set up for you.

> Local nuget.config

I don't see how adding a nuget config improves anything. You have completely omitted what you place inside of it to make it build and use a local clone of the package source.

Look at all this nonsense that people have resorted to: https://stackoverflow.com/questions/32482746/how-to-temporar...

You will still need to integrate Vite somehow to use modern CSS, TS, etc. And if you do that, why even use Razor to begin with?

Also, hot reload is garbage. C# will never get close in speed or features to something like Vite.

Office Space took place there before the dotcom bust.

Less enterprisey, but John Carmack and id Software also started there.

Npm has tons of libraries, but they're mostly abandoned. Many barely worked in the first place. And if they're even a little out of date, there's a decent chance they're missing TypeScript types or they won't work with your module system. It's a nightmare.

Struggling with missing or broken dependencies is what made me swear off Node backends permanently.

https://www.npmjs.com/package/is-even

Java was originally Sun Microsystems.

However - if Java was Oracle to begin with (and as successful in the mid-90s) then might have done some marketing for the Java+Oracle mix.

Some people (ie Managers) if they decide on using Microsoft products will likely "encourage" the use of C# and .NET. -- That is an example of C# + Sql Server.

If a business is turning away candidates because they "don't have n years of experience in x" that doesn't sound like a very dynamic/interesting place to work, it sounds like a code monkey job. AI is going to eat code monkey jobs.

Also the DX is just not there. Hot reload is a mess. Even when it works it's too slow. Once you start using hot reload with Vite you can't go back to waiting seconds for every change and full page reloads.

> Compared to what?

Everything else?

Do you think it's acceptable that it took 4 years for Minimal APIs to get validation?

What about hot reload being broken for years and years?

It's a lot easier when you have a single shared library you can just NuGet into both sides, client and server and then use the same correctly typed PlayerDTO for both.

While Blazor has some cool stuff built in, the cool stuff never felt worth the risk of building a product around it.

Further you go away from that circle, the less enticing it is.

That being said, I'd much prefer to deploy a C# application over Node or Java, no argument there. But saying "I wish more startups were using C#" makes me wince. C# seems well-suited for the monolith-architected VM-image-deployed strategy of the early 2000s, but it's pretty close to being the exact opposite of modern best practices. And unfortunately it's kinda unfixable in a language that depends on a VM execution environment.

I'm sure all this is short-lived however -- I'm relatively confident we'll see deployment best practices converge down to "use whatever language you want but you must compile to WASM" in the next decade, so the warts of devs' chosen language aren't an ops problem anymore.

VSCode gets you 90% there.

But IMO Rider gets you over 100%.

Obviously. IME it is better than Visual Studio.

> But yeah, the coding/refactoring support (Resharper et al) and general quality and integration of tooling (database tools, package managers, version control, debugging (esp. multi-process) etc.) is the big one for me.

I rarely use any of these tools tbh. I just want Resharper and something that works reliably on Linux. I would transition to using vim entirely but half the vim stuff I like using I can't use with Windows (work is never not going to use Windows).

Java doesn't have extension methods and while both are decent languages, C# is the one that likes implementing every conceivable language feature immediately, while Java takes a while to design a bigger feature that will replace several smaller ones' use cases.

I'm not inherently against it, we have a problem with opensource being asymmetrically underfunded and if people going commercial is the cost perhaps we've failed.

Publishing your app as Native AOT produces an app that's self-contained and that has been ahead-of-time (AOT) compiled to native code. Native AOT apps have faster startup time and smaller memory footprints. These apps can run on machines that don't have the .NET runtime installed.

You literally started with "Java takes a while to design a bigger feature that will replace several smaller ones' use cases".

But look, this small feature is not a one-off, and is actually useful because <arbitrary arguments>

> Meanwhile records arrived several versions ago

> Meanwhile C# has many many "one-off" features

Such one-off features like records and pattern-matching that C# also has? Or multiline strings that C# also has?

Or any other useful features directly impacting developer experience that you just dismiss out of hand because for some arbitrary reason you deem them "one-off" or small. Until they finally make their way into Java of course.

1. The overall architecture (with the JVM) made it slower than the equivalent C# code.

2. C# really started embracing modern language features at a time when Java was kind of languishing (lambda functions, async patterns). Java seems like it's been in perpetual catch-up since then.

(Not OP, disclaimer, I work for Microsoft and this is only my opinion).

Java is fast and reasonably safe. It has a lot of software (especially OSS) software. Its package system (Maven and the like) is ok, but not great. The language occasionally gets new features, but change is slow.

To a first approximation, C# is a lot like Java, so it is relatively easy to switch. But C# is, hands down, a better language. The most obvious thing that a developer might notice that that C# does not force you to be extremely verbose like Java, although you can code in the Java style if you like.

Having switched my course from Java to C#, the most obvious "win" was the fact that, every lecture, I would delete some slides that explained painful Java corner cases to students. For example, Java's implementation of generics. Boxed types are necessary, and explaining them to students who have never seen any form of polymorphism before is difficult. After an entire semester of deleting a handful of slides each lecture, I have save _three entire lectures_ worth of corner cases!

Some C# niceties:

* Everything is an object, even value types! So our favorite `ToString` and `GetHashCode` methods, etc, are all there. * Generics work as you would expect with very few weird corner cases. No boxed types because... everything is an object! * The last two facts mean that you also get generic arrays, which are fantastic (and, incidentally, are also _implemented_ in C#, which is super cool). * By default, reference types are not nullable. This is a little bit of a pain for an intro data structures course (we turn them off), but it is a great idea for commercial programming. * switch statements work the way you would expect a modern switch to work, and in some cases they even do exhaustiveness checking like a functional language. * Speaking of... LINQ! * In general, the standard library is also better organized. Interfaces start with "I". Collections libraries have been carefully designed and learned many lessons from Java. A good example of an improvement over Java is the IEnumerable<T>/IEnumerator<T> class, which is simpler than Java's Iterator<T>. * Type inference is limited compared to a functional language, but it is dramatically better than Java. Being able to write `var` is wonderful. * Properties are really nice, and the shorthand syntax for property getters/setters saves a lot of time. * C# has a rich set of value types, including structs. Java may have added something like this, since I remember the Scala people hacking away on it, but it is used pervasively in C#, and you can make very fast data structures that take advantage of spatial locality. Rolling one's own hash table implementation in C# is actually kind of fun. * .NET's runtime reflection capabilities are amazing. All of my autograders make extensive use of reflection instead of forcing students to compile with interfaces; this gives them a degree of freedom in implementing things. * NuGet is a million times easier to use than Maven.

The downside is that C# is definitely not as fast as Java, in particular when the runtime is starting up. I remember how painful Java startup used to be, so I am optimistic that this will improve eventually.

Anecdotally, my students this semester are demonstrably more capable programmers after a semester of C# than a semester of Java. It might just be that I got lucky with this group, but I have been teaching this same course (except in Java) for the last 7 years, and this feels like a real effect.

Does Java have real generics yet?

It is rarish to find a partial MS shop. Most of this is how hard MS makes it to use other tools. Even in 2025 they have good interop with external tools hamstrung.

Example: SQL Servers JDBC driver will convert an entire table's of data from ASCII to UTF and a full table scan instead of convertering your UTF bind to ASCII and using the ASCII based index. This doesn't break interop but does make it painful to code and one more reason to just use .Net.

Some Microsoft stuff is really good but it's not universally true. And in the worst cases you end up locked into some hard to migrate off platform that is withering on the vine.

1. Process, process, and more process. Doing anything required layers of management approval. Trivial tasks become month long, or even years long, processes.

2. You have no power or agency. Something is broken? You're a developer, you should be able to fix it right? No. Broken things stay broken. You swim in your lane and keep your head down. Mediocrity is the goal.

3. Optimization doesn't exist. If a process is manual and takes you, a developer, 10 hours, then that's what it is. Nobody gives a flying fuck about tooling. Nobody cares if you spend 50% of your dev time doing random stuff. And if you even dare try to fix it, you will be told it's impossible and you're wasting your time.

4. Management is king. You will have to lie to them. You will have to spend time re-entering the same data in 5 different places so they can read it conveniently. You will have to make Excel workbooks. You will have to dumb things down, and then dumb them down again, and again. Everything is about Jira... Unless they're a really high up manager, in which case you have to take whatever is in Jira and put it in a word doc and send it to them, because they don't know how to open Jira.

What was the last Java version you used? There has been a huge momentum in adding new features lately, granted, it is slower than in C# (Java's top priority is backwards compatibility, so it does not have the luxury of shedding old stuff or changing them once they are in), but in the last couple of years it has improved tremendously. The JVM (especially in the garbage collection front) but also the language - half of an ML-style language is there (for example, ADTs and pattern matching), the other half is coming soon!

That's not the case anymore. Kestrel is one of the fastest servers there is, and it beats every Java server out there.

That’s a radically different proposition than, say, raw OCaml and not particularly niche. It also impacts hiring pools differently since competent functional C# devs are viable, but it tends to appeal to a certain calibre of dev.

Moving faster with fewer errors and more talented candidate pool are relevant to repackaged SaaS startups too. Leaves more time for the other stuff and scales better.

We have access to millions of libraries. I look at BEAM languages and OCaml every once in a while but can’t quite drag myself over there, knowing that in .NET, just as an example, I can choose between a dozen JSON serialisation libraries that have been optimised and tuned comprehensively for decades.

But then, those libraries are also our curse. If you consume them, everything is OO so you either give up on functional purity and start writing imperative F# code, or you have to spend time writing and maintaining a F# idiomatic wrapper around it.

Similarly I was working recently on project to develop a library which was going to have downstream consumers. The problem lent itself really well to domain modelling in F#. But I knew that my downstream users would be C# devs. I could invest the time and write my library as “functional core, imperative shell”. But then I decided that since the interface would be OO anyway, I might as well just write it in C#.

Thankfully what keeps F# going is the wonderful community around it, not Microsoft. I know some people (outside of Microsoft) have worked on a standalone F# compiler but it’s still very early stages. Maybe one day.

This is absolutely not my experience, especially when it comes to the ecosystem and third-party libraries. Like Java is pretty much the best in this category.

Well they pulled back but the trust was broken in a lot of cases. I am still fine with it 'for now' but IDK NSubstitute always feels weird to me, maybe that's just how I was taught to use it tho.

> Masstransit went commercial recently

I mean good for them but thankfully it's also giving attention to other projects that are FOSS or Open Core...

As far as the other stuff, I've never seen AutoMapper used in a way that couldn't literally be handled with a static/extension method in 'real' code. Yes it can be useful but it is often grossly overused.

MediatR is cool but TBH I'd rather just reach for Akka.NET or MessagePipe instead; If you're abstracting out to keep processing backend 'swappable' you should be able to handle any of the above for the choice you make anyway.

ASP.NET is the web part, no?

Before that, years ago, I just YOLOed with WebSharper and built composition helpers to make 'spartan but correct' UIs that could be prettied up with bootstrap if needed.

That said, alas, Bolero (what replaced WebSharper) is F# specific rather than also supporting C#.

I mostly bring those up because they have various libraries out there to work with different JS bits.

[0] - Cries in webforms

On the dotnet side, both Oxpecker and Giraffe (Giraffe being written by the author of that post) perform very well with simple code and from what I see, no "tricks". It's all standard "how the docs say to write it" code (muuuuch different than those platform benchmarks that were rightfully scrutinized in the referenced blog post).

On the jvm side, I started looking for a reference near the top without any targeted non-default optimizations (which is really what I personally look for in these). The inverno implementation has a few things that I'd call non-standard (any time I see a byte buffer I imagine that's not how most people are utilizing the framework), but otherwise looks normal. I recall an earlier quarkus implementation that I read through a couple years ago (same repo) that wasn't as optimized with small things like that and performed very well, but it seems they've since added some of those types of optimizations as well.

All to say: If you venture outside the standard of either platform (full fatty aspnet/ef or spring/hibernate) you can make the tradeoff of framework convenience for performance. However when it comes to the cost/benefit ratio, you're either going to be joining a company using the former, or writing your own thing using the latter (most likely).

...

>> sure maybe you have some data science people who need python,

This is how it happens though; it's not "let's form a company with 10 developers; don't worry what tools they use!". It's starting with a single problem using common tools, then adding specialized problems where you could still use the same tools but they are not optimized, then adding an acquisition product that uses different tech, then growing to 100 or 1000 developers and may all use React or C# (doubtful) but don't use it the same way...

>> If you're going to make a change then migrate everything

Have you ever worked for a software company before? THis is not how it goes.

And all the 6-month-old on-line docs and tutorials aren't only useless, but time wasting.

This sounds very close minded to me. It is certainly true that there exist tasks if not subdomains where some ecosystems are better than others. Using a hammer for everything might work for you if all your problems are nails. But that doesn't mean that all problems out there are nails

Spring is a de-facto extension of the core java libraries and alternatives like Quarkus follow the same mental model with a better technological foundation.

I'm talking about general software development and web dev in particular. There's a trend where you'll see one org has or web app using .net ad react, another using next.js, another using Java and Vue, one djnago and htmx, and so on.

And there is literally no reason for any of these choices, they're all fairly basic web applications that could have all been made in literally any half decent web stack. So whether the devs who made these choices knew or not, they made them based on preference not any kind of reason or need, they're all nails and any hammer would have done the job just fine.

Working there you aren't building the next Google, you're probably maintaining a some 20 year old order-to-cash ERP process that's boring, but critically important to the business, and is exactly the software you don't want to move fast and break.

Just don't go work for big enterprises if you don't want that environment. It won't matter what language/tech stack, it's just big non-tech company things.

But there's plenty of us out there that don't mind those jobs. Pay can be good enough, and usually offer great work-life balance. I work IT ops for one. I'm remote, I put in my 9 to 5 and I'm done. I'm (thankfully) not on call, I get unlimited PTO, and my personal time is 100% my own to go do non tech things with.

But most developers are pretty bad. I see a lot of developers who hardly do any work at all, and many who do lots of work but it's all trash. Buggy, overcomplicated, untested, dumb pointless decisions.

Like my current project. Two guys started it - .NET backend, React frontend. Sure, fine. But let's use Azure functions for the backend instead of a regular web api. What. We asked them why, no reason. And their whole codebase was trash, I've deleted about 90% of the code that they had written and I'll delete the rest too.

I've also been in a team that had the problem I highlighted in the OP. 20 different apps, 10 different JS frameworks etc. Speaking as someone who worked on these apps, there was absolutely no reason to choose one JS framework over another. I could have made them all in React no problem, they're just websites, not much more than glorified PDFs. How you generate the html is irrelevant. And the code was mostly trash. Overcomplicated, buggy, untested etc.

I did struggle with this early in my career - am I just a narcissist? Everywhere I turn the code is just trash, maybe I'm the problem? But now I've worked with people who do good work. I've seen my own ideas work in practice. I know for a fact my judgement is good.

In university I was the one who helped everyone else. I was always ahead, while my peers could hardly keep up. When we graduated a lot of them would have struggled to solve fizzbuzz in 20 minutes, yet we all have the same degree. No wonder there's so much trash code around.

I am pretty language agnostic and I am reasonably competent programming in C# (I worked with C# and VB.NET for about 15 years), Go, Python, TypeScript and C++ these days.

The issue with a lot of places that do C#/.NET stuff is that they will typically ignore new tech until it is officially blessed by Microsoft. You can have a piece of tech that everyone is using and works really well and it will be ignored if it isn't blessed by Microsoft.

The other issue with .NET is all the Microsoft gumpf that tends to come with it even with the newer versions of .NET.

I am also in the weird place of being a Linux user. I've had job interviews that wanted to do live coding exercise/take home code exercise and they expect you to do everything in Visual Studio with SQL Server.

As someone who has been developing primarily on .Net for the past decade this is absolute bullshit.

1. It’s only very recently that .Net became open source. Until then you would frequently hit issues where the only option was to rely on the few support calls you got with MS engineers with your $1000+ Visual Studio subscription to move forward. And believe me, this isn’t a pleasant way of debugging. 2. It’s only recently that .Net became cross platform. Until recently .Net meant you had to pay far more money for windows servers, get far less performance, and open your application to way more security issues. And when things broke they broke in highly inscrutable ways. 3. It’s still not a great platform. If you’re deploying on Windows, there are still things you will want to do that will require windows registry changes. 4. It’s only recently that the transition to an open source/cross platform framework has stabilized. Until now you had to deal with MS alphabet and naming goop, an absolutely muddy roadmap, and if you ever got thrown into a project you’d end up finding yourself in a mess of varying conventions, project types, incompatibilities, etc. 5. You know all those performance improvements they’re delivering with every release? There’s a reason for that. Until recently performance was so bad. Kestrel alone provider at least an order of magnitude of improvement. 6. Thank the lord for Jetbrains but other than them, to do proper .Net development you need to use Visual Studio. And Visual Studio is not a pleasant IDE or development environment at all.

There were a lot of technical reasons to not adopt .Net. Even today there’s the problem of MS losing interest or making the wrong choices and there being basically no alternative, because unlike even Java, the .NET ecosystem is completely dependent on what MS does.

In +90% of cases you will still need a frontend for that backend.

TS full stack is by far the best option for this.

"The main concern is having replaceable talent to reliably do X" as in every other company?

I swear you guys make having a regular job sound like being under slavery. It's just a job. Some companies are boring, that's just part of the job, and being able to adapt to different environments is what makes a good sde imo.

I'm just fondly remembering the ASP.NET MVC churn or more recently, Azure API whiplash.

.NET was literally created to replace the Java enterprise ecosystem. It never managed to completely displace it, but effectively gained around half of the enterprise market - and it will take more and more, after Oracle started pulling their usual boa-constrictor moves. C# is as "enterprisey" as they come, and it went full-opensource only once it became a requirement even in the enterprise.

But I would levy the same complaint with most Java[1] usage as well.

1. https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...

I'm not saying all dotnet places are like this, but they are common.

No, they don't. You may believe that some frameworks or programming language are ideally suited for some particular tasks, but that is mainly dictated by your prior experience (or lack thereof). The truth of the matter is that a van can very well do the tasks you conceive for a car, trucks, bicycles, motorcycles, etc. If you go with a van, you avoid the problems of having to maintain car, trucks, bicycles, motorcycles, etc. This is called software engineering.

Which is an analogy for "how many different programming languages for the same task of serving a web api can you company afford to support?"

The majority of programming languages (c# definitely included!) are "general purpose", i.e. they can be used well enough for almost all tasks. They're not so different as a truck vs. a bicycle.

The issue is not so much "we need firmware in Rust and statistical analysis in R" - that's fair! The issue is more, as others have said, web apps or similar in multiple equivalent languages. This is an overhead. If you take on that overhead, recognise that 1) it has definite drawbacks and 2) for mundane tasks, the advantages aren't large. and 3) chances are your organisation is like most orgs - you don't do all of firmware, statistical analysis and web apps, in house.

I'm saying use one tool for one task. One type of truck. One type of bicycle. Maybe some companies need both a small and a large truck. That's all fine as long as you actually need it.

Just don't let every dev choose their own because you're gonna have a hell of a time maintaining that fleet.

The "force everyone to ride it" on the weekend part is where I think the analogy has broken down irreparably. We're talking about cost of ownership of company equipment used during working hours for much more defined tasks. What flavour of bike you enjoy riding on weekends is not relevant.

Programming language are inherently flexible, especially those that aim to be "general purpose". Fine-grained distinction of road bike vs mountain bike apply more to the apps created than the coding tool.