5 ms·

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

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.

GiorgioG 5y ago
.NET 6.0 minimal APIs allows you to do just that: https://www.hanselman.com/blog/a-net-6-minimal-api-todo-example-playground https://www.hanselman.com/blog/a-net-6-minimal-api-todo-exam...
nightski 5y ago
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();
- 3np 5y ago
  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.
  - GordonS 5y ago
    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!).
    - thrower123 5y ago
      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.
      - pipeline_peak 5y ago
        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.
- bluefirebrand 5y ago
  How much boilerplate and configuration does "dotnet new web" generate?
  - nightski 5y ago
    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.
potta_coffee 5y ago
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.
- metaltyphoon 5y ago
  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.
  - oneplane 5y ago
    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.
  - potta_coffee 5y ago
    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?

GiorgioG 5y ago

.NET 6.0 minimal APIs allows you to do just that: https://www.hanselman.com/blog/a-net-6-minimal-api-todo-example-playground https://www.hanselman.com/blog/a-net-6-minimal-api-todo-exam...

nightski 5y ago

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();

3np 5y ago
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.
- GordonS 5y ago
  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!).
  - thrower123 5y ago
    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.
    - pipeline_peak 5y ago
      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.
bluefirebrand 5y ago
How much boilerplate and configuration does "dotnet new web" generate?
- nightski 5y ago
  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.

potta_coffee 5y ago

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.

metaltyphoon 5y ago
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.
- oneplane 5y ago
  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.
- potta_coffee 5y ago
  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?