Can anyone explain why sub-interpreters are so much faster than multiprocessing? The demo cited in the OP reports a 25x speedup on a CPU bound web services. I can find comments from 2017 [1] predicting that sub-interpreters will be similar to multi-processing but require less overhead from the OS for inter-process-communication, but I find it hard to believe this is the cause of such a large speed up, except in a contrived example. [1] https://mail.python.org/piperm...

> abysmal performance "The performance of uvloop-based asyncio [Python async networking/webserver] is close to that of Go programs." https://magic.io/blog/uvloop-b...

This is simply wrong. No you do not. I've migrated hundreds of projects through every python transition from 2.6 to 3.7, and never had these problems. I say this with sympathy, not condemnation, because we've all been there in one topic or another, but you must be doing it wrong.

You do know that 'go' is moving to a backwards incompatible version 2.0, right? https://blog.golang.org/toward...

>Do you believe rehabilitation is impossible or do you want revenge?

I don't believe that someone who commits mass murder can be rehabilitated, no. It isn't about revenge; it's about public safety.

Someone once pointed out that hoping a rapist gets raped in prison isn't a victory for his victim(s), because it somehow gives him what he had coming to him, but it's actually a victory for rape and violence. I wish I could remember who said that, because they are right. The score doesn't go Rapist: 1 World: 1. It goes Rape: 2.

What this man did is unspeakable, and he absolutely deserves to spend the rest of his life in prison. If he needs to be kept away from other prisoners as a safety issue, there are ways to do that without keeping him in solitary confinement, which has been shown conclusively to be profoundly cruel and harmful.

Putting him in solitary confinement, as a punitive measure, is not a victory for the good people in the world. It's a victory for inhumane treatment of human beings. This ruling is, in my opinion, very good and very strong for human rights, *precisely* because it was brought by such a despicable and horrible person. It affirms that all of us have basic human rights, even the absolute worst of us on this planet.

This is precisely why I lost all interest in Oculus the instant I heard that it had been acquired by Facebook.

This is good advice, and gives me an opportunity to speak to the community at large: some of us who go to cons and are in a position to shake tons of hands politely decline. It's not because we're being dicks, it's because we know it's a good way to substantially decrease our chances of catching and spreading any germs.

I played the PAX Pandemic game, where the Enforcers handed out stickers to attendees that read [Carrier] [Infected] or [Immune] (There was also a [Patient Zero].

I got the [Immune] sticker, and by the time I got home on Monday, it was clear that I had the flu. I've had a fever between 100 and 104 all week that finally broke last night, but I'm going to the doctor today because I think whatever I had settled into my lungs. I'll tell him about the H1N1 outbreak and get tested if he wants to run the test, but at this point I think it's safe to assume that I was [Immune] to the Pig Plague, but definitely [Infected] with the damn PAX pox.

Even though it's been a week of misery, it was entirely worth it, and I don't regret going to PAX for a single second.

> It must be a small challenge involving a relatively simple task.

I think an interesting point is that, for problems larger than small, well-defined tasks (ie. any real world project), then the speed advantages or disadvantages of the language start to get swamped by the choice of algorithms.

I spent some time working through the small programming challenges at projecteuler.net. It is worth noting that the submitted solutions by users, in many languages, vary in execution time over many orders of magnitude, and my casual inspection seemed to show that the thing that correlated with fastest execution speed was not choice of language, but choice of algorithm.

The programmers submitting solutions are amongst the set who are voluntarily spending their own time to do this - hence while they aren't the best programmers out there, they also probably aren't the worst.

My conclusion is that if you can afford to get a good programmer to spend all day optimising a small bit of code, then yes C is going to be fastest. But as soon as the problem gets larger, or as development time is reduced to more normal proportions, then most half-decent programmers choice of non-obviously sub-optimal algorithms is going to swamp that. A high level language that supports discovery and implementation of the right algorithm, by giving the programmer less low-level detail and fewer lines of code to worry about, is going to claw back some ground.

This matches with my own experience of Python. People expect that performance will be terrible, and when we measure it in benchmarks, it is terrible. But in real-world projects, it is great. So what's going on?

This is why my motto (and fundamental rule for life) is Don't be a dick: it's simple to understand, and reasonable people can agree on what it means.

I think that pdq332 is asserting that VB would be very popular. In which he would be correct. He makes no judgement about how 'good' it is.