RubyFlux: a Ruby to Java compiler

https://github.com/headius/rubyflux

by neXter • 14 years ago

112 39 14 years ago

github.com

RyanZAG• 14 years ago

Quick, someone needs to complete the circle!

Compile your ruby code to java with this new compiler.

Then compile your java code to javascript with GWT https://developers.google.com/web-toolkit/

Then run your javascript inside ruby with ExecJS https://gist.github.com/4106776

Bonus points if you can make your original ruby code interact with the javascript in the ruby VM.

VeejayRampay3• 14 years ago

This is great, it's nice to see people pushing the boundaries, shaking bottles and trying to get out of the "same ol' same ol'" frame of mind from time to time.

Looking forward to more.

sublimit3• 14 years ago

Cross-language compilers aren't a particularly new concept, though. And I fail to see how this one's exactly useful, either. Seems more like an "it can be done" sort of challenge, rather than a tool people would use in everyday programming.

But since it's currently the #1 post on Hacker News, maybe people do have some use for a Ruby-to-Java compiler, so could you enlighten me?

wr1472• 14 years ago

Think of this as art - it doesn't need to have a purpose.

Or think of it as the solution to a problem yet to be discovered - isn't that how most discoveries are made?

Either way great achievement.

cookiecaper2• 14 years ago

See http://stackoverflow.com/questions/12487986/how-can-i-make-r... . The tl;dr of it is that MRI is atrocious at memory management. For political reasons we are stuck using Ruby in a situation like that; if we could easily, accurately compile that to Java and run it with with java -jar my_script.jar it'd be awesome.

VeejayRampay3• 14 years ago

Cross-language compilers are not a new concept, you're right about that. I was more enthusiastic about the fact that any person trying to offer alternatives is doing a good deed.

Whether or not this has practical applications is irrelevant for now, the project seems to be in its infancy. Nonetheless, it's a good thing that the author is trying and tackling new concepts.

taylorlapeyre• 14 years ago

I'm getting a..

LoadError: no such file to load -- ruby_flux-1.0-SNAPSHOT

shitlord• 14 years ago

I didn't even get that far... I got 100 of these on the first step: error: cannot find symbol

rietta• 14 years ago

Sweet! Another neat project from Mr. Charles Nutter. I look forward to experimenting with this. One of my latest projects involves a cross-platform GUI built with the help of JRuby.

miles_matthias• 14 years ago

Could someone explain why this is needed?

I don't understand why someone wouldn't just write Java if they wanted to write Java.

I also don't understand why anyone would want generated code. The unnecessary abstraction leaves you less expressive and with less control.

Not trying to be a troll here, just hoping to learn something I'm missing.

pit• 14 years ago

Weirdly, I was wondering about the existence of something like this about 20 minutes ago. I'm using Grails for work, and it's pretty unpleasant. I don't want to write Groovy, but I have to write Groovy.

amalter• 14 years ago

This could be useful for someone wanting to whip up some Android code in Ruby, but not wanting to import the full JRuby or Ruby NDK overhead.

I bet it's mostly for fun. He essentially extracted his JRuby JIT into a conventional compiler.

In other words, a neat hack.

rst• 14 years ago

