I'm working on a Django+graphQL app and I'm basically considering buying a farm at this point. Python is really not the right language.
I'm working on a Django+graphQL app and I'm basically considering buying a farm at this point. Python is really not the right language.
I actually prefer Kotlin for a lot stuff people use those languages for. Similar amount of stuff to download but just a lot better tools (e.g. refactoring) and less leaky abstractions. I've used all of it of course. I just know what I prefer at this point. I was doing some python last week. It's alright but also quite a messy ecosystem.
As for Graphql, I just completed a project of ripping that out. Using it was a mistake. People like it for the wrong reasons; mostly because they are afraid of joining tables with SQL and spending some time thinking about what the optimal table structure is to minimize the amount of expensive joins needed. So they end up using stuff that does that poorly by combining the results of multiple micro-services after it comes out of the database. Which has all the predictable downsides in terms of performance. People use ORMs for the same reason. ORMs are popular for the same reason. It's not the tools but the people wielding them shying away from thinking about doing more optimal things with their databases. This stuff can work fine if you know what you are doing of course. But lots of people simply don't.
Python 3.13 will have a JIT, and true threads. It'll likely take a couple more releases for these features to be stable and utilized throughout the stdlib and the wider ecosystem. In a few years, performance and quirks will likely not be an issue.
Whenever I run some benchmark myself, I do not see any improvements over Python 3.7 and the horrible numbers for the threaded build.
I do not understand why Dropbox and Instagram are cited as references. People also cited Google 10 years ago, but Google has now fired the Python team.
Dropbox moved large parts to Golang, and Instagram code does not seem to be something to aspire for. Perhaps Instagram manages to prop up a horrible stack by throwing hundreds of developers at the problem. Not every company, especially startups, can afford that.
If the new free threading becomes the default, I would not expose Python directly to the web. Already before that CPython has show a lackadaisical attitude towards threading correctness and convoluted abstractions that are barely auditable.
We’ve built a few APIs which serve millions of users without any problems and with very low latency with FastAPI, and so far we’re very happy with the choice.
Static analysis is pretty much impossible for large python codebases. IntelliJ does not understand a single shit about the codebase I'm working on and I find myself having to ctrl+f instead of being able to shift click, etc. There is simply such a thing as "too dynamic".
Python was designed for quick scripts and pseudocode mockup prototypes. There's a bunch of bullshit strapped onto it nowadays but there's no escaping the roots of the design of python. It's not a good fit for large software or software nor software that needs to be reliable. Sure, with _enough effort and discipline_ you can bla bla bla. I'm not interested in that. I'm interested in working smarter, not harder.
but not having to context switch from python to another language is worth it for 95% of applications.