A bit of history
Over two months ago I’ve put on GitHub repository with first commits for RuDy, exactly on the day when my first very basic Ruby extension written in D worked. That was a culmination of few previous months gathering some data, emailing with Kirk McDonald (author of PyD) about challenges to come and features to implement, converting .h files to .d and generally pushing towards this first successful run.
This first successful (compiling and running) extension was the first milestone of RuDy and a sign that this indeed might work; The day after setting up a github project I’ve submitted a talk topic on this year’s EuRuKo to tell about and show the RuDy project, and to and advertise it amongst fellow rubyists — a library without an application using it is a dead library.
Shortly after the blog post explaining the reasons of starting RuDy appeared.
Head-first
Submitting a talk about a pretty innovative and technology-glue project before it was ready to be shown was a kind of stunt I pulled out (partially) for the sake of motivating myself to work on RuDy.
There were some dangers and possibilites of failing, but Kirk helped me overcome all the obstacles in two ways. First, he did in PyD basically everything (and more) I wanted to do in RuDy, so I knew what was possible anyway and had a lot of working code to look at (and to shamelessly copypaste from). Second, and more important actually, Kirk turned out to be very friendly and helpful guy, ready to help me with problems that were blocking me (mostly due to my small knowledge of D and it’s nuances) whenever I sent him a desperate e-mail.
Another obstacle was basically around my studies: this year I’m supposed to graduate with a Msc. degree from physics and thus my thesis needed (still needs anyway) a lot of work, not to mention my everyday bill-paying job as Ruby developer. Last two months were pretty busy and what I was afraid of occured: I had only two last weeks when I could really focus on RuDy and prepare it for prime-time and announcement at EuRuKo.
Current state
But it worked.
Every single hour of writing D code for RuDy was actually a pleasure and motivator for spending another hours. Everything just worked as expected (there were really a few bugs that made it past compiler — and they were caught by unit tests) and that was a delightful experience. That was a deja vu — last time I’ve been seriously programming in D (simple yet funny physical simulations) made me feel the same. I’ve been coding furiously for the last two weeks (and the last one was completely crazy in that regard) and even took some days off at work to have more time for RuDy.
Now I’m 12 hours before plane from Warsaw takes off and RuDy is nowhere near PyD in terms of features, but complete just enough to show at EuRuKo and inspire fellow developers. Everything I’ve been working on is fully covered with unit tests, so shall any bug arise, a failing test case will be everything that’s needed. Test coverage also eases (and lets me postpone) writing a sensible documentation for the whole library, a task left for the times RuDy matures and stabilizes a bit.
Future shock
I’m still nervous about showing it on Euruko. I have a lot of confidence in it, but due to time constraints I won’t be showing “live” code compilation and running (OK, maybe I will show Dexter, the test application) and limit myself to code snippets in the talk. Not that I have problems with self esteem, but stumbling upon a runtime failure — when everything’s been working and developing so smoothly during the last two weeks — would probably break me down.
I also hope it’s going to attract some enthusiastic developers and I won’t be the sole developer, tester and user of RuDy. This project is too promising and inspiring (yeah, in my opinion, but a few programmer friends confirmed that) to be left unused and I definitely need someone that would be the end-user of the lib for suggestions about shape and convenience of the API. I’ve been shaping RuDy onto library I’d like to (and I surely will) use myself, but “parent’s bias” is something I want to avoid.
For sure there’re going to be questions I can imagine asking after such talk. “Why bother when there’s FFI and inline gem” — well, I don’t personally like how inline and FFI separate me from the generated code and I haven’t seen anything bigger than example-apps written using it (I think it may also be pretty hard to do it). I still like how they ease writing small code snippets in C and do the variable to-and-fro conversions. “What about JRuby, you can’t link D with that” — yes, but D is closer to Java than C and thus it’d be a lot easier to port code from D to Java (all the class-relation design stays the same). “What about garbage collectors of D and Ruby, aren’t they going to conflict with themselves?” — that’s the smartest question I could think about and the honest answer is “I don’t know, it needs to be thoroughly tested. Python’s GC do conflict with D’s GC and that’s why PyD has some code to prevent that — I have some of that code copypasted in RuDy, but commented out until the need arises”.
RuDy is a fun project that hopes to become used by Ruby developers feeling frustrated by C (malloc, free, segfault) every time they have to write a native extension. It’s also my first innovative, full-featured and started Free Software / Open Source project, so enthusiasm won’t wear off soon. I hope it takes off!
I’m taking off in a few hours.