[pharmakom]

I used to write lots of C#, but now I consider it a bad ecosystem. The problem is the amount of ceremony, silly OOP abstractions, dependency injection, etc. Just look at building a simple HTTP endpoint in C# compared to Node or even F#!

[rawling]

> Just look at building a simple HTTP endpoint in C# compared to Node or even F#!

It's... basically the same? Include library, create server object, tell server object what request to handle and what to return, start server object.

https://learn.microsoft.com/en-us/aspnet/core/fundamentals/m...

[whizzter]

Yeah, you can get away with minimal C# stuff if you want. Mind you minimal API's is a relatively new thing as of NetCore 6 so GP might not have had the chance to touch these new things yet.

Much of the older overdesigned pain of C# is that it used to be tied to how IIS wanted things to work, NetCore initially pivoted more to DI stuff before pivoting again to these minimal API's but the DI stuff is definitely available(and used) still.

For pragmatic choices it's all there, you can start off with minimal API's and get far with it and once you start feeling pain-points as you want to re-implement things it might be time to add in the more "frameworky" parts.

[progmetaldev]

You can also use DI without having to use interfaces for everything. It's easy and possible to inject straight dependencies from concrete classes into constructors, without all the abstraction (beyond allowing constructors being called for your dependencies and injected into your controllers). I'm a big fan of using services with an unabstracted database context from EF Core, rather than ever making use of repositories. I can still go from a MVC project with concrete views, over to Web API with a completely JavaScript frontend framework, without needing to change any of my business logic. Approximately 10 years ago, I was lost in all the abstraction you'd find in tutorials and any book on ASP.NET MVC, but experience has taught me a LOT, as well as working with other languages and seeing the (lack) of ceremony needed to get things done.

[vsareto]

By "used to write", I'm guessing maybe they worked in the .NET Framework/IIS era, which did have a cognitive cliff to climb. You could get used to the ceremony though and then your brain started to ignore it and focus on the stuff that mattered. These days it's much easier though.

[michielr]

I agree this was a problem, but with the current Minimal API's, there is no boilerplate, looks a lot like Express to me!

  var builder = WebApplication.CreateBuilder(args);
  var app = builder.Build();
  app.MapGet("/", () => "Hello World!");
  app.Run();

[_gabe_]

>> The problem is the amount of ceremony, silly OOP abstractions, dependency injection, etc.

Your code snippet certainly has a lot of unnecessary ceremony. Why use a builder object at all? Why use a static class with a function to build the builder object?

  var builder = createBuilder(args);
  // etc...

Would be better. But

  var app = createWebApp(args);
  // etc...

Is even better. No ceremony at all!

[progmetaldev]

There is a lot that gets done behind the scenes in createBuilder(). I understand where you're coming from, but this allows you to override any defaults that you don't like, in order to provide your own. I personally still stick to the standard MVC pattern, and don't go crazy with abstractions. I place my business logic within services and inject those in my controllers, but if you were to run a debugger, you would not have to jump through interfaces and other useless abstractions that were a thing of the past (and present if you follow current tutorials and books). I have used Node.JS, and still use it to provide my frontend developers with an environment using Express to build out templates using Gulp for minification/transpilation/compression for use in Umbraco (a .NET Core CMS). My frontend developers don't need to know C#, and can work in standard EJS templates and HTML, but benefit from SCSS and modern JavaScript. I can then build out the Razor syntax for views, and just drop their CSS and JS files directly into the CMS projects.