Yes, Python is Slow, and I Don’t Care

You can use comment annotations to typecheck with mypy in py2

At this point, I would find it far easier to believe that you are underestimating the difficulty involved in what it takes to speed up Python than that there are enormous gains yet to be had in speeding up Python. I suspect JS has had more optimization effort expended overall, but Python has still had a ton of work by lots of smart people, and generally got an earlier head start on optimization. (They didn't start trying to make JS "fast" right away; they spent rather a lot of time getting JS's hookup to the DOM in the face of things like .innerHTML working first, before anyone even cared to do what we today do routinely without thought in plain ol' Javascript, let alone with our glorious frameworks.)

There are enormous gains to be had in speeding up "a language that is like Python except certain things are banned", but people have already done that analysis too and discovered that broadly speaking, if you do that, too much existing Python breaks. If you want to see something like that, check out the RPython aspect of the PyPy project, which successfully implements a fast subset of Python. But it is a noticeably restricted subset of Python; AIUI it's not even close to something you can just drop in to your code and get faster speeds.

One of the things that I've learned from Python and the other attempts to speed up the scripting languages is that despite the mantra, yes, there is in practice such a thing as an intrinsically slow language. (The theoretical existence of a Python interpreter that can run all existing Python code at C speeds doesn't do us much good if we have no idea after decades of very smart people banging on the problem how to manifest it. Personally I'd suspect that while such a beast theoretically exists it has an exponential complexity startup cost or, if you prefer, exponential compilation costs. And probably a pretty decent code and/or RAM bloat cost, too.) And Python is one of them. Some of the reasons why it is so much fun to use are part of that intrinsic slowness. Some of them really aren't.

I personally think there's a lot of up-and-coming languages that are exploring the space of how to get those nicer programming abstractions and programmer-convenient code without paying anywhere near the runtime cost that the dynamic scripting languages of today do; it's one of the more exciting developments I see coming up. People complain a lot about code bloat and poor performance of our code since right now we have to choose between "fairly inconvenient but fast" and "convenient but slow and bloated". Patience! Better choices are developing, but they're still young.

Do you or anyone on your python using team can use C professionally for things you'll use in production?

I work with python everyday on a team that uses python everyday, and I worked professionally in C++ for a >2 years time, and I still wouldn't trust myself to write a reliable/safe C backend to something.

And using C++ behind python with something like pybind11 is anything but painless on the other end; it requires careful consideration.

Python is "good enough" in nearly all cases, but there are some instances where you sort of hate yourself for using it for the prototype since you're forced to effectively rewrite afterwards.

"Statically type languages prevent a lot of bugs and allow for a lot of automated provably correct refactorings that simple cannot be done with a statically typed languages." -- not true, Clojure is trying to do that with Clojure.spec and specifications being checked at runtime can get you closer to things you could have automatically proved correct only with languages with dependent types, nothing against statically typed languages but I feel that your sweeping generalizations hurt the point you are trying to make.