Response to "Maglev and the naiivety of the Rails community" from Patrick Collison | Hacker News Reader

Response to "Maglev and the naiivety of the Rails community" from Patrick Collison

collison.ie

43 pointsicey11 comments

This sure has a lot of upmods for zero comments. Nothing against pc, but is this really that spectacular of a blog post? It's like the 10th MagLev response on the front page lately, and doesn't add too much to the discussion other than a quick comparison to Common LISP.

The hype build-up continues. Note how a friend of MagLev devs points out that it's "up to 60x", which technically could mean anything including "60x for one specific case and 1x for the rest of them". With claims that are this wishy-washy, the only sensible option is to wait for the benchmarks of the public release. Anything else merely fuels the hype machine.

(edit) Hmm, interesting .. getting down-modded. I guess independent benchmarking is no longer a preferred way of confirming rather bold vendor claims.

You should be skeptical of vendor benchmarks. But being ignorant of how far VM technologies have come and how far Ruby has left to go is not excusable. (Or more importantly, not being self-aware enough to figure out what you don't know, then having the bad luck to get posted on social news.)

In any case, most of the time it matters more to programmer's egos now than anything else. CPython is already fast enough for low-level bitwise operations on large amounts of data, provided you are clever with optimizing and you're willing to implement key routines in C. Just look at Mercurial! It's in the same league as Git for speed, and Git is written entirely in C by one of the best C hackers around.

Note how a friend of MagLev devs points out that it's "up to 60x", which technically could mean anything including "60x for one specific case and 1x for the rest of them"

No; you're intentionally distorting things. "Up to 60x" is a quote from Sho's piece, and I just pointed out that he uses this claim inconsistently.

Later in the piece, I note that I don't know if MagLev will be even 10x faster when released.

Collison only mentions 'up to 60x' in a parenthetical about Fukamachi's distortions. To note that tiny bit, as if it's a 'wishy-washy' hyped claim (as opposed to just a clarification of the original presentation) is equally distorting.

Also, the point of Fukamachi's critics is that the MagLev claims aren't "rather bold" at all, given the well-established performance of other Ruby-like language environments. Some doubt is healthy. Vigorously doubting things well-known to the dynamic languages community is sophomoric.

The upvotes for this item reflect pent-up demand for downvotes on the original 'naiivety' article.

I find the transparent persistence and caching much more interesting. I wonder if you can transparently persist closures and continuations. If so you can do some really neat things.

I find it much more interesting as well. And yes, you can - I showed persisting a closure at the demo, and Gemstone persists continuations as a matter of course in their Seaside port.

That's awesome. I'll definitely give it a try then.

I'm just not interested in closed source low-level infrastructure (like programming languages) if I can possibly help it. Look at how much trouble that caused with Java... no thanks.

The situation with Java is very different. The language itself is not owned by a corporation. There is no need for a "clean room reimplementation," as was necessary for Java.

Also, Avi's trick with Gemstone/S can also be replicated with any other commercial Smalltalk. It can also be replicated with the now Open Source Strongtalk VM, which is a Smalltalk VM as fast as the the commercial ones.

And when YARV is ready to put under apps like Rails the Ruby community will have another VM as fast as the commercial Smalltalk JITs.

Reply on news.ycombinator.com