3 ms·
Your reluctance to install Java on the servers you're on means you're missing out on one of the best Ruby implementations available. You'd be well served by put
by headius 15y ago
Your reluctance to install Java on the servers you're on means you're missing out on one of the best Ruby implementations available. You'd be well served by putting aside your prejudice and just giving JRuby a try.
That said, there's certainly domains where JRuby is not a great fit. C extension-heavy systems are one; because C extensions are so crippling to more modern VMs like the JVM or Rubinius, you're better off using the implementation the C API was designed for (MRI). Or if Rubinius suits your needs and C extensions work well enough, I'll recommend Rubinius over JRuby any day. I hate C extensions, or at least I hate them in the form they exist in MRI, since they're invasive and damaging to modern VM features like good GC and concurrent threads.
In any case, it's worth seeing if FFI (the Ruby API that Rubinius pioneered and JRuby made generally available) serves your purposes, because it works extremely well in JRuby and requires no C extension support. And I'd suggest you actually give JRuby a try; it's so much more than "Ruby for Java interop" and may work better as a "plain old Ruby impl" than you expect.
- tptacek 15y agoI just used JRuby FFI to implement a native x86-64 debugger on WinAPI; we had x86 working for a long time on Win32, Linux, and OSX using MRI, and JRuby was actually the only way to get around LP64 issues with MRI. JRuby has been a compat and native code win for us; it is a better platform for accessing C code than MRI Ruby is.
- headius 15y agoThat's great to hear! Given that FFI is intended to work across all Ruby impls, I wish there were more attention paid to using FFI instead of C extensions. I will admit there are some usability problems, especially around cross-platform struct mapping, but the resulting libraries are vastly easier to deal with than a bunch of grotty Ruby C API code.
- enebo 15y agoWe have had other JRuby users state that most 64 bit stuff just works with JRuby and not so much with MRI. Thanks for sharing another example.
- abrandoned 15y agoHuge fan of FFI (I use it to wrap/test all my shared libraries, mysql ext, etc..), but the problem of cross platform compilation still exists. I write a shared library and an FFI interface, but packaging it for use on Windows/*nix is still a pain (for compilation during install). Is there anything that solves for compilation across implementations and platforms? (FFI makes the interface simple after that)
- tptacek 15y agoI don't think we should have to sign up for coupling with a specific Ruby's runtime internals just to get cross-platform compilation of a shared library. For whatever it's worth, even autoconf can be made to work cross-platform.
- headius 15y agoYeah, for that I don't have a solution. It seems like there ought to be a way to have FFI libraries bring along the lib they need and compile it right there, but portable C libs are still a bitch to manage across platforms no matter what you do. I hate to say it, but JVM libraries have a huge advantage here; most JRuby-specific libs that ship a jar file just work on any platform with no recompile and no portability issues. Hard to beat that :(
- jvoorhis 15y agoJRuby's FFI implementation is great, but I've had about as much success with MRI, so I test my FFI libs on MRI 1.8.7, 1.9.2 and the latest JRuby. I'm looking forward to the day when Rubinius' FFI converges with the other implementations.