10 ms·

The dynamic languages slower than ruby prediction didn't hold up either. The past ten years have just seen nibbling around the edges for dynamic languages, with

The dynamic languages slower than ruby prediction didn't hold up either. The past ten years have just seen nibbling around the edges for dynamic languages, without any compelling ideas about how to make them fundamentally more expressive.

wycy 7y ago
Doesn’t that describe the rise of JavaScript? I haven’t done or seen any specific benchmarks, but I gathered that JS was among the slowest of languages.
- ratww 7y ago
  No, it's pretty fast [1]. Chrome and V8 were released in 2008, and Node.js (which leverages V8) in 2009. V8 was already considered fast back then. Mozilla and Apple also focused on optimizing their JS stack in the following years. [1] I'm not a fan of linking to benchmarks, but that's the best I can do: https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/node-yarv.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... / https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/javascript.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
  - mattmanser 7y ago
    No, it really wasn't. You had to use it in really specific ways and it had all sorts of gotchas. One I vaguely remember is that if an array got too big performance would tank like crazy.
  - jashmatthews 7y ago
    Google’s marketing for Chrome and V8 was incredibly effective. We’ve basically forgotten that Mozilla, Adobe and Apple were pushing JS perf long before V8 was released. Memory usage of early V8 was atrocious and real world performance was barely improved over Safari and Firefox but Google dominated dev mindshare for a decade.
    - kragen 7y ago
      No, Mozilla and Apple didn't release their JIT engines until after Chrome (though I think at least Apple was working on theirs) and so when Chrome came out JS immediately got about 4x faster, which was a bigger improvement than had happened over the entire previous lifetime of JS. Popular web pages didn't immediately get 4x faster, because they had carefully avoided doing anything in JS if its performance mattered, but JS did. It's true that V8 used a ridiculous amount of RAM, and still does, but its existence made it possible to do things in JS that previously required native code. As for Adobe, they never did much for JS; they tried to get people to use ActionScript instead, which was a statically-typed language with syntactic similarities to JS.
      - jashmatthews 7y ago
        Apple built the Sunspider benchmarks in 2007, and along with Mozilla, they made dramatic real world performance improvements before Chrome was even publicly announced. https://webkit.org/blog/152/announcing-sunspider-09/ https://webkit.org/blog/152/announcing-sunspider-09/ https://webkit.org/blog/214/introducing-squirrelfish-extreme/ https://webkit.org/blog/214/introducing-squirrelfish-extreme... Chrome + V8 was already behind in real world performance, not ahead! http://www.satine.org/archives/2008/09/19/squirrelfish-extreme-fastest-javascript-engine-yet/ http://www.satine.org/archives/2008/09/19/squirrelfish-extre... Macromedia (later Adobe) funded a whole bunch of JIT research as the Tamarin Tracing project, which was shared with Firefox as TraceMonkey. The NanoJIT assembly backend was actually shared code.
        kragen 7y ago
        I guess you're right that TraceMonkey was announced before Chrome was released on 2007-09-02, one day after its inadvertent public announcement. TraceMonkey was announced, though incomplete, more than a week earlier, 2008-08-23: https://brendaneich.com/2008/08/tracemonkey-javascript-lightspeed/ https://brendaneich.com/2008/08/tracemonkey-javascript-light.... SFX, however, was announced later, 2008-09-18. I don't want to piss too much on SunSpider, but unsurprisingly V8 did better on V8’s benchmarks, while SFX and TM did better on SunSpider, once they were eventually released. That's because V8 was written to do well on its benchmarks, presumably, not because the benchmarks were rigged. Certainly they were in accordance with my experience at the time. When Chrome was released, V8 was way ahead of the other browser JS engines at JS performance, partly because it had the first JS JIT. But the other browsers took a year or two to catch up, which they had because it also took websites a few years to move most of their functionality into browser JS. I don't know why you keep emphasizing this “real-world” thing. Are you saying you think nbody and fannkuch are especially realistic benchmarks? You're right though that Tamarin was a JS engine, not just an AS engine. We regret the error.
