[obviouslygreen]

While I'm not disagreeing on the quality of Flask, "x uses y, so y must be stable" is the same kind of argument as "Facebook runs on PHP, so PHP must be blazing fast." Yeah, there are large web companies using all sorts of tech, but what else they're using alongside it and how they've adapted it to their needs make this sort of commentary questionable at best.

It's definitely nice to see other responses here that are from people who are, first hand, using Flask in high-traffic live deployments. I'd just be careful about drawing conclusions based on who has it somewhere in their stack without any context.

[coldtea]

>While I'm not disagreeing on the quality of Flask, "x uses y, so y must be stable" is the same kind of argument as "Facebook runs on PHP, so PHP must be blazing fast."

No, the argument is the same: "Facebook runs on PHP, so PHP must be stable".

Which makes sense. A base technology that holds up with half a billion users, I would call production ready.

As for fast, if you look at the most comprehensive benchmarks, PHP is more or less on par with Ruby/Python for raw speed of simple page serving, but when multiple DB connections are used in a page (which is the most common case for dynamic pages), it leaps far ahead, and reaches Servlet and Go levels of reqs/sec.

[Timothee]

Fair enough in general, but I don't think my conclusion of "Twilio's API runs on Flask => Flask is very reliable" is too far-fetched in the context of Twilio, whose whole business is their API.

To be fair to your skepticism, I have probably followed Twilio more than you've had. I seem to remember that they switched to Flask, so I don't think it was technical debt that they had to work around later on. (like it might have been the case with Facebook and PHP)

Let's say that "Twilio uses Flask for their API" answers the question "can it be used in production?" (or "is it a serious project today?"). "Should you use it in production?" is where context matters more.