
Ruru: native Ruby extensions written in Rust - thibaut_barrere
https://github.com/d-unseductable/ruru
======
PascalW
Interesting. Wonder how it compares to Helix [1].

[https://github.com/rustbridge/helix](https://github.com/rustbridge/helix)

~~~
fbernier
I am slightly disappointed by Helix. They pushed an alpha version, made a good
and extensive blog post on it and everything it's going to bring to the table,
and got us all excited.

More than a month later there are obviously some bug reports and pull requests
that have been opened. There hasn't been a single answer or acknowledgement
from the team behind Helix. Not a single commit either.

I get that this is open source software and that they might suddenly not have
any time to put on it, but at least an acknowledgement of the situation
somewhere or getting some help from contributors would have been appreciated.

------
actsasbuffoon
Looks like the repo hasn't been updated in over a month. This project looks
interesting. Anyone know if this is still being developed?

In fact, every crate I can find in this category (Helix, ruru, rurust, mrusty,
and ruby-sys) is looking a little abandoned. rurust was updated 25 days ago,
and that's the most recent.

~~~
GavinMcG
It's summer! People are doing things with their lives.

~~~
actsasbuffoon
Wait, people have social lives outside of reading HN? I find this information
disturbing.

------
haberman
I wonder how it handles memory management. I just wrote an article about how
memory management is handled with Ruby C extensions. It involves some gnarly
platform-specific tricks like scanning the C stack looking for "VALUE"
pointers (ie. C pointers to Ruby objects). Also Ruby makes you implement a
"mark" function to trace references the Ruby interpreter doesn't know about.

[http://blog.reverberate.org/2016/06/12/native-extensions-
mem...](http://blog.reverberate.org/2016/06/12/native-extensions-memory-
management-part1-ruby-mri.html)

I wonder if this works the same for Rust.

------
diminish
What would it require the whole Ruby to move to Rust from C? What would it
bring and would it make sense?

~~~
rubiquity
Probably a lot of work. It would bring the same things that most rewrites do:
Cleaner code in most places and probably some performance due to understanding
problems better the second time around. If you were doing the rewrite for
performance, it wouldn't be worth it. If you were doing the rewrite for a more
modern language to attract more contributors, it might be worth it.

I don't think Ruby as a language has had many issues in the space that Rust
tends to solve (safety related to memory). Ruby is garbage collected. I don't
know what (if any) performance boost the VM would get by being converted to
LLVM IR. It's mostly the semantics of Ruby the language that make it hard to
make fast. It seems most of the recent efforts to make Ruby faster have been
by making the runtime do less allocations.

~~~
chrisseaton
> I don't know what (if any) performance boost the VM would get by being
> converted to LLVM IR

Well you can already convert the VM to LLVM IR today by compiling with clang.

~~~
valarauca1
This is an interesting idea. If you transpile the Ruby runtime to LLVM-IR you
can run Ruby's IR in LLVM's tracing JIT mode.

Theoretically the LLVM will optimize your application as its running.

P.S.: I don't know Ruby so YMMV

P.P.S.: If it works with Ruby it'll work with Python too.

~~~
chrisseaton
We do this to run Ruby C extensions on the JVM - compile the extension to LLVM
IR instead of native code, then JIT compile the IR using the JVM's JIT. It's
fast!

~~~
chc
Huh? You use the JVM's JIT to compile LLVM IR? How does that work? Isn't it a
bytecode compiler?

~~~
chrisseaton
Well yes but at some point in the pipeline the byte code is long gone. So you
can use it for anything by using just the parts beyond that point.

But really we don't directly compile the IR. We have an interpreter for IR,
and we JIT compile the interpreter, sort of constant folded with the IR. It
achieves the same thing without getting more technical.

[https://github.com/graalvm/sulong](https://github.com/graalvm/sulong)

------
ksec
Why is it many of the Ruby Communities have decided to argument Ruby with
Rust, rather then something much more similar to Ruby like Swift or Crystal?

~~~
kibwen
Likely because people in the Ruby community tend to favor solutions that allow
them to continue writing Ruby. In the context of the OP, Rust is being used
only to augment Ruby, to complement it, not to outright replace it. Adopting
Swift or Crystal would involve rewriting much more code from Ruby into the new
language.

Look at it this way: for these programmers, the choice isn't between Rust and
Crystal, it's between Rust and C. And for people who've never written systems
code before, Rust is enormously friendlier.

~~~
ksec
Sorry I wasn't being clear in the first post. I meant argument Ruby with Rust.

Yes the Choice is pretty much something to replace / use instead of C. Which
Swift as well as Crystal can be used in here too.

~~~
kibwen

      > Swift as well as Crystal can be used in here too
    

Can you elaborate? I don't know of any way to compile Swift or Crystal code
into a library that exposes a C-compatible ABI, and I can find no
documentation as such.

