Headius on FFI

As usual Headius is the shit

FFI stands for Foreign Function Interface. FFI has been implemented in various libraries; one of them, libffi, actually serves as the core of JNA, allowing Java code to load and call arbitrary C libraries. libffi allows code to load a library by name, retrieve a pointer to a function within that library, and invoke it, all without static bindings, header files, or any compile phase.

Take that SWIG! Although IIRC, .NET (including Mono) had some this sort of coolness as well.

To break it down

A simple FFI script calling the C "getpid" function:

require 'ffi'

module GetPid
  extend FFI::Library

  attach_function :getpid, [], :uint
end

Nanite: Ruby Cloud Computing

Over on Ruby Inside Peter blogs on Nanite which really looks interesting -- not that I'll have any time to play around with it anytime soon.

Ruby HTTP Client Performance

Courtesy of Ruby Inside there is a pretty interesting analysis of Ruby 1.8.x client performance

Ruby’s Net::HTTP implementation blows. It’s a bit better in 1.8.7 with the new 16K buffer size, but the timeout implementation has got to go. Even with timeout eliminated, Net::HTTP is trounced by the pure-Ruby rfuzz and the native/Ruby blend curb, suggesting that timeout notwithstanding, there are other inefficiencies in Net::HTTP. Looking at the protocol.rb code, I’m struck by how painfully inefficient the implementation is with buffers. rfuzz and curb minimize buffer copies and my rfuzz streaming HTTP extension reuses the same buffer for multiple calls, while Net::HTTP is happily appending and sliceing away at arrays.

Headius and the Elephant

At Cisco we used to have the phrase "No Technology Religion" on our badges and although this is easier said than done, it is the thought that counts (to double up on cliches).

It is the religious fervor (intolerance of diversity and the belief in one path to enlightenment vs. many ways to climb the mountain) that seems to be one of the differences. between between the Python & Ruby communities:

The is illustrated in the The Elephant from earlier this month:

I don't see this in the Python community, for example, which might surprise some Rubyists. Pythonistas seem to have positively embraced both IronPython and Jython. There's no side-chatter at the conferences about the evils of anything with a J in it. There's no mocking slides, no jokes at Jython or IronPython developers' expense. No "Python elite" cliques actively working to shut Jython or IronPython out, or to discourage others from considering them. The community as a whole--Guido included--seems to be genuinely thankful for implementation diversity. Even if one of them does have a J in it.

Matasano on Ruby Vuln Handling

A must read if you need something to be angry about.

Developers relying on any of these frameworks are then faced with a difficult choice: wait an indeterminate amount of time for a good release from the official maintainers (and remain vulnerable in the meantime), or apply a patch from a third-party which may not plug all the security holes, or may include unforeseen bugs. This is clearly a problem. In the meantime maintainers have to scramble to get ruby back to a good state that actually plugs the holes while people complain. Everyone loses.

21 Ruby Tricks

Haven't blogged here forever (mostly using Python these days, although I did break into some JRuby a couple of weeks back to avoid Java coding) but definitely check out 21 Ruby Tricks from Peter Cooper.

Regex, Array Joins, file operations, and more
Good stuff..

Headius on the Peril

The Promise and Peril of Alternative Implementations is a must read, if only for his detailed summary of the Ruby implementations out there, but on the peril's:


JRuby

Compatibility is *hard*. I'm not talking a little hard, I'm talking monumentally hard. Ruby is a very flexible, complicated language to implement, and it ships with a number of very flexible, complicated core class implementations. Very little exists in the way of specifications and test kits, so what we've done with JRuby we've done by stitching together every suite we could find. And after all this time, we still have known bugs and weekly reports of minor incompatibilities. I don't think an alternative implementation can ever truly become "compatible" as much as "more compatible". We're certainly the most compatible alternative impl, and even now we've got our hands full fixing bugs. Then there's Ruby 1.9 support, coming up probably in JRuby 1.2ish. Another adventure.

IronRuby

But there's some peril here too. IronRuby is largely still being developed in a vacuum. Perhaps in order to have secrets to announce at "the next big conference" or perhaps because Microsoft's own policies require it, IronRuby's development process proceeds largely from all-internal commits, all-internal discussions, and all-internal emails that periodically result in a blob of code tossed over the fence to external contributors. The OSS story has improved, since those of us on the outside can actually get access to the code, but the necessary two-way street still isn't there. That's going to slow progress, and eventually could make it impossible for IronRuby to keep up as resources are moved to other projects at Microsoft. JRuby has managed to sustain for as long as it has with only two fulltime developers entirely because of our community and openness, and indeed JRuby would never have been possible without a fully OSS process.

Say I wonder if anyone has written a Ruby implementation in Python, hehe

Have you started working on your Ruby implementation yet? All the cool kids are doing it. It's remarkable how many implementations of Ruby are in the works right now. It remains to be seen whether the ecosystem can support such diversity in the long term, but at the very least they're introducing splendid variation. And there's a lot more to do with Ruby in terms of performance, scaling, and "getting things done". Ruby's future is looking bright, in no small part due to the many implementations. How's your favorite language looking?