I'm not sure how much benefit a promise model can bring to a language still gimped by the GIL. Yeah you can do a few things while waiting for a http response to return, but you're still bound to a single core for work unless you fork the entire process. I only find Python appealing for smaller scripts for that reason -- something that performs tasks every so often via cron? Sure. A high-throughput web server? No.
I wouldn't say multicore processing in a single process is collectively "settled" as a good idea, as a necessary feature. Most people go "hey, yeah, more cores is more better, right?"
I think people misunderstand what it would really bring to the table that multiple processes wouldn't do easier.
The only reason it's 100% necessary is if you absolutely have to read and write data between threads/processes as fast as possible. Like, I'd want to hear an explanation for why ordinary IPC won't work before I grudgingly admit that genuine multiprocessing is necessary.
Otherwise I'd just tell you to run $cores processes and call it a day.
Promise based systems are more about how you conceptualize multiple tasks at once, rather than being a performance thing.
Also I really hate threaded code. At least situations where you're working directly with mutexes for anything more complicated than a single threadsafe queue.
I still have nightmares hunting down obscure, impossible-to-trigger deadlocks in pthreads code.
If there's a problem with Python and web development, it'd be that the overall byte interpreter is slow. Not the GIL. (But I doubt it.)
Say you have a good app server returning a cached response in 50μs, and a bad one that returns a cached response in 50ms (close-to-real example -- I'm porting a legacy PHP application to something less terrible right now). While there is little difference to the user, the bad server requires 1,000 times more effort for the server, per request. 1,000 requests later, that's 49.9 seconds of wall time wasted on a poor-performing application server. If your server is being hit very hard by a thousand users at once, this is where bottlenecks begin to appear.
Generally the language choice itself won't be the biggest issue. A good app will use layers of techniques to make shit go fast. Memcached or redis, disk caches, your slower, bulk store like mysql/postgresql, and nginx. The language interpreter itself is essentially statistical noise by that point.
This is a worst-case scenario, since PHP is a poor choice if you are building for performance due to the need to bootstrap an entire application around every incoming request, but whatever.
Well, there's php-fpm. But I hate php anyway.
The point is eventually you are going to be in a situation where you are going to build stuff that is going to span multiple servers. It's not just response time that matters, but also how much CPU and memory resources are being consumed. You could be saving hundreds, maybe thousands of dollars a month in the long run if you select your infrastructure and design your software well.
Programmers are substantially more expensive than machines. And this isn't a situation where you can just tell your programmers "lol, program better". To some extent you can, but at the end of the day, bugs happen.
You'll want the highest level language you can get, to squeeze the most value out of your programmers, especially in an emergency situation with an unexpected bug.
Unless you're outright writing ass backwards code that can't possibly run fast, I think it's an expensive mistake to prioritize machines over people.
