Natalie – a work-in-progress Ruby compiler, written in Ruby and C++ | Hacker News Reader

Natalie – a work-in-progress Ruby compiler, written in Ruby and C++

github.com

106 pointsciconia22 comments

Andreas Kling (of SerenityOS and Ladybird fame) streamed contributing a performance improvement to this compiler that was pretty interesting to watch: https://www.youtube.com/watch?v=b4PZgvPYkP4

Natalie: An early-stage Ruby implementation that compiles to C++ - https://news.ycombinator.com/item?id=29660883 - Dec 2021 (50 comments)

Natalie: A work-in-progress Ruby implementation, compiled to C++ - https://news.ycombinator.com/item?id=28207921 - Aug 2021 (2 comments)

For those asking what’s the point, check the author’s GitHub profile: “I’m also making my own Ruby called Natalie. You know, for fun!”.

Very cool. Ruby is still my favorite lang after many....

Right?!! It’s just so much fun to use. I have even more appreciation for it after working on my own. :-)

Wouldn't it be easier to have it transpile to Crystal? The languages are already extremely similar

Crystal's syntax is somewhat similar to Ruby's, but its actual semantics (and type system) are fundamentally different.

In particular, `method_missing` and other fundamentally dynamic things that make Ruby feel like Ruby can't be done in Crystal, at least not without extensive runtime support.

(I haven't looked at this implementation, but I suspect that they end up doing similar things in C++ for the same reason.)

I might port some of my algorithms to this!

Please do… I would love to have some more example scripts in the repo!

What's the goal of the project? It's not clear from the Github repo or the site (natalie-lang.org).

I think:

> It provides an ahead-of-time compiler using C++ and gcc/clang as the backend

Which is kind of the new "in" lately.

EDIT: If you see the the animation in the GitHub repo, you'll see at a certain point a file named "bs" (which is a binary file). I guess the standard Ruby compiler doesn't allow you to spit out binaries out of the box (?).

> I guess the standard Ruby compiler doesn't allow you to spit out binaries

Ruby is an interpreted language, programs are not compiled (except for the JIT compiler).

I wonder what makes this different from mruby[1] which seems to be very well supported for many years.

[1] https://mruby.org/

If we're being honest, the only thing that differentiates an interpreted and compiled language is intention (design decisions that make one implementation versus the other easier) and what you choose to run the language through.

You can make almost any general purpose language "compiled", depending on how fat you're willing to make the runtime. And you can certainly create an interpreter/JIT VM for C/C++. It's not a question of possibility, but one of "why?".

mruby is making ruby more lua-like (embeddable, etc.). If this project does AOT compilation well, we might be able to shave lots of interpreter overhead from Ruby for some applications.

I say some applications because there are still people using Ruby to write non-web things, and I doubt if this project will ever support Rails in the short term

Yeah, Rails would be a long ways off, if it ever happens at all. But I could see a use for a compiled Sinatra app, and that seems attainable in my lifetime. :-)

Cool, that was my read as well. Just making sure I wasn't missing something!

Still think that crystal might be more interesting in a similar niche?

https://crystal-lang.org/

No, a compiler for Ruby is more interesting than a compiler for a vaguely Ruby-like language with feature alterations specifically for ease of implementing compilation.

Even if it only ends up compiling a subset of Ruby, it could be a foundation for a Ruby equivalent of one of the several tools for accelerating Python by compiling a subset and allowing it to interface with regular interpreted code.

It's a cool project, but I'm not really sure what the point is. I'm doubtful that you could ever match the full expressiveness of Ruby in C++ or any compiled language. If you wanna play with it because it's fun, that's fine, but I doubt that it would ever be able to do much with most of the Ruby code out there.

Never underestimate the power of doing it for fun.

Thankfully, progress rests on the shoulders of people doing crazy things, ignoring the nagging voices of those unable to create just for the fun of it.

I wish this myth of dynamic == interpreted, static == compiled would die.

Interpreters are almost always written in statically typed compiled languages. When you feed an interpreter source code in Ruby, Python, Perl, etc. the net effect is that you have a compiled binary program that's executing your dynamic code.

So it shouldn't too great of a leap to understand that you can do full ahead-of-time compilation of dynamic code so long as you're prepared to embed a rich runtime into the binary.

Common Lisp is one of the most dynamic languages in existence, and has been ahead-of-time compiled for decades.

Of course, the dominant compilation paradigm for dynamic languages these days is "just-in-time" (e.g. JavaScript V8, Python PyPy, Ruby YJIT), because it allows you to use runtime frequency and type information to compile parts of the source more intelligently.

But either way, the whole "dynamic languages cannot be compiled" thing isn't true.

Reply on news.ycombinator.com