4 ms·

I'm always slightly confused by the language speed comparisons for I/O heavy applications like networked services. On the one side you are taking in, for exampl

I'm always slightly confused by the language speed comparisons for I/O heavy applications like networked services. On the one side you are taking in, for example, HTTP requests, on the other you are talking to a database, maybe some other networked APIs. A caching layer picks up plenty of load - how often is the program really cpu-bound here? For me fastAPI [0] and async Python call the performance statements into question; good to run some benchmarks with real world use cases [0] https://fastapi.tiangolo.com/async/ https://fastapi.tiangolo.com/async/

hsn915 5y ago
I'm confused by "I/O heavy applications". This is a reality: I can server thousands of concurrent connections using a single machine in a server program written in Go. Can you do the same thing in Python or Ruby? No. Something to be noted: when your host language is slow (like Python) you almost have no choice but to make your application I/O heavy. What do I mean? Your application needs feature X. Your choices: - Implement X in your codebase. - Run a separate program XY that sort of does X, host it on the same or a different machine, and let your actual program talk to XY over a socket connection. When I write in Go, I just implement X in my program. No I/O, just regular code. When you write in Python, this option is out the window, so you have no choice but to run XY and talk to it over a socket. An easy to understand example is a cache. In Go I can just cache things in memory. In your python project you have to use Redis. So it looks to you like the problem domain is inherenty I/O heavy. Yes there's a lot of I/O involved, but that's mostly: - TCP connections from clients (HTTP) - Saving data to permanent storage Another thing you can do when you write in Go vs Python is you can move computations from the database server to your own code. See, there's this thing that happens in Python code where, because your host language is slow, you lean heavily on your (Postgres?) database to pull up the heavy weight. So what happens? Your database becomes a bottle neck. A lot of the heavy computations that you push to your database can be performed a lot faster in your own code base .... if only you weren't hosting yourself in a slow language. This is not some theoretical bullshit. I've seen this manifest in real world applications.

hsn915 5y ago

I'm confused by "I/O heavy applications". This is a reality: I can server thousands of concurrent connections using a single machine in a server program written in Go. Can you do the same thing in Python or Ruby? No. Something to be noted: when your host language is slow (like Python) you almost have no choice but to make your application I/O heavy. What do I mean? Your application needs feature X. Your choices: - Implement X in your codebase. - Run a separate program XY that sort of does X, host it on the same or a different machine, and let your actual program talk to XY over a socket connection. When I write in Go, I just implement X in my program. No I/O, just regular code. When you write in Python, this option is out the window, so you have no choice but to run XY and talk to it over a socket. An easy to understand example is a cache. In Go I can just cache things in memory. In your python project you have to use Redis. So it looks to you like the problem domain is inherenty I/O heavy. Yes there's a lot of I/O involved, but that's mostly: - TCP connections from clients (HTTP) - Saving data to permanent storage Another thing you can do when you write in Go vs Python is you can move computations from the database server to your own code. See, there's this thing that happens in Python code where, because your host language is slow, you lean heavily on your (Postgres?) database to pull up the heavy weight. So what happens? Your database becomes a bottle neck. A lot of the heavy computations that you push to your database can be performed a lot faster in your own code base .... if only you weren't hosting yourself in a slow language. This is not some theoretical bullshit. I've seen this manifest in real world applications.