My implementation of Ruby, JRuby+Truffle, is as fast as V8

http://stefan-marr.de/downloads/crystal.html

Note that usually being "as fast as" a production JSVM means also proving that you can start up as fast as JSVMs do. Have you done this?

Search around for "Substrate VM". I see it referenced in some slide decks, and it's designed to make JVM startup much faster.

Here's an old slidedeck that talks about it: http://www.oracle.com/technetwork/java/jvmls2013wimmer-20140...

Wow thx for the reminder, I have forgotten about it already. I remember the promise of Truffle + Graal + Substrate VM.

My god can't believe it was 3 years ago i read about it on HN.

I know about it. I'm not concerned with future hypotheticals, but current actual measurements.

That's the currency I deal in.

There seem to be measurements in the slides I reference, so it wasn't exactly "future work". But of course it sucks that this work is not yet publicly available (AFAIK), probably due to not being 100% production ready yet. But I'm sure it's getting there.

Ruby has massive adoption, as do Python and Perl and PHP. Environments with objectively better performance like the JVM and .NET have not, in fact, done all that well comparatively in this environment (which is to say they've done fine too and achieved "massive" adoption, just not that much better than their slower competitors).

In fact, looking at the market as it stands right now I'd say that performance concerns are almost entirely uncorrelated with programming environment adoption.

Considering the massive speed improvements we have been seeing in Javascript, but also languages like Ruby, I'd say compilers is a solved problem for staticly compiled languages, but perhaps not as much for interpreted highly expressive languages.

Sort of. Lisp had a good combo of expressiveness and speed in the 80s, but it reached that point on the efficiency frontier by different techniques, like heavier use of macros. The newer techniques like trace compilation can make life even better, but the language design decisions in Ruby/Python/etc. that made that sort of thing necessary if you want speed, they didn't really pay for themselves from the perspective of smug Lisp weenies like me who were happy enough with our language and just wanted pragmatics like libraries.

Did you just call Javascript a "highly expressive" language? Really?!?

LOL! It is expressive though. It's got really powerful first-class functions. It's got classes. It's got prototypes. It's got generators. It's got other things that I don't even remember (but will probably have to learn, to implement them, make them fast, and then fix the bugs).

I actually think that the reason why JS is so odd is that it is so expressive. That tends to happen with kitchen sink languages like C++.

Relevant: "There are only two kinds of programming languages: those people always bitch about and those nobody uses."

Cool. "We took a dynamic language and made it fast(er again)".

And you're gonna apply that to the darkest corners of ES6? Whee, language theory nerd paradise!

I can't wait for the compilers targeting that using all sorts of really odd idioms that in effect work like fuzz testing.

https://www.destroyallsoftware.com/talks/the-birth-and-death...

More expressive than a less imaginative subset of C. More expressive than assembler. Much less expressive than any decent high-level language.

Javascript is low level, primitive and clumsy. There is absolutely no excuse for it being so crappy.

If you still think it is "expressive", you never seen an expressive language.

> If you still think it is "expressive", you never seen an expressive language.

Are you aware who Filip Pizlo is?

Of course - a low level guy. It is quite likely that he is either not exposed at all to any expressive languages or reject them out of ideological reasons (JikesRVM is quite a strong symptom of the latter case).

I have no idea what the Jikes RVM has to do with "ideology". The point is that you're trying to tell someone who has a significant academic and industrial PL pedigree that they don't know what an expressive language is.

You seem to have an intense dislike of JavaScript. I'll the first one to admit that JavaScript has a lot of problems. But not being expressive enough is not one of them. JS is, if anything, too dynamic and expressive.

Yes, if he thinks that JS is expressive he does not know what is expressive. And his track record clearly lacks anything related to any expressive language. I can only explain it with an ideology, because ignorance is not an option here.

And, no, JS is not expressive. It got strict limits on an available level of abstraction (unless you go into eval, of course).

ajross is right. People choose the languages they like regardless of performance.

JS perf is important to users though. Faster execution means fewer watts spent rendering and interacting with your favorite web page.

(Fun fact: B3's backend contains a machine description language that gets compiled to C++ code by a ruby script, opcode_generator.rb. We use Ruby a lot.)

Why didn't you use JavaScript for that purpose (in a similar vein to how LuaJIT uses Lua for dynasm)?

I'm not a big fan of self-hosting. I like that you can build JavaScriptCore without using JavaScriptCore.

I wasn't really referring to self hosting. I was wondering whether it made sense to write tools like JavaScriptCore's offlineasm in JavaScript rather than Ruby (as LuaJIT does by using Lua for its dynasm tool). The LuaJIT build process actually builds a cut down copy for Lua for the purposes of running dynasm, which is then used to build parts of LuaJIT.

We spend time optimizing JavaScriptCore's build time. It's a hard problem and it's important when managing such a large project. People inevitably have to do clean builds and that sucks when you have >400k lines of C++ code.

So, naturally, we want to avoid building JSC twice. ;-)

Suppose that you are developing not to push this platform, but to simple do better on this platform. What does self-hosting gain you in that case?