I'm not sure how you feel I attacked C# aside from thinking it had the unnecessary bloat of requiring functions to live in class objects. As far as splitting everything up into 9 billion files and projects it's not something C# really forces you to do. I don't mind dotnet too much, I've worked with it for a decade and it's never been as great to work with as what it's become. I'd never pick it over Go for a new project if I had the choice though. I'm genuinely curious as to why you'd say these things however:
> Go has poorer ecosystem for writing web applications
For me personally the std http handlers is by far the best experience I've ever had with web development. Though I suspect that you may have worked with Go before the std was enough, and if so your experience was probably a little "tainted" by how the the ecosystem can be a little too "node" like.
> worse ORMs and worse tools for troubleshooting advanced issues in production
Now this is personal preference but I don't particularly like the rich debugging capabilities of the Microsoft package for C#. Exactly because it's hard to use them in production. Which depends on what sort of production environment you have, but we rely on open telemetry even for our dotnet applications. As far as ORMs go... We operate at a scale where they aren't useable. Entity Framework is quite nice... It's just that the industry has sort of moved beyond the need for ORMs. Even if your teams manage to avoid the lazy loading pitfalls your ORM is eventually going to be more complex than simply working without one. Partly because they weren't really designed for things like an Expand Contract Pattern (which you can implement, but then you're doing more work than simply writing raw SQL), but mainly because LLM's have made it sooooo easy to be both productive and remain control over your data.
> Go brings notoriously more boilerplate
I can write a struct and a function and then call it on my type in less lines of code than it takes to do the whole namespace... So I'm really not sure what you mean by this. If it's the C# magic which happens behind the scenes I think it's up to your personal opinion whether or not you want the control. As you might have guess from my take on ORM's I prefer the transparency and control.
> Go has poorer ecosystem for writing web applications
For me personally the std http handlers is by far the best experience I've ever had with web development. Though I suspect that you may have worked with Go before the std was enough, and if so your experience was probably a little "tainted" by how the the ecosystem can be a little too "node" like.
> worse ORMs and worse tools for troubleshooting advanced issues in production
Now this is personal preference but I don't particularly like the rich debugging capabilities of the Microsoft package for C#. Exactly because it's hard to use them in production. Which depends on what sort of production environment you have, but we rely on open telemetry even for our dotnet applications. As far as ORMs go... We operate at a scale where they aren't useable. Entity Framework is quite nice... It's just that the industry has sort of moved beyond the need for ORMs. Even if your teams manage to avoid the lazy loading pitfalls your ORM is eventually going to be more complex than simply working without one. Partly because they weren't really designed for things like an Expand Contract Pattern (which you can implement, but then you're doing more work than simply writing raw SQL), but mainly because LLM's have made it sooooo easy to be both productive and remain control over your data.
> Go brings notoriously more boilerplate
I can write a struct and a function and then call it on my type in less lines of code than it takes to do the whole namespace... So I'm really not sure what you mean by this. If it's the C# magic which happens behind the scenes I think it's up to your personal opinion whether or not you want the control. As you might have guess from my take on ORM's I prefer the transparency and control.