Atom was my first text editor when I was getting serious into learning software development. Sharing this neat video for those who hasn't seen it yet:

https://www.youtube.com/watch?v=Y7aEiVwBAdk

I understand what you feel completely. I actually wasn't even able to complete the tutorial since the commands given would trigger a permission error one way or another. I got charged $50 as well since I wasn't aware that there's still services running. Such a terrible thing to front as a "Getting Started" guide.

Really excited to see your release on the Philippines. Godspeed!

I still use Django to this day, both for monolithic SSRs and REST APIs. All the batteries it comes with are perfect for the common use case, and the small "bubble" around it (ex: DRF) is as good as it gets IMO.

The tooling around REST APIs are lacking compared to Flask and FastAPI, but wrangling what's available (drf-yasg, oauth2lib) to suit my needs is better than migrating to another framework I think.

Same here. When I want to get a new project of the ground, I use Django.

This partially due to the batteries included, partially because I am very familiar with it.

On more mature projects, at the stage where I really start splitting services into their own hosts, I switch to something else. Django's batteries are no longer useful at this stage, since e.g. auth is it's own service now.

I'm an API developer working with Python and Django. I did dabble with Golang for quite some time, but I just can't seem to justify the effort (in terms of lines of codes and static typing) of writing a ReST API with Go when I can build a similar one with Django and co (DRF, Swagger, etc).

Can someone chime in? There must be an obvious advantage that I might be missing.

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.