Whoah, this comment section is surreal. People really aren't bothered by the propensity for runtime errors in python? How slow it is? That it has no good features for managing complexity in large codebasea? The fact that abstractions like these pretty much always break, or at some point you want to do something more outside of the box, and you have to put in a monumental effort?
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.
Slow is if you need to download MBs worth of JS frameworks. I love that this is usable without JS if you want to. Also the abstractions around HTML seem to be very thin so I don't really get your pint there. GraphQL seems to be a performance killer too, so maybe just use simple, boring SQL?
Downloading that all that stuff is a one time thing if you are developing. And most js dependencies are actually developer tools. The runtime dependencies of a webapp tend to be pretty minimal actually. Also, python has lots of dependencies typically.
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.
There has been funding in recent years to fix the quirks and improve performance. The Faster CPython project has had good outcomes towards achieving these goals.
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.
Yes, I think people are polite and give the new framework a chance. Anything that is not Django is of course appreciated.
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.
I’ve seen good Python projects and bad Python projects. Not all errors are caught at compile time and performance may or may not matter in non-cpu bound workloads. There’s no “right” language. Python can shine in the right context (including web applications).
Can you expand on the features you need for managing complexity in large code bases?
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 typing (that is actually sound, strict, and enforced by default) with support for interfaces. Just generally a language that doesn't incentivizes using strings and dictionaries for everything. A language that has actual separation and implementation hiding, rather than the convention of using underscores and praying that no one touches it.
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.
Pydantic, dataclasses and mypy help a lot, I don't get what you mean by incentivizing strings and dictionaries for everything, that definitely doesn't sound like good modern Python. The go-to-definition functionality is available in any modern editor, it sounds like yours isn’t set up properly.
Yeah I also don't get it. Python is great and I really like it, but it never feels like a good choice for an app that runs 24/7 for years to come. So many wasted CPU cycles.
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.