A lot of the asp.net core configuration nonsense can be entirely sidestepped, but the way in which you would do this is not published as a headline article or otherwise made clear to the developer.

I suspect Microsoft wants most developers to throw their hands up and just follow the "hook your app up to our $$$ azure authentication products $$$" tutorial.

The happy path for AspNetCore could be achieved if Microsoft started the entire conversation with "Here's a request pipeline and here's how you add middleware to it". Everything else is some form of abstraction on top of that. You can learn about how to do all of this 1 afternoon if you know what to focus on.

Once you figure out how to get at HttpContext with your services available in that scope, you have the rabbit entirely cornered. Relying on Micrsoft's middleware to do everything for you is how you get trapped in their puzzle box for all eternity.

This is so not true. It is the opposite of a clusterfuck. The old ASP.NET was a clusterfuck.

It has a excellent server (kestrel), a middleware pipeline, routing system and common dispatching patterns like pages, MVC or minimal apis.

It is excellent in every degree of abstraction. Love the basics, go for kestrel. Work with http basics go for middlewares. Want to work with request and response principles and routes go for minimal API. MVC for a bit more structure. Pages for a traditional set. And Blazor Serverside if you love state.

All of this experiences are good.

I would prefer some examples what is bad here! And spare me DI.

This. I have to support it in production among other platforms. It’s painful to reverse engineer the stack every time something goes bang which is often and usually something utterly obscure. It also has a much higher amount of hands on work required to keep the plates spinning than any other platform I’ve used.

To be clear I have .Net experience going back to the beta frameworks in the early 2000’s and have hand held some huge products on the platform from inception to maintenance phase architecturally and infrastructure wise. It’s been a bloody rough ride and I regret every moment of it and wish I’d picked another platform bet. I’ve had the entire stack rug pulled from underneath major projects multiple times and burned months in pointless rewrites due to tech changes and obsolescence. The majority of the open source ecosystem is broken or abandonware and the commercial bits are overpriced, with poor support and barely work. It’s hell.

The only good bit has been being paid by the hour to unfuck stuff which has been profitable.

You are talking about the old asp.net, not the Core one? Because I do not recognize any of this. I find asp.net core, especially 5 and 6, rather trivial to handle vs a lot of other products running in production.

Both. Core is probably 50% less painful but it does some weird stuff sometimes including GC problems and a wonderful issue we have where it just does an exit(0) intermittently.

Sounds like your developers might be doing the damage themselves. I run a lot of .NET Core/.NET 5 applications, and I've experienced none of those issues.

Quite possibly. I don’t disagree with that.

But that doesn’t give me much confidence when it comes to finding out how to fix things that go wrong.

I just talked to a bunch of Python engineers who feel that way. They didn't have a single solid argument - what's yours? .NET is a bit verbose, but there is a clarity that comes with it.

The Microsoft documentation is garbage, the worst I have seen. But the language and framework are good.

Python is just as horrible. It’s ok for a bit of automation with system packages but the moment you end up with a venv it starts getting painful. I have seen much criminality rammed into AWS Lambda for example.

The c# language is now like an Indian train at rush hour. Busy and dangerous. Very easy to shoot yourself in the foot if you don’t know what you’re doing. LINQ and its contract breaking promises are a fun one for example. One interface returning IEnumerable<T> and you’re in big trouble when someone assumes the data is already materialised.

This isn't an excuse or an explanation, but in prod, most devs ToList() any async calls / anything using IEnumerable. They don't want to think about the nuance and have the additional methods available on the List interface out of the box. Seems to be a decent convention, since the performance diffs between IEnumerable and IList are miniscule for paginated 20-record calls that are 99% of Line-of-Business apps.

If you are referring to lazy loading, awaiting calls and ToList()..ing them solves that too.

I know I will get crucified for this, but that's what happens in practice.

Ms docs, as in msdn documentation? Nothing's perfect, but actually covering almost every single class it's better than what other languages normally offer.

What would you recommend that is fast enough (ie not Ruby or Python)?

I’m hedging my bets on lots of small bits of well decoupled and well designed Go with micro frontends in JS sitting on top of Kubernetes. It sits in the niche area of being typed, quite fast, light weight, reliable, fast startup, decent tooling and concise enough to be able to build knowledge and retain it.

If all you're doing is web dev, Ruby and Python are both more than fast enough.

Imagine how much less compute capacity we would need if Ruby and Python were as fast as .net core.

We're talking a lot about doing something for the environment, it could start with using "fast enough" languages.

Of course we need to find a compromise between performances and ease of use. So I wouldn't abandon .net core for Ruby or Python, but I would for something as performant (or better ofc) but friendlier to use.

In that case, the elephant in the room is of course Javascript ;) It can be up to 50x faster than python or ruby.

A single RDS instance and a handful of web servers can handle hundreds of millions to low billions of requests a month with last byte responses under 200-300ms.

How so? It's about as lean as it gets. It also provides so much standard functionality which is where other frameworks fall down.

Easy to make a simple endpoint for a tutorial, but after building any serious application the other language stacks end up hooking together several large packages and modules just to get the same standard functionality that ASP.NET provides.