All the more so because current "jruby-on-Android" has performance problems. This hits particularly hard on startup (where a simple app can take several seconds to get past a splash page; see http://ruboto-startup.heroku.com/measurements for timing). But even once the app gets running, things still drag compared to a conventional JVM because the JIT doesn't work (due to Android's nonstandard Dalvik bytecodes).

If rubyflux winds up bypassing most of this overhead, it could be a major win. (Right now, I've got a project to try to use Scala to try to build a full-featured, reduced-boilerplate Android environment here: http://rst.github.com/positronic_docs.html --- but I'd really rather be using Ruby if the performance penalties could be ironed out.)

zem• 14 years ago

there are a lot of people who want to have java written, but don't want to write java. this way you might get less control, but you get the greater expressiveness of ruby.

scott_s• 14 years ago

It may not be needed. The author may just have done it because they could, and thought it was neat.

But the potential reasons for wanting it is that now the runtime is the JVM, MRI (Matz's Ruby interpreter). JRuby accomplishes using the JVM as the runtime for Ruby by reimplementing the Ruby runtime in Java. This is a different approach, one in which Ruby code is compiled to Java code, rather than using Java runtime interpret Ruby code.

yareally• 14 years ago

Definitely with Android. Lots of people want to make Android apps, but a decent percentage do not want to use Java. I prefer Mono for Android as a native alternative, but this could be nice for those that want to use a more dynamic language than C# or F# (Mono for Android does not have real support for dynamic languages due to limitations imposed by the Dalvik VM).

bascule2• 14 years ago

You're essentially asking why someone would write a compiler. Why wouldn't someone consume target language X directly instead of using a compiler to generate output in target language X. We want our programs to wind up as machine language, so why not write opcodes for the host ISA instead of writing in, say, any other language?

nate_martin• 14 years ago

Not actually a compiler, more of a translator.

chimeracoder4• 14 years ago

You're correct; however, unfortunately most discussions on here ignore the difference, I've noticed.

isbadawi• 14 years ago

What is the difference? As far as I know any program that translates code from one language to another is a compiler.

thasmin• 14 years ago

Mirah is a very similar project. It's a language that's very similar to Ruby that compiles directly onto the JVM with no runtime. It's also by Charles Nutter.

hosay123• 14 years ago

The difference between this and Mirah is that Mirah is more just a (beautiful) Java front-end: it looks like Ruby, but with just enough annotations to allow for strongly typed output. This looks a a bit more loose than that.

haberman• 14 years ago

Are there any production-quality cross-language compilers that support all the subtle semantics of the source language correctly? (I'm excluding C as a target language, which I know is often used as an output format for production-quality compilers).

I feel like I always see projects like this that have just started out, and provide no discussion of the difficult edge cases and how they will be supported. Correctly implementing a programming language is a really hard problem. Programming languages have tons and tons of subtle edge cases, like what happens if you add two objects of different types (think about the "wat?" talk: http://www.youtube.com/watch?v=kXEgk1Hdze0). If you don't get all these semantics correct, then your implementation won't be compatible with code written on other implementations.

Charles Nutter has obviously done a lot of work implementing Ruby in the past so is surely aware of all of this. I just wonder, when I see a project like this, what the ultimate plan is. Is it:

- the project is new and incomplete, but we plan to work on it until it correctly supports all semantics of the source language, even if the generated code gets uglier and more complicated as a result

- the project is new and incomplete, and we'll add support for more stuff but not get too worried about every last quirk of the source language, especially if it makes the generated code get too complicated

- the project is just an interesting hack, a fun side project, an experimental prototype or proof-of-concept, etc, and you shouldn't expect much compatibility.

headius2• 14 years ago

I would say it is the second goal right now. Implementing JRuby and Mirah taught me a lot about features of Ruby that can map directly to Java/JVM, and I feel like this can be a very useful, functional subset of Ruby. Because this is a "compile the world" approach, things like evaluation probably will never be supported. But because it can generate the whole system, things like methods_missing, send, and respond_to? are all doable (and I just pushed m_m support a few hours ago). That opens up possibilities that are hard to achieve in typical statically typed languages without requiring any complicated dynamic dispatch system.

Honestly I feel like the biggest feature of both Mirah and RubyFlux are their ability to produce binaries that have no external dependencies. You only pay for what you use, and in both cases you,really just doing normal JVM calls under the covers. What Mirah achieves through static typing, RubyFlux achieves by generating all method names as stubs on a base class.

As others have pointed out...it is also just a fun experiment :-) But that is how both JRuby and Mirah started out too.

lucian303• 14 years ago

I thought the whole fiscal cliff thing was quite nasty but this ...

RubyFlux: a Ruby to Java compiler

Related Stories