Comment by codemog
8 hours ago
A lot of this advice is good or at least interesting. A lot of it is questionable. Python is completely fine for the backend. And using SQLite for your prod database is a bad idea, just use Postgres or similar.
8 hours ago
A lot of this advice is good or at least interesting. A lot of it is questionable. Python is completely fine for the backend. And using SQLite for your prod database is a bad idea, just use Postgres or similar.
There’s a lot to be said about his approach with go for simplicity. Python needs virtual environments, package managers, dependencies on disk, a wsgi/asgi server to run forked copies of the server, and all of that uses 4x-20x the ram usage of go. Docker usually gets involved around here and before you know it you’re neck deep in helm charts and cursing CNI configs in an EKS cluster.
The go equivalent of just coping one file across to a server a restarting its process has a lot of appeal and clearly works well for him.
Yes. It strikes me as odd how many people will put forward Python with the argument of "simplicity".
It is not. Simple. It may be "easy" but easy != simple (simple is hard, I tend to say).
I'm currently involved in a project that was initially layed out as microservices in rust and some go, to slowly replace a monolyth Django monstrosity of 12+ years tech debt.
But the new hires are pushing back and re-introducing python, eith that argument of simplicity. Sure, python is much easier than a rust equivalent. Esp in early phases. But to me, 25+ years developer/engineer, yet new to python, it's unbelievable complex. Yes, uv solves some. As does ty and ruff. But, my goodness, what a mess to set up simple ci pipelines, a local development machine (that doesn't break my OS or other software on that machine). Hell, even the dockerfiles are magnitudes more complex than most others I've encountered.
I am not following the difficulties you have mentioned. Setting up a local dev environment in Python is trivial with UV.
The only major downside of Python is its got a bit poor module system and nothing as seamless as Cargo.
Beyond that the code is a million times easier to understand for a web app.
Python will take you a long way, but its ceiling (both typical and absolute) is far lower than the likes of Go and Rust. For typical implementations, the difference may be a factor of ten. For careful implementations (of both), it can be a lot more than that.
Does the difference matter? You must decide that.
As for your dismissing SQLite: please justify why it’s a bad idea. Because I strongly disagree.
What a load of nonsense.
Why is it nonsense? Sounds reasonable to me.
4 replies →
Why is SQLite bad for production database?
Yes, it has some things that behave differently than PostgreSQL but I am curious about why you think that.
For read only it can be a great option. But even then I would choose D1 which has an amazing free tier and is sqlite under da hood.
But then you don't get the benefits of having the DB locally, with in-process access.
4 replies →
I think the point is that your Python webapp will have more problems scaling to let's say 10,000 customers on a 5$ VPS tham Go. Of course you can always get beefier servers, but then that adds up for every project
At 10,000 paying customers I don't think it is frivolous to move to a 10/month vps, or maybe a second 5/month one for fail-over.