I guess it's subjective. For me the clear advantage of building HTTP endpoints using Go (framework-less) over DRF, Swagger and others is: no magic, no annotations, no dependencies; I know exactly what's happening and I can build a tailored system that is adjusted to my needs. This leads to very performant systems that are highly independent of the current trends and, most importantly, to a high degree of ownership of the systems you are building.

The act of writing these kind of systems is IMHO, somehow, liberating.

Static typing buys you correctness now. Go isn't really a poster child of language design, to be blunt - but it's better to find out now rather than in production.

Compiled code is also significantly faster in many cases.

i see your point and i know OP asked about why Go instead of python, but having a statically typed language isn't limited to only Go. you could replace everything you wrote with Java/C++/C# and still have a similar answer (minus language design i guess which is a different argument)

1. simpler architecture - python typically requires multiple systems to deal with concurrency (ioloops, celery, etc)

2. execution speed - Django's ORM comes to mind

3. concurrency

That being said there are alot of great features with python web frameworks that come out of the box. You need to a lightweight project like gin/echo or something to get these features. Naked net/http is sorta like the 'erector set' of web frameworks.

Every time I use DRF, I end up making some huge and horrible abstraction that I hate after its creation, like Dr. Frankenstein. So far, this has not happened to me with Go. I don’t know if the problem is just me or what, but I find Go easier to just define a data type, grab some JSON from the request, send some other JSON back without making myself crazy.

Interesting. Can you give an example of a "huge and horrible" abstraction that stems from your usage of DRF?

I remember having the same sentiment a few months back, but investing a considerable amount of time planning the structure of serializers and sticking to DRF's patterns did reduce the amount of "fighting" that I need to do to make my API work as expected.

running python servers is annoying, you have to have a menagerie of stupid little parts and things to get it all to fit together. I haven't done this in years but I always wound up with some mess of virtual envs, pip, gunicorn, nginx proxying, something to start the services, and that's _before_ writing any of my own code. With Go I just compile a static binary, rsync it to a server and turn it on and call it a day. The only other part I often use is nginx as a reverse proxy because it's easier to harden. Way easier to operate and way easier to not break once your project gets beyond a few kloc.

> With Go I just compile a static binary, rsync it to a server and turn it on

With "turning it on", you mean you write a systemd configuration file and start it using systemctl, right? Just curious how people do this stuff nowadays.