Live data from Hacker News

Ruby YJIT Ported to Rust

github.com

91–93 of 93 posts

Re: Ruby YJIT Ported to Rust

#91
post #50

Earlier quoted context omitted.

This position is like saying C or C++ won't eat ASM's lunch. While technically true since there's a lot of ASM code still being written, especially for extremely low-level or high performance code, the vast majority of C and C++ developers don't actually touch ASM (i.e. C/C++ dominate ASM in terms of number of developer hours spent). I think you may also be overlooking the GCC backend for rustc and gccrs, a ground-up…

Very few will actually rewrite code in rust. It is enough for Rust to be used for new projects which would otherwise be c or c++

If gcc supports Rust as a frontend ootb, I could see existing C/++ projects incrementally adopting components written in the language.

Re: Ruby YJIT Ported to Rust

#92

Here's a benchmark [1] done in Jan'22 against many ruby implementations, truffleRuby [2] seems to be way ahead in most, and at least ahead in all. Why truffleRuby isn't talk about much here? [1] https://eregon.me/blog/2022/01/06/benchmarking-cruby-mjit-yj... [2] https://github.com/oracle/truffleruby

I must note that TruffleRuby is a fantastic and genius bit of work with similarly genius folks working on it, but to answer your question.. there's a big cultural aspect. Things involving Oracle, the JVM, and Java generally do not tend to particularly click well with the entire Ruby world (but are just fine in specific niches). Consider that JRuby was significantly faster than CRuby for a long time yet the level of usage it got never really reflected that. Also consider just how poor Windows support was in Ruby for many years - this also wasn't purely a technical issue.

Re: Ruby YJIT Ported to Rust

#93
post #50

Earlier quoted context omitted.

This position is like saying C or C++ won't eat ASM's lunch. While technically true since there's a lot of ASM code still being written, especially for extremely low-level or high performance code, the vast majority of C and C++ developers don't actually touch ASM (i.e. C/C++ dominate ASM in terms of number of developer hours spent). I think you may also be overlooking the GCC backend for rustc and gccrs, a ground-up…

Very few will actually rewrite code in rust. It is enough for Rust to be used for new projects which would otherwise be c or c++

It's extremely important for meaningful commercial Rust adoption for legacy codebases to be able to adopt it incrementally (i.e. all new code is Rust). I think you're underestimating how much C/C++ code there is out there (Linux Kernel, Chrome, all of Google's internal infrastructure, all of Amazon's internal infrastructure etc). We're talking about many billions dollars worth of code that is never going to get rewritten and lines of code that keep accruing. Now competitors starting today may make other choices but there's enormous value to be had by cracking the nut of seamless integration of progressive migration (i.e. so that you can say "no more new C++ code"). The failure of this lesson is seen in banks that continue to run on Fortran at best and at worst other businesses that continue to run on old unsupported languages/technologies. Thankfully, I think the tech companies are engineering-led and understand this so I suspect they're paying people to figure out this problem.
Post reply on HN