it's a history thing: back then, everything was serverless^WCGI and you didn't need to do any http servery things at all: just read stdin and write to stdout. web servers were an afterthought and turns out if you needed performance, you had to do it in C anyway, so nothing came prepackaged. then the web 2.0 happened and suddenly hello world is being done over http instead of printing to stdout, so new entrants obviously designed their stdlib around this.

But I still need gunicorn, don't I? My point is that with Go, I just have to execute my single binary and I'm good to go. It doesn't prevent me from adding a reverse proxy and a loaf balancer if I want to, but I don't need gunicorn or other runners.

Also if a single line is enough, maybe adding it clearly to the doc would be nice.

> But I still need gunicorn, don't I? My point is that with Go, I just have to execute my single binary and I'm good to go.

I don't see how your point is relevant. I mean, with interpreted languages you need to run the interpreter, but if having to write an additional word or line of code bothers you that much then you should not worry about it if you dockerize the app or, god forbid, use a launcher script. I mean, in non land no one ever complained about how hard it is to add scripts to mom's start and prestarte targets to launch a server by doing mpm start. So why is this suddenly relevant with Go?

You don't. Some frameworks are stand alone. It just happens flask uses wsgi, and so you need gunicorn.