9 ms·

JavaScript is really lucky. Imagine having you pet language’s execution being continuously optimized for decades by the likes of Apple, Google, Microsoft and Mo

JavaScript is really lucky. Imagine having you pet language’s execution being continuously optimized for decades by the likes of Apple, Google, Microsoft and Mozilla. The amount of brainpower that has gone into making JavaScript fast is amazing.

hsaliak 8y ago
The best part is that they cannot afford to stop doing that.
- tambourine_man 8y ago
  Yeah, but I think we are in the diminishing returns phase, already. I hope I'm wrong, though.
tanilama 8y ago
Well, there are multiple attempts in Python's history to make it faster, yet failed. Most noteworthy one is Unladen Swallow from Google: https://www.python.org/dev/peps/pep-3146/ https://www.python.org/dev/peps/pep-3146/ And Dropbox's now dead Pyston. While both are pretty dynamic, Python has a rich ecosystem of C-extensions, which exposes a lot of interpreter details to developers, making moving away from the CPython implementation much harder or straight impossible if compatibility is required.
- bakery2k 8y ago
  Unladen Swallow had a small fraction of the resources that Google allocated to V8, though. I think it was only worked on by a few interns. Pyston was better supported, but I think just too ambitious - IIRC it was initially intended to be a full rewrite and to be compatible with C-extensions.
  - tanilama 8y ago
    Pyston as far as I was tracking, it seems to be mainly 2 devs from Dropbox, hardly that better off. You have a point though, no company can replace javascript , the cost is straightly forbidden. But Python as mainly a backend language at the time, it can be more realistically replaced, with newer more performant alternatives like Golang, and to some extent node.js. But it has its own stronghold, which is data/ml land stuff. However, that community has gotten around with Python in its own way, either they are tolering the slowness because that happens behind the scene, or they are bypassing the performance bottleneck to c-extensions. So in the end, I guess people love complaining about Python's performance, including myself, but it never reaches the break point where they said enough is enough.
    - cbxxx 8y ago
      The number of devs is not so important. One author who is left alone from corporate BS for three years can achieve more than a collection of 10 randomly hired programmers who just disturb the lead dev.
      - woadwarrior01 8y ago
        As someone who has worked on language runtimes in a corporate environment, I believe there’s some truth to this. One successful example of this would be Mike Pall, of the LuaJIT fame.
- llukas 8y ago
  PyPy is faring pretty well in terms of performance and compatibility.
  - tanilama 8y ago
    Performance maybe, but not without gotchas. However, compatibility is certainly not: http://packages.pypy.org/ http://packages.pypy.org/ Scipy/scikit-learn/pandas/matplotlib/h5py aren't supported, and all the packages depends on them, which makes it not an option for probably the most important segment of python's user base.
    - j88439h84 8y ago
      Those packages work just fine on pypy. They just don't support Python 2.
- lazyjones 8y ago
  There is https://github.com/graalvm/graalpython https://github.com/graalvm/graalpython too, doesn’t seem to be dead yet.
- ZuLuuuuuu 8y ago
  Would it help making it more cross-interpreter if new Python extensions who communicate with C code were written using the standard ctypes package instead of C-extensions which depends on CPython implementation? Or even porting the existing extensions? Would this be technically possible?
- sametmax 8y ago
  The amount of ressource can't be compared. Hundred of millions have been poured at chrome, ie and firefox. The best specialists in the world in the field of interpretters and JIT worked on them. For years. The Python projects were mostly personnal initiatives approved by the companies.
amelius 8y ago
At least Python has multithreading (even though it has the GIL). JavaScript only has some kind of decoupled worker processes that can communicate only through a narrow message channel, or through a low level shared memory array.
- pjmlp 8y ago
  Worklets are going to add more paralelism to JavaScript.
  - amelius 8y ago
    Their usefulness is very restricted. What we want instead is: - general concurrency - access to any (garbage collected) JS variable/object from any thread. - a garbage collector that works across all threads. - no global locking of threads by the runtime system
    - jnwatson 8y ago
      And then you get into the problem that Python has. The reason why Python has the GIL is that all of those things are really hard to do right in a performant way. I think JS is making the right call here: a small subset just to engage the extra cores.
eadmund 8y ago
> The amount of brainpower that has gone into making JavaScript fast is amazing. It really is, and it really makes me sad that the manpower wasn't instead invested in a better underlying language. If only Eich had been allowed to implement a Scheme for Netscape Navigator! I really dislike Scheme (it's under-specified, and has some poor design decisions like a single namespace), but having a homoiconic language available within every browser in the world would have been amazing. The manager who squashed that is single-handedly responsible for setting back the development of computing by at least twenty years (and more likely thirty, since I predict that it'll be at least another decade before we're able to escape the JavaScript rut).

