I can open a file in notepad and get a high performance HTTP server spun up and responding in under 10 lines with Go. With a simple single function abstraction around what can modify the incoming request and what can write to response.

In .NET I find that it's incredibly powerful when you know what you're doing. But there's just so much crap to wade through that I'm just thinking "why isn't this easier?".

The abstractions that .NET throws at you to start developing with it encourages developers to write their own applications as these crazy complex mazes of abstraction too.

Why can't .NET just be simple? Hand me a request with a Stream, give me a Stream to write my response to. That's all a HTTP handler needs to be, whether it's middleware or not. But instead it's just overwhelming.

In .net 6 you just run the command -

dotnet new web

then type

dotnet run

and you have a web app running.

If you'd like to edit Program.cs with notepad or w/e (the default text is below, which is incredibly simple).

var builder = WebApplication.CreateBuilder(args); var app = builder.Build();

app.MapGet("/", () => "Hello World!");

app.Run();

Right. I don't know if this changed significantly with 6, but my experience from previous versions have been that as soon as you start adding things like caches, authentication middleware that interacts with certain other components, or rewrite requests or responses in other ways it soon becomes a goose chase across the web and incomplete documentation.

This is what comes to mind to me from GP's mention of crazy abstraction mazes.

A lot of this stuff was fiddly a long time back, before dotnet core, but it's all pretty sweet these days.

For example, `AddMemoryCache() ` gives you a memory cache with the default settings - or you can change them by using the options argument. Request rewriting is really simple too, and even authentication is relatively straightforward.

I get what you mean about "crazy abstraction mazes", but thankfully over the past few years we've been trending away from the madness of ludicrous inheritance hierarchies that were sold as "clean code" and dogmatically hoovered up by junior devs (including me, once upon a time!).

It does get a little complicated when you try adding in the middleware components, and it doesn't Just Work. Frequently then you end up at some GitHub readme file as the only documentation (for first-party Microsoft components) with some very brief examples, maybe with some samples that don't quite show how you'd want to do what you want to do. Then you start digging in the source code and learning how the guts of aspnet core work.

I would agree that bailing on dogmatic 2000s OOP has been an improvement.

I think The command and observer aspects of WPF are really elegant and OOP patterns certainly have their place.

But app development isn’t a pretty place where time crunched developers are expected to carefully design complex data structures…..at all.

How much boilerplate and configuration does "dotnet new web" generate?

That was the entire source code. There is a project file, but it's incredibly simple and they are meant to be human consumed/edited nowadays.

.NET 6.0 minimal APIs allows you to do just that:

https://www.hanselman.com/blog/a-net-6-minimal-api-todo-exam...

This was my observation. 50 lines of Go translate to 500 lines of .NET. All based on assumptions of what proper OOP and SOLID should be, things that I neither need nor care about when 50 lines of simple code could get me there.

Perhaps you have the old view of .NET?

In fact there is more reinventing the well in go because all the std lib is just that… a library. When you need all the fluff around parsing routes, validating objects, preventing XSRF and a multitude of common solved problems, you have to reach for third party.

I need surprisingly few 3rd party packages to build projects in Go. Most if not all of them are in the "nice to have category". Also, I've seen more then a few .NET projects now and they all had 3rd party packages installed as well. Perhaps it's possible to build without 3rd parties but how many real world projects are built this way?

You make it sound like everything has to be first party (i.e. a locked-in ecosystem).

I also don't agree that one is 'reaching' for anything, since as soon as you interact with the broader world of interconnected systems, most of the first-party Microsoft things just don't work. They are almost all designed for their own standards that are too different or have to be manipulated too much to be compatible with something else.

Some things don't even exist like a basic Redis client. At that point even a highly experienced Microsoft developer has no choice but to get that non-first-party library.

dotnet tries to do too much by itself and that makes it annoying to use unless you happen to be building what it wants you to build.

asp.net core is a clusterfuck of over-architecture and over-abstraction.

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.