I personally think Python is nice to work with and I really like Django as monolithic web framework with no dependencies- a rare thing these days. But when thinking about long term projects I’m unable to reconcile things I like with the fact that Python is among the slowest modern languages. Why would I start with an unnecessary handicap?
Can't speak for Python/Django but I'm in the Rails world and the fact is on most Rails apps (even huge ones) the Ruby code isn't the bottleneck. IO and database operations are. You don't need a fast language for the things Python (and Ruby, PHP, Perl, etc..) does.
This is a widely-held belief, but it isn't true. Maybe once upon a time in the land of spinning rust that was true, but it certainly isn't now. Databases are fast enough that a scripting language frequently is the performance bottleneck.
> scripting language frequently is the performance bottleneck
I'm not sure I'd use the word "frequently" here, but I could just have a different experience. Most projects are boring CRUD stuff, and something else have always been the bottleneck before the actual language itself, most of the times different types of I/O but also just poor choice of algorithms/data structures. I don't think I've ever actually came across a situation where the language itself was the bottleneck of the performance, but I don't normally work super close to performance-sensitive projects as I said, mostly common web tasks.
I know benchmarking isn't always the greatest, especially when the previous maintainer of Actix-Web (Rust) kind of cheated to get to the top of the leaderboard, but it still provides a decent general overview of how many responses/s a service can handle when using the same box.
> True, but depending on the service I personally would like efficient languages, not only dev time wise, but also runtime wise.
I don't think this really exists today partly because of the comment you replied to.
Rails, Django and Laravel are massively optimized for developer productivity to build web applications and use languages that have been around long enough where the community has created widely successful and popular libraries to implement mostly common features for things aren't included by default. Libraries that go beyond 1 developer maintaining them in their free time.
If you can build a web app and host it for $40 a month on a single VPS that can sustain tens of thousands of users and you can make a million dollars a year as a solo developer what incentive is there to switch to a faster language? Your secret weapon here is being able to build things quickly and not have to single handily develop a bunch of common lower level libraries just to build the app features you want.
For when you need to scale out we have Kubernetes which generally works the same to scale out most types of web apps. It seriously (honestly) doesn't matter if your hosting bill is $10,000 / month instead of $3,000 / month when you have a team of 8 developers ($240,000 / month) on payroll and your web app is happily returning p99 responses in under 150ms while your business profits tens of millions of dollars a year. What does matter is how fast you can build new features while maintaining your app and finding qualified developers.
> while your business profits tens of millions of dollars a year
These two points from both of your comments don't really reconcile (today).
Sure, if you're optimizing for "profits tens of millions of dollars a year" then go ahead and spend/receive as much money as you can and disregard all else, like the environment, employees health and so on.
But, if we want to have sustainable companies, in terms of profit and impact on the earth together with it's inhabitants, then we need to go further than just considering how we can add that next million to our ARR.
I really don't think the world is going to be saved by building your crud apps in rust instead of python. Consider instead what could be done if the company that is able to grow twice as fast has a charity matching program?
Or, i don't know, imagine we tried to fix something that actually would cause a dent, like not encouraging everyone to buy new smartphones and laptops every year, not allowing international shipping to externalize the costs of burning "lowest imaginable quality" diesel, etc. This comment feels like saying "Turn off your LED lights when you go to bed!" while your neighbors are literally burning tires in their backyards.
> I really don't think the world is going to be saved by building your crud apps in rust instead of python.
If that is all we are doing to "save the environment", then surely not.
On the other hand, if we are going towards a wall with 200km/h and only "lightly break" (so not pushing the break really hard), then we will still crash, maybe with 100km/h, still deadly.
What I want to say: No, it (being more resource-friendly) is not the one solution, but it's part of a greater solution.
> These two points from both of your comments don't really reconcile (today).
I didn't write both comments btw, the parent comment who I replied to is someone else who mentioned the environment.
> Sure, if you're optimizing for "profits tens of millions of dollars a year" then go ahead and spend/receive as much money as you can and disregard all else, like the environment, employees health and so on.
It's possible to be environmentally friendly, have reasonable server costs for an app built with Python / Ruby / PHP, keep employees happy and make major progress towards improving Earth. The place I work at is focused on clean energy management and the environment. It's a privately owned company so it's not my place to share any numbers but I can say we don't throw money at problems as a first line of action.
For context, the company has been around for over 10+ years and uses PHP (public info based on HTTP headers). I joined a few months ago as a full time employee after spending ~20 years being a solo developer doing contract work. I hope that sets the stage for how much I like the folks working there and how they run things. Also for context, I don't actively write PHP there. My role is focused on deploying their app(s) although I have developed some Python based services for them (I did contract work with them for a while before joining full time).
Developer time needed has an environmental cost too. It's not at all clear that optimising server usage will always be worth it if it requires more developer time even from an environmental perspective.
> I don't think this really exists today partly because of the comment you replied to.
Java and JVM languages are reasonably good dev time wise as well as performance/energy efficiency wise. The latter is possible by not running GC all the time so it comes at the expense of slightly higher memory consumption, but JVM GC’s are beasts, they can manage heap sizes up to terabytes of RAM.
While a request itself can finish reasonably fast in a slow language, the amount of resources a single request consumes since python can't do multithreading is quite absurd. The python codebases I've worked on need an order of magnitude more servers to handle similar amount of loads, since each request is basically handled by a separate process.
It's fairly standard practice to hack in some "green thread" behaviour using gevent or similar. It's far from perfect but gets you away from the single-process-per-request bottleneck. If it even is much of a bottleneck in the first place - isolating each request in its own process worked well enough back in the CGI days. I suspect the real reason is that autoscaling doesn't generally play well with having thousands of mostly idle processes.
Though, they ended up writing a whole new Ruby JIT to deal with Ruby's performance, so clearly at some point the trade-off changes from "no systems programming, a highly dynamic language instead" to "hardcore systems programming, to make the highly dynamic language fast enough"
For a bigger code base projects fixed typing contributes to speed of development. Add to it dependency management you will have clear win-win for something like Java over Python.
They force different tradeoffs to be made in languages but also in development, so they kind of are.
Obviously: if speed of development and speed of program were non-problematically compatible, everybody would always go for both (why lose speed, if you can have the same development experience)? But speed requires several things, like more careful algorithms and program design, custom solutions instead of one-size-fits-all libraries and frameworks, more care regarding memory usage, time spend for optimization, use of a statically typed language as opposed to a higher level scripting one, slower build/jit times (as opposed to interpreter), and so on...
Garbage collectors are not bottle necks at all, hell, for highly dynamic allocation patterns they beat malloc implementations out of the water in performance.
Of course one should not spam them needlessly, but that’s why value classes are important.
"Comparing runtime, space consumption, and virtual memory footprints over a range of benchmarks, we show that the runtime performance of the best-performing garbage collector is competitive with explicit memory management when given enough memory. In particular, when garbage collection has five times as much memory as required, its runtime performance matches or slightly exceeds that of explicit memory management. However, garbage collection’s performance degrades substantially when it must use smaller heaps. With three times as much memory, it runs 17% slower on average, and with twice as much memory, it runs 70% slower. Garbage collection also is more susceptible to paging when physical memory is scarce. In such conditions, all of the garbage collectors we examine here suffer order-of-magnitude performance penalties relative to explicit memory management."
Horizontal scaling is going to be an issue eventually, no matter the language. You can serve tens of thousands of people off a single django server. Unless you're going to hit a growth limit at specifically 3-5x what a single vertically scaled django server can do, or you know for a fact that webserver compute is going to be the bottleneck, development speed rules all else.
I’d agree, but I wonder how much faster writing a backend API in Django is compared to using node.
I’ve written a lot of python outside of the web space and a lot of JavaScript in the web space and I can’t think of a time I wish I was writing in python.
Modern JavaScript has a really expressive syntax without the runtime performance hit.
For every comment like this, there is someone who would say the opposite. Why would I write in a language with the semantics of javascript when I could use python?
I'd also argue that syntax-wise they are virtually the same language and not worth really comparing. It's not like either is ML.
Every month or so I look around to see if there's a monolithic web framework in languages I'm interested that are effectively equivalents of Django, Rails, Laravel, etc. I've done a lot of non-webapp stuff with Go, for example, and would like to build full fledged webapps with a Django-like framework in Go. But nothing like that truly exists. I've found projects like Buffalo [0] that promise this monolithic experience, but they're still very much works in progress. Even Node lacks such a true monolithic web framework from what I can tell.
