4 ms·
Not intending to start a flamewar with VM/Intepreter implementations, BUT I have to agree with the article. When I was evaluating on platforms for a rewrite of
by rs 17y ago
Not intending to start a flamewar with VM/Intepreter implementations, BUT I have to agree with the article.
When I was evaluating on platforms for a rewrite of xp-dev.com, I did seriously consider using RoR with JRuby, but there was some parts missing here and there (including some bugs) that it was just not worth the risk for the scale of the project.
I ended up going back to a Java web framework, thinking, I'll keep a close eye on JRuby and see if it can be used in future projects.
The JVM is an excellent VM - things like having the ability to set heap sizes, JMX and all the readily available sugar that comes from it is well worth trying to support as many languages into it, and for that reason, Ruby needs the JVM. Re-implementing things like JIT, GC is just not worth the trouble. Ruby hackers can actually focus on real, hard productive features and essential bug fixes which would be a better use of their precious time.
* JVM here refers to Sun's JVM implementation, not the spec. JRockit is pretty good as well.
- michaelneale 17y ago>things like having the ability to set heap sizes Oh that has always irritated me, and others - having to know what to set it to up front - interesting that you like it?
- rs 17y agoI don't think it's "having to know what to set it to up front" - its more experimentation and seeing what has the best performance. Too big heap and poor code, you might end up having really, really long GC pauses. Too small heap and you'll be out of heap space. I like it as there's only so much physical memory on a server, and there's only so much virtual memory a kernel can provide. Swapping is not a good idea if you're looking into performance, and hence limiting the heap size can turn out to be a good strategy to ensure that your application does perform within expected boundries.