"There's are still some big gains python could make, if python implementations were better."
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.
I consider "python implementations being better" to be some simple things.
* pypy-level performance by default
* Much faster startup times (I'm looking at you namedTuple)
* Better libraries for specific use-cases, like interacting with opengl
* Rpython actually being documented so I can write library code in it
I'd also really like to see good sandboxing and fast-enough object sharing.
Those are the kinds of things I think can open up whole new market-segments. And python being used by more market-segments means more support for python.
I think the work being done on ruby with the truffle/graal project is interesting in this regard - it's my understanding that ruby is very dynamic too - but it's interesting to see what can be achieved by inclining c to ruby to c etc. It's a crazy stack, compared to something like red (redlang) - but it's amazing how close they are able to get to "magically fast compiler/runtime".
If they manage to combine tracing/warm-up with ahead-of-time compilation to executables... It'll be very interesting indeed.
Go is an early entrant into this space, but I think part of the reason it is early is also that it is less ambitious. But to answer the ever-present question on HN about "why would anyone ever use this language?", something modern, almost as easy to use as a scripting language [1], and almost as fast as a compiled language, doesn't actually have a lot of contenders. (Old fogeys... like me!... like to observe that if you drop modern you have some things like Delphi that fit that slot, but they're all pretty much dead now, and Go has good support for concurrency in the modern processor environment.)
Given the programming landscape and the general direction of things lately, I also bet there's a couple of serious contenders developing out there that haven't even hit HN yet.
[1]: For at least a broad class of problems. Put Go head-to-head with a problem someone would use NumPy for and Go will go down in flames in the ease-of-use and line count department. However I use Go for a lot of networks servers (not even necessarily Web servers, but network servers) and the line count for these comes out maybe 20% larger than Python, and it doesn't take much developer cognitive energy for those extra lines. I've also used Go for some command-line type apps where the line count is probably 50% over Python, but I also got some significant wins from the type system and concurrency, so, all in all there's a lot of things I can prototype with about the same mental effort in Go as I could in Python. Being able to declare interfaces that existing types conform to turns out to cover a surprising amount of those "duck-type" scripting-type cases.
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.