hsaliak 8y ago

The best part is that they cannot afford to stop doing that.

tambourine_man 8y ago
Yeah, but I think we are in the diminishing returns phase, already. I hope I'm wrong, though.

tanilama 8y ago

Well, there are multiple attempts in Python's history to make it faster, yet failed. Most noteworthy one is Unladen Swallow from Google: https://www.python.org/dev/peps/pep-3146/ https://www.python.org/dev/peps/pep-3146/ And Dropbox's now dead Pyston. While both are pretty dynamic, Python has a rich ecosystem of C-extensions, which exposes a lot of interpreter details to developers, making moving away from the CPython implementation much harder or straight impossible if compatibility is required.

bakery2k 8y ago
Unladen Swallow had a small fraction of the resources that Google allocated to V8, though. I think it was only worked on by a few interns. Pyston was better supported, but I think just too ambitious - IIRC it was initially intended to be a full rewrite and to be compatible with C-extensions.
- tanilama 8y ago
  Pyston as far as I was tracking, it seems to be mainly 2 devs from Dropbox, hardly that better off. You have a point though, no company can replace javascript , the cost is straightly forbidden. But Python as mainly a backend language at the time, it can be more realistically replaced, with newer more performant alternatives like Golang, and to some extent node.js. But it has its own stronghold, which is data/ml land stuff. However, that community has gotten around with Python in its own way, either they are tolering the slowness because that happens behind the scene, or they are bypassing the performance bottleneck to c-extensions. So in the end, I guess people love complaining about Python's performance, including myself, but it never reaches the break point where they said enough is enough.
  - cbxxx 8y ago
    The number of devs is not so important. One author who is left alone from corporate BS for three years can achieve more than a collection of 10 randomly hired programmers who just disturb the lead dev.
    - woadwarrior01 8y ago
      As someone who has worked on language runtimes in a corporate environment, I believe there’s some truth to this. One successful example of this would be Mike Pall, of the LuaJIT fame.
llukas 8y ago
PyPy is faring pretty well in terms of performance and compatibility.
- tanilama 8y ago
  Performance maybe, but not without gotchas. However, compatibility is certainly not: http://packages.pypy.org/ http://packages.pypy.org/ Scipy/scikit-learn/pandas/matplotlib/h5py aren't supported, and all the packages depends on them, which makes it not an option for probably the most important segment of python's user base.
  - j88439h84 8y ago
    Those packages work just fine on pypy. They just don't support Python 2.
lazyjones 8y ago
There is https://github.com/graalvm/graalpython https://github.com/graalvm/graalpython too, doesn’t seem to be dead yet.
ZuLuuuuuu 8y ago
Would it help making it more cross-interpreter if new Python extensions who communicate with C code were written using the standard ctypes package instead of C-extensions which depends on CPython implementation? Or even porting the existing extensions? Would this be technically possible?
sametmax 8y ago
The amount of ressource can't be compared. Hundred of millions have been poured at chrome, ie and firefox. The best specialists in the world in the field of interpretters and JIT worked on them. For years. The Python projects were mostly personnal initiatives approved by the companies.

amelius 8y ago

At least Python has multithreading (even though it has the GIL). JavaScript only has some kind of decoupled worker processes that can communicate only through a narrow message channel, or through a low level shared memory array.

pjmlp 8y ago
Worklets are going to add more paralelism to JavaScript.
- amelius 8y ago
  Their usefulness is very restricted. What we want instead is: - general concurrency - access to any (garbage collected) JS variable/object from any thread. - a garbage collector that works across all threads. - no global locking of threads by the runtime system
  - jnwatson 8y ago
    And then you get into the problem that Python has. The reason why Python has the GIL is that all of those things are really hard to do right in a performant way. I think JS is making the right call here: a small subset just to engage the extra cores.

eadmund 8y ago

> The amount of brainpower that has gone into making JavaScript fast is amazing. It really is, and it really makes me sad that the manpower wasn't instead invested in a better underlying language. If only Eich had been allowed to implement a Scheme for Netscape Navigator! I really dislike Scheme (it's under-specified, and has some poor design decisions like a single namespace), but having a homoiconic language available within every browser in the world would have been amazing. The manager who squashed that is single-handedly responsible for setting back the development of computing by at least twenty years (and more likely thirty, since I predict that it'll be at least another decade before we're able to escape the JavaScript rut).