Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ruby YJIT Ported to Rust

github.com

Post reply on HN
Print view View original

81–90 of 93 posts

Re: Ruby YJIT Ported to Rust

#81

Post by steveklabnik »

stormbrew wrote: post #80
steveklabnik wrote: post #79

Earlier quoted context omitted.

Hilariously, years ago I did some Rust/Ruby integration, for fun, and had Ruby’s makefiles just call Cargo to build the rust code. It worked just fine. It doesn’t work for all things in all cases, of course, but it can be workable. At work we built a build system on top of Cargo to paper over some of its deficiencies. It’s not ideal but IMHO it’s still better than dealing with rustc directly. In this case it’s easier…

I mean, calling rustc isn't so bad other than managing dependencies. I don't think it's really all that much more fraught than the compilers of other complex languages (including C++) that people manage to interact with directly. But cargo is simultaneously so good at dealing with dependencies, and (for lack of a better word) parasitic in its integration with nearly every crate in existence, that the moment you want…

Yes, absolutely, the end of your first paragraph is really what I mean; you end up having to basically rebuild cargo anyway. If you have a self contained code base, it’s not like rustc is inherently bad to call directly, for sure.

Re: Ruby YJIT Ported to Rust

#82

Post by faitswulff »

hardwaregeek wrote: post #68

This is so cool! If new contributions to Ruby could be written in Rust, I'd be a lot more inclined to contribute. I don't think I'm alone here. Andy Kelley noted that the new Zig compiler has significantly more contributors, likely due to it being written in Zig and not C++. Some people may roll their eyes at this, but it is a lot more enticing to work on a Rust codebase than a C/C++ one. I'm less likely to screw up…

Unfortunately:

> To be clear, it's OK to use Rust to implement YJIT (and other optional features in the future), but mainline CRuby will not be implemented in Rust.

- Matz, https://bugs.ruby-lang.org/issues/18481#note-14

On the other hand, there is Artichoke Ruby: https://github.com/artichoke/artichoke

Re: Ruby YJIT Ported to Rust

#83

Post by Ar-Curunir »

pjmlp wrote: post #76
pcwalton wrote: post #72

Earlier quoted context omitted.

WebRender is certainly "GPU related" and is shipping to millions of happy Firefox users. And yes, LLVM is written in C++. So what? C++ compilers depend on C code in libc. Portions of libc are written in assembler. Some assembly instructions are decomposed into microcode. Yet nobody doubts that C++ has eclipsed assembly language in terms of importance to the industry nowadays. We'll always need a way for humans to rea…

For how long? 3% and decreasing. Libc is UNIX only. As for the rest, it is useful to tone down hype with some cold water reality check.

> tone down hype with some cold water reality check.

I mean, you're the one who keeps mentioning Ada/SPARK on every Rust thread, so if anyone needs to stop hyping things, it's perhaps you?

Re: Ruby YJIT Ported to Rust

#84

Post by Tobu »

matharmin wrote: post #29
throwaway-m3232 wrote: post #15

Why not C++, for better portability? If I want to design my own CPU, I will have to add it to GCC. But Rust is LLVM so if I want to support Ruby-jit on my CPU, I will also will have to support LLVM.

If you want to design your own CPU, supporting LLVM is going to give you much greater benefits than supporting Ruby. Nevermind the fact that you don't even need this to support Ruby.

To add to your point, following Woodruff's "Weird architectures weren't supported to begin with", Robert O'Callahan pointed out[1] that for one definition of the open-source platform (looking at the requirements of Linux distributions), a new architecture would need to support at least: LLVM and GCC targets, a port of the Linux kernel, a V8 backend, and acceleration for various codecs.

And while at this point a platform needs to have support from both compilers, I can see the GCC/glibc ecosystem being made redundant; LLVM is more adaptable and has found its way into so many specialized compiler stacks.

[1]: https://lwn.net/Articles/847830/

Re: Ruby YJIT Ported to Rust

#85

Post by Tobu »

infamouscow wrote: post #31
brobinson wrote: post #22

Earlier quoted context omitted.