- kibwen 7y ago
  JS is pretty much the fastest of the popular dynamic langs, if only because JS interpreters see highly-competitive investment from well-funded companies with armies of developers thanks to the web.
- hyperpape 7y ago
  Like others have said, major Javascript engines are much than Ruby implementations, owing to the huge effort Firefox, Google, Apple, and Microsoft have put into those engines. In principle, I'm not sure if there's reasons that make one intrinsically harder to optimize. But even if Javascript were slower, it wouldn't mean the prediction was right. Javascript didn't do something super amazing that let you write beautiful code (the way Rubyists feel about Ruby, or Python folks feel about Python). It just ran the web so we used it. Over time, it's morphed into a language that's about as expressive as any other good dynamic language, also with some warts. But it's not a leap ahead, which is what the original post predicted. The only language I've felt that way about was Prolog. When it works right, it's amazing. Too bad I can rarely make that happen.
  - jaggirs 7y ago
    I am convinced there has to be a way to leverage the expressive power of a language like pure prolog without the strain of the 'hints' you need to give it when the depth-first algorithm can't solve the problem. My bet is that if the interpreter 'knows' enough algorithms to solve common calculations, it could leverage these to compute 90% of problems (without needing to have one algorithm for each problem). For the other 10% you would have to supply the interpreter with the necessary algorithms yourself.
- lern_too_spel 7y ago
  JavaScript is now both faster and less productive than Ruby, so it doesn't match his prediction that a slower and more productive language will become popular.
  - goatlover 7y ago
    What it does show is that being a web standard trumps everything else.
- rsynnott 7y ago
  Applications written in JavaScript tend to be hideously slow (and getting worse) but this is more of a community problem; the language itself is now rather fast by dynamic language standards.
- austincheney 7y ago
  Did anybody predict the slow death of jQuery or the rise of giant monster JavaScript frameworks? 2010 is when jQuery was a cult of personality. It was everywhere and any criticism of it was quickly met with desperate mob violence. Did anybody predict a typical corporate web page would require 3gb of JavaScript code from frameworks and thousands of foreign packages just to write a couple of instructions to screen?
jnwatson 7y ago
Python is eating the world. In many measures, Python is slower than Ruby.
- agumonkey 7y ago
  python won't last, just like ruby / js / php I sense a strong convergence between all of them (builtin DS, linguistic traits, bits of static typing)
  - MaxBarraclough 7y ago
    JavaScript will last. There's no question there at all.
- ImprovedSilence 7y ago
  I would have agreed with you in 2013. Now it's just seems so fractured and all over the place, like it's had it's peak and is on the way back down.
  - simonh 7y ago
    Sometimes fractured and all over the place is a sign of success. Python is used by a huge variety of different communities for a myriad of use cases, which is pulling it in different directions. That’s not a bad problem to have, as long as it’s managed well and the core webs seem very tuned in to this issue. Also the community migration to Python 3 is done now. Yes there are massive P2 code bases out there still, but for new projects P3 has been the clear choice for a long time now. It’s over.
- jacquesm 7y ago
  Python is just a very nice interface to a large amount of optimized C code.
  - Dylan16807 7y ago
    Don't neglect the Fortran code!
mntmoss 7y ago
Raku (formerly Perl 6) basically sits alone as the successor to the slower-and-more-expressive throne. It's a great language to study for the gee-whiz-they-thought-of-everything factor. But, nobody is paying attention to it. Some of that is because of the Perl 6 baggage, but just as much is probably because this past decade was so heavily entrenched in proliferation of the web-cloud-mobile paradigm that new scripting systems weren't part of the hype cycle. If it didn't get the backing of the FAANGs, it didn't register. I can imagine a day coming where scripting shines again, though. It might actually be closer than we think. There is always a need for glue code, and glue code benefits from being a kitchen sink of built-in functionality.
- crdoconnor 7y ago
  We've reached a point where package ecosystem eclipses the importance of language features (which, in brand new languages, typically only offer incremental improvements these days). It's not good enough to build a slightly better language any more. People won't learn a new language without their favourite packages (or equivalents).
  - jaggirs 7y ago
    A solution to this is leveraging the ecosystem of another language, like elixir (erlang) and all the jvm languages do.
    - crdoconnor 7y ago
      This has a habit of creating impedance mismatch problems though.
    - goatlover 7y ago
      Julia does this by being able to call Python, R and Fortran libraries.

wycy 7y ago

Doesn’t that describe the rise of JavaScript? I haven’t done or seen any specific benchmarks, but I gathered that JS was among the slowest of languages.

ratww 7y ago
No, it's pretty fast [1]. Chrome and V8 were released in 2008, and Node.js (which leverages V8) in 2009. V8 was already considered fast back then. Mozilla and Apple also focused on optimizing their JS stack in the following years. [1] I'm not a fan of linking to benchmarks, but that's the best I can do: https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/node-yarv.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... / https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/javascript.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
- mattmanser 7y ago
  No, it really wasn't. You had to use it in really specific ways and it had all sorts of gotchas. One I vaguely remember is that if an array got too big performance would tank like crazy.
- jashmatthews 7y ago
  Google’s marketing for Chrome and V8 was incredibly effective. We’ve basically forgotten that Mozilla, Adobe and Apple were pushing JS perf long before V8 was released. Memory usage of early V8 was atrocious and real world performance was barely improved over Safari and Firefox but Google dominated dev mindshare for a decade.
  - kragen 7y ago
    No, Mozilla and Apple didn't release their JIT engines until after Chrome (though I think at least Apple was working on theirs) and so when Chrome came out JS immediately got about 4x faster, which was a bigger improvement than had happened over the entire previous lifetime of JS. Popular web pages didn't immediately get 4x faster, because they had carefully avoided doing anything in JS if its performance mattered, but JS did. It's true that V8 used a ridiculous amount of RAM, and still does, but its existence made it possible to do things in JS that previously required native code. As for Adobe, they never did much for JS; they tried to get people to use ActionScript instead, which was a statically-typed language with syntactic similarities to JS.
    - jashmatthews 7y ago
      Apple built the Sunspider benchmarks in 2007, and along with Mozilla, they made dramatic real world performance improvements before Chrome was even publicly announced. https://webkit.org/blog/152/announcing-sunspider-09/ https://webkit.org/blog/152/announcing-sunspider-09/ https://webkit.org/blog/214/introducing-squirrelfish-extreme/ https://webkit.org/blog/214/introducing-squirrelfish-extreme... Chrome + V8 was already behind in real world performance, not ahead! http://www.satine.org/archives/2008/09/19/squirrelfish-extreme-fastest-javascript-engine-yet/ http://www.satine.org/archives/2008/09/19/squirrelfish-extre... Macromedia (later Adobe) funded a whole bunch of JIT research as the Tamarin Tracing project, which was shared with Firefox as TraceMonkey. The NanoJIT assembly backend was actually shared code.
      - kragen 7y ago
        I guess you're right that TraceMonkey was announced before Chrome was released on 2007-09-02, one day after its inadvertent public announcement. TraceMonkey was announced, though incomplete, more than a week earlier, 2008-08-23: https://brendaneich.com/2008/08/tracemonkey-javascript-lightspeed/ https://brendaneich.com/2008/08/tracemonkey-javascript-light.... SFX, however, was announced later, 2008-09-18. I don't want to piss too much on SunSpider, but unsurprisingly V8 did better on V8’s benchmarks, while SFX and TM did better on SunSpider, once they were eventually released. That's because V8 was written to do well on its benchmarks, presumably, not because the benchmarks were rigged. Certainly they were in accordance with my experience at the time. When Chrome was released, V8 was way ahead of the other browser JS engines at JS performance, partly because it had the first JS JIT. But the other browsers took a year or two to catch up, which they had because it also took websites a few years to move most of their functionality into browser JS. I don't know why you keep emphasizing this “real-world” thing. Are you saying you think nbody and fannkuch are especially realistic benchmarks? You're right though that Tamarin was a JS engine, not just an AS engine. We regret the error.
