Ahead-Of-time (AOT) Compiler Designed for Ruby | Hacker News Reader

Ahead-Of-time (AOT) Compiler Designed for Ruby

github.com

42 pointsksec16 comments

This is /not/ AOT compilation of ruby code.

It simply compiles a ruby interpreter and adds your code to the executable (as memfs).

The output is an executable that /interprets/ ruby code.

Currently it is just packaging, but when combined with work of @ko1 we could achieve real compiling in order to boost start-up speed and also protect intellectual properties.

I talked to @ko1 last year after his presentation about AOT compiling for Ruby at RailsConf, and it seems like we were missing a piece of the puzzle at that time, which is to preserve the file system structure after compiling, in order to accommodate `__FILE__` and `require` calls. I achieved it now with the help of libsquash(https://github.com/pmq20/libsquash). So now in runtime every path that begins with `/__enclose_io_memfs__/` got redirected to the memory, and so are your project files.

Preserving the file structure and deriving information from it at runtime (__FILE__, require, etc) is still totally not AOT compilation..

I can understand that you're just starting on the project and don't want to discourage you in anu way. But it might help if you reflect your projects goals but also the current status in the readme :)

Maybe you know something I don't, but I understand that Koichi's AOT is still just translating the Ruby source code to bytecode which is then interpreted. It isn't AOT to native code.

You are correct. AOT compilation for ruby would translate the internal AST into machine code.

While serializing Ruby files in byte code might be a good idea (I don't know enought of the internals of MRI so I can't judge that), it's still not AOT compilation

So it compiles your code into a bundle with ruby interpreter so that you don't need one during execution? It sounds like what youtube-dl does in Windows by adding the interpreter to the executable. Useful but not in speeding things up but in packaging without dependencies.

They should probably mention that in the README because it is ambiguous and I thought it was a bytecode or binary compiler for Ruby at first.

IMO there's not mich ambiguity in AOT compilation; it /compiles/ the code ahead of time. This tool is just not that. It /copies/ the code ahead of time. There's not really an advantage in that (maybe distributing a single file, but that's it).

Maybe the author should consider describing it as packager or something else.

As I was skimming README, I was thinking "what's the catch?"

And there it is, you're absolutely right this is not an AOT compiler.

http://i.imgur.com/MVOSH81.png

I can't be the only one

https://duckduckgo.com/?q=%22that+just+works%22

<Product name>. <What it does>, that just works. Made by <name> in <city> with love.

It just works, passing tests and all that fancy stuff is out of the project's scope.

A lot of people have complained about the lack / difficulties of Ruby Programs distribution. I remember the Authors of Vagrant said one of the reason why he switched to Go was that.

And this solves that problem.

As suggested by other comments, this is not really AOT, more like a bundler (not that bundler) or packer. It prepacks a Ruby interpreter with your files/libs/deps. Useful and interesting, but not an AOT.

While still useful, this appears to be more of a bundler than a compiler, per se.

How easy would it be to retrieve the ruby source code from the distributed binary?

Fairly easy. It's inside a memfs in data section in the binary.

Reply on news.ycombinator.com