[megumax]

The platform `problem` shouldn't be a problem, because you wouldn't use ruby outside of Linux, Windows, Mac, FreeBSD, OpenBSD and Rust has support for more than that[1]. Backwards compatibility isn't a concert either, Rust promised and kept it for some years (after 1.6).

The real problem is whether or not the expense of porting it is justified. Taking a look at the git repository of it (before it was merged into upstream), I understand why they want to rewrite it in Rust, the repository looks like a complete mess. I don't know if they want to use an existing JIT codegen like LLVM or Cranelift, or their own.

[whizzter]

Afaik the only ones that's somewhat successfully used LLVM for a dynlang JIT is the Safari guys, and iirc that one was only for the highest optimization level (and that is an important hint on their direction and one that most dynlang JIT's should head).

The goals and constraints of practical dynlang JITs often differ a bit from those for statically typed languages. The JITs for statically typed languages are often fairly "straightforward" since the basic/primitive types are often known, and with the exception for dispatch optimizations, many large wins comes from register allocation,etc.

A dynlang JIT on the other hand far more often has unstable basic types that goes along with type guards,etc. You have a ton of optimizations in that regard that comes before it's even time to consider more than basic register allocation optimizations (See for example the recent posts on the new Erlang JIT).

In this particular case Maxime's PHd was a JS JIT that implemented something called Basic-Block-Versioning, you can see an early paper on this at https://arxiv.org/abs/1411.0352

My suspicion is that the existing codegens you mention comes with a lot of baggage that might be in the way of how a lazy codegen like they want should be structured. I wrote a small experimental lazy dynamic JIT once and the structure definitely got twisted around and "direct" access to all parts definitely was a plus.

[byroot]

> you wouldn't use ruby outside of Linux, Windows, Mac, FreeBSD, OpenBSD and Rust has support for more than that[1].

Ruby has support for plenty of "exotic" systems like HP UX, AIX etc. It's unclear how many people actually use it, but it's there.

> I don't know if they want to use an existing JIT codegen like LLVM or Cranelift, or their own.

Their own.

[petercooper]

Fun bit of trivia.. Ruby only (officially) dropped Atari ST support in 2016: https://github.com/ruby/ruby/blob/c5eb24349a4535948514fe765c... .. I've never heard of anyone actually using Ruby on an Atari ST though(!)

[megumax]

I wasn't even referring to CRuby, I was referring to YJIT especially. For now, it only works on x86_64 Unix like systems (Linux and mac). I doubt that someone will ever port YJIT codegen to these "esoteric" architectures, so rust platform support is enough.

[byroot]

> I wasn't even referring to CRuby, I was referring to YJIT especially.

My bad, that's really not what I understood from your initial statement. But yes agreed.

The only real downside is discussed on the ticket. Ruby is primarily installed from source, so requiring a second toolchain is not ideal.

[pjmlp]

While those that were willing to make it happen, now have to wait until Rust/Zig supports their esoteric architecture.

[pjmlp]

At least in what concerns AIX, IBM has migrated their compilers on top of LLVM, so some support is there.

No idea about HP-UX, it is impossible to find anything now, apparently HPE has buried almost everything about it. Completely unrelated to how good it used to be about 20 years ago.

[byroot]

I just gave a couple examples I had in mind because they came up recently. The point was that the parent's assertion:

> you wouldn't use ruby outside of Linux, Windows, Mac, FreeBSD, OpenBSD

Isn't quite true.

[pjmlp]

Agreed.