kibwen 7y ago
JS is pretty much the fastest of the popular dynamic langs, if only because JS interpreters see highly-competitive investment from well-funded companies with armies of developers thanks to the web.
hyperpape 7y ago
Like others have said, major Javascript engines are much than Ruby implementations, owing to the huge effort Firefox, Google, Apple, and Microsoft have put into those engines. In principle, I'm not sure if there's reasons that make one intrinsically harder to optimize. But even if Javascript were slower, it wouldn't mean the prediction was right. Javascript didn't do something super amazing that let you write beautiful code (the way Rubyists feel about Ruby, or Python folks feel about Python). It just ran the web so we used it. Over time, it's morphed into a language that's about as expressive as any other good dynamic language, also with some warts. But it's not a leap ahead, which is what the original post predicted. The only language I've felt that way about was Prolog. When it works right, it's amazing. Too bad I can rarely make that happen.
- jaggirs 7y ago
  I am convinced there has to be a way to leverage the expressive power of a language like pure prolog without the strain of the 'hints' you need to give it when the depth-first algorithm can't solve the problem. My bet is that if the interpreter 'knows' enough algorithms to solve common calculations, it could leverage these to compute 90% of problems (without needing to have one algorithm for each problem). For the other 10% you would have to supply the interpreter with the necessary algorithms yourself.
lern_too_spel 7y ago
JavaScript is now both faster and less productive than Ruby, so it doesn't match his prediction that a slower and more productive language will become popular.
- goatlover 7y ago
  What it does show is that being a web standard trumps everything else.
rsynnott 7y ago
Applications written in JavaScript tend to be hideously slow (and getting worse) but this is more of a community problem; the language itself is now rather fast by dynamic language standards.
austincheney 7y ago
Did anybody predict the slow death of jQuery or the rise of giant monster JavaScript frameworks? 2010 is when jQuery was a cult of personality. It was everywhere and any criticism of it was quickly met with desperate mob violence. Did anybody predict a typical corporate web page would require 3gb of JavaScript code from frameworks and thousands of foreign packages just to write a couple of instructions to screen?

jnwatson 7y ago

Python is eating the world. In many measures, Python is slower than Ruby.

agumonkey 7y ago
python won't last, just like ruby / js / php I sense a strong convergence between all of them (builtin DS, linguistic traits, bits of static typing)
- MaxBarraclough 7y ago
  JavaScript will last. There's no question there at all.
ImprovedSilence 7y ago
I would have agreed with you in 2013. Now it's just seems so fractured and all over the place, like it's had it's peak and is on the way back down.
- simonh 7y ago
  Sometimes fractured and all over the place is a sign of success. Python is used by a huge variety of different communities for a myriad of use cases, which is pulling it in different directions. That’s not a bad problem to have, as long as it’s managed well and the core webs seem very tuned in to this issue. Also the community migration to Python 3 is done now. Yes there are massive P2 code bases out there still, but for new projects P3 has been the clear choice for a long time now. It’s over.
jacquesm 7y ago
Python is just a very nice interface to a large amount of optimized C code.
- Dylan16807 7y ago
  Don't neglect the Fortran code!

mntmoss 7y ago

Raku (formerly Perl 6) basically sits alone as the successor to the slower-and-more-expressive throne. It's a great language to study for the gee-whiz-they-thought-of-everything factor. But, nobody is paying attention to it. Some of that is because of the Perl 6 baggage, but just as much is probably because this past decade was so heavily entrenched in proliferation of the web-cloud-mobile paradigm that new scripting systems weren't part of the hype cycle. If it didn't get the backing of the FAANGs, it didn't register. I can imagine a day coming where scripting shines again, though. It might actually be closer than we think. There is always a need for glue code, and glue code benefits from being a kitchen sink of built-in functionality.

crdoconnor 7y ago
We've reached a point where package ecosystem eclipses the importance of language features (which, in brand new languages, typically only offer incremental improvements these days). It's not good enough to build a slightly better language any more. People won't learn a new language without their favourite packages (or equivalents).
- jaggirs 7y ago
  A solution to this is leveraging the ecosystem of another language, like elixir (erlang) and all the jvm languages do.
  - crdoconnor 7y ago
    This has a habit of creating impedance mismatch problems though.
  - goatlover 7y ago
    Julia does this by being able to call Python, R and Fortran libraries.