From Rails to Clojure, Then to Java, Then Back to Rails

Re:From Rails to Clojure, Then to Java, Then Back to Rails by pjmlp on Wednesday March 21, 2018 @01:19PM (#16640307)

Ruby also suffers from top quality JITs vs what JS has.

The only good option being JRuby, as far as I understand. I am not at all into Ruby.

Regarding being polyglot and seniority, a possible solution is to work for consulting companies that focus on multiple stacks.

[ Parent | on HN ]

Re:From Rails to Clojure, Then to Java, Then Back to Rails by steveklabnik on Wednesday March 21, 2018 @02:21PM (#16640941)

MRI has just added a JIT, I know nothing about it other than that it exists.

[ Parent | on HN ]

Re:From Rails to Clojure, Then to Java, Then Back to Rails by jashmatthews on Wednesday March 21, 2018 @05:21PM (#16642542)

MJIT works by taking MRI Ruby bytecode, replacing the instructions with the original C code, and compiling an entire method using GCC/LLVM.

Because MRI Ruby is a threaded VM, it's easy to replace jumping to an instruction which dispatches to the next instruction, with jumping to some native code which dispatches to the next instruction.

Right now, AFAIK, only very basic optimizations are enabled but just removing the overhead of VM dispatch between each instruction is a huge performance improvement.

[ Parent | on HN ]

Re:From Rails to Clojure, Then to Java, Then Back to Rails by lloeki on Wednesday March 21, 2018 @02:12PM (#16640843)

Most of the time you're not using JRuby for the JIT but for threads and/or to fit into some Tomcat/other Java environment. JRuby isn't exactly fast.

[ Parent | on HN ]

Re:From Rails to Clojure, Then to Java, Then Back to Rails by jashmatthews on Wednesday March 21, 2018 @05:11PM (#16642458)

JRuby is now about 3x faster than MRI, thanks to improvements in JRuby and increased support from the JVM for optimizing dynamic languages like invokedynamic.

[ Parent | on HN ]