Why not a memory safe language, to avoid those 70% of CVEs? (67% of 0-days last year: https://news.ycombinator.com/item?id=31085539 )

Because Ruby is already memory safe and JIT miscompilation is a logic bug.

Rust's type system is enough to get rid of memory safety and UB, but it does that by enforcing more invariants, invariants which you also use to encode properties you care about. 70% percent of vulnerabilities are memory unsafety which is impossible in safe Rust etc etc, but a better type system, a language that doesn't disclaim commonly found code as unsupported, more productive errors, lower cognitive load… also tends to help with the rest of the bugs.

Re: Ruby YJIT Ported to Rust

#86

Post by hardwaregeek »

faitswulff wrote: post #82
hardwaregeek wrote: post #68

This is so cool! If new contributions to Ruby could be written in Rust, I'd be a lot more inclined to contribute. I don't think I'm alone here. Andy Kelley noted that the new Zig compiler has significantly more contributors, likely due to it being written in Zig and not C++. Some people may roll their eyes at this, but it is a lot more enticing to work on a Rust codebase than a C/C++ one. I'm less likely to screw up…

Unfortunately: > To be clear, it's OK to use Rust to implement YJIT (and other optional features in the future), but mainline CRuby will not be implemented in Rust. - Matz, https://bugs.ruby-lang.org/issues/18481#note-14 On the other hand, there is Artichoke Ruby: https://github.com/artichoke/artichoke

True, although Matz has changed his mind in the past (type annotations come to mind). I wouldn't be surprised if people notice that YJIT contributions are far more common, Matz may reconsider this.

Re: Ruby YJIT Ported to Rust

#87

Post by stormbrew »

steveklabnik wrote: post #81
stormbrew wrote: post #80

Earlier quoted context omitted.

I mean, calling rustc isn't so bad other than managing dependencies. I don't think it's really all that much more fraught than the compilers of other complex languages (including C++) that people manage to interact with directly. But cargo is simultaneously so good at dealing with dependencies, and (for lack of a better word) parasitic in its integration with nearly every crate in existence, that the moment you want…

Yes, absolutely, the end of your first paragraph is really what I mean; you end up having to basically rebuild cargo anyway. If you have a self contained code base, it’s not like rustc is inherently bad to call directly, for sure.

Yeah. I really wish cargo had a "create a build environment" mode. It would make integrating rust into other systems a lot easier.

Re: Ruby YJIT Ported to Rust

#88

Post by antonvs »

throwaway-m3232 wrote: post #15

Why not C++, for better portability? If I want to design my own CPU, I will have to add it to GCC. But Rust is LLVM so if I want to support Ruby-jit on my CPU, I will also will have to support LLVM.

C++ is a 28-year old language that's been showing its age for at least a decade or two. If we want the software world to progress we need to move on from such languages.

Re: Ruby YJIT Ported to Rust

#89

Post by anitil »

rubyfan wrote: post #28
anitil wrote: post #18

Earlier quoted context omitted.

This is the first time I've felt that Rust is starting to eat C's lunch.

Can you say more about why you think that?

I started in C and generally when people say 'rewrite it in Rust' I just roll my eyes, because I know how hard that is. But seeing it happen on a sophisticated project has made me take another look.

Obviously for the embedded world everything is pitched at C currently and I don't think that will change, but for larger projects this is proof that my intuition was wrong.

I suppose that's a long winded way of saying that it might be time for me to learn Rust.

Re: Ruby YJIT Ported to Rust

#90

Post by pjmlp »

Ar-Curunir wrote: post #83
pjmlp wrote: post #76

Earlier quoted context omitted.

For how long? 3% and decreasing. Libc is UNIX only. As for the rest, it is useful to tone down hype with some cold water reality check.

> tone down hype with some cold water reality check. I mean, you're the one who keeps mentioning Ada/SPARK on every Rust thread, so if anyone needs to stop hyping things, it's perhaps you?

Where is Rust powering avionics and high integrity systems in production for the last 40 years? The very definition of secure software.

No one is asserting how Ada is going to wipe language XYZ.

Post reply on HN