5 ms·

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,

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.

sanxiyn 4y ago
This is a non-issue. YJIT only targets x86-64. After all, this is a JIT. If you designed a new architecture X, you need to port YJIT itself to target X, in addition to GCC, LLVM, etc.
- throwaway-m3232 4y ago
  Oh, so YJIT is highly coupled to x86-64? Porting GCC + yjit is less work than porting GCC + yjit + LLVM.
  - FooBarWidget 4y ago
    It's not like new architectures appear very quickly, much less adopted very quickly. The benefits of maintenance overhead reduction and development speed increase, far outweight the theoretical downside of having to port LLVM to that new architecture.
  - byroot 4y ago
    It’s not that it’s highly coupled, just that it’s still the early days and only x86_64 was on the roadmap. Arm64 is planned, and will hopefully make it into Ruby 3.2
    - FullyFunctional 4y ago
      And with an Arm64 backend, adding RISC-V is probably going to be a walk in the park.
  - lalaithion 4y ago
    Why even port GCC at all, and not simply LLVM?
    - lnxg33k1 4y ago
      But why not just buy an existing CPU on amazon
  - dkersten 4y ago
    So just port LLVM + yjit.
brobinson 4y ago
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 https://news.ycombinator.com/item?id=31085539)
- infamouscow 4y ago
  Because Ruby is already memory safe and JIT miscompilation is a logic bug.
  - carlmr 4y ago
    How is JIT miscompilation or vulnerabilities in the JIT compiler not an issue?
    - infamouscow 4y ago
      A Ruby program can delete all of the files on a computer, insert arbitrary rows into a database, drop a table, send email with attachments, etc. Am I correct that you're concerned the Ruby JIT itself will have a security vulnerability in the act of JIT compiling Ruby code? This seems extremely myopic.
      - criticaltinker 4y ago
        JS engines have had many serious vulnerabilities in their JIT optimizers, it’s not myopic at all and is a well known technique in the industry. I agree that some folks aren’t executing untrusted ruby code so they wouldn’t have to worry about this - but how many PaaS/SaaS products out there are? Or how about third party dev tools that are blindly downloaded and executed on local workstations or CI pipelines?
        infamouscow 4y ago
        > JS engines have had many serious vulnerabilities in their JIT optimizers, it’s not myopic at all and is a well known technique in the industry. HotSpot and V8 are both written in C++ and get more use than any other JIT on Earth. Can you provide a link to a CVE caused by JIT miscompilation and explain how Rust would have been able to prevent the bug in a way that C++ wouldn't? > I agree that some folks aren’t executing untrusted ruby code so they wouldn’t have to worry about this - but how many PaaS/SaaS products out there are? This is what Xen, KVM, and Hyper-V do. > Or how about third party dev tools that are blindly downloaded and executed on local workstations or CI pipelines? Are you suggesting a Ruby JIT shouldn't generate machine code that corresponds to the Ruby program, but somehow magically prevent stupid developers from doing stupid things?
matharmin 4y ago
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.
- Tobu 4y ago
  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/ https://lwn.net/Articles/847830/
cjg 4y ago
Rust has some GCC support.
unrealhoang 4y ago
Because Rust is much easier to learn than C++ so the authors are more comfortable with Rust?
cesarb 4y ago
> I will also will have to support LLVM. This won't be an issue for long, as there's already a GCC backend for Rust in development.
mustache_kimono 4y ago
I'm not sure I understand why some people really hate Rust, but when the argument feels like "But can't we be miserable forever?" I just have to laugh.
- mustache_kimono 4y ago
  FYI -- my technical thinking -- because Rust is a nicer language for the people who have to work with it. Full stop. Rust offers substantial memory safety guarantees, but that isn't the only thing it offers. People who don't know this are those that haven't tried it. Others have focused on security in this thread, and I think that's wrong headed. That's obviously not the reason for choosing Rust here. It's that it makes things that are important now and in the future, like say concurrency, easier and more likely to be correct. Yes, ergonomics and a nice dev experience actually matter even for the people writing your compiler! Moreover, Rust GCC support is far closer to being a thing that yjit is to being a thing. So -- let the kids play.
bilkow 4y ago
> If I want to design my own CPU, I will have to add it to GCC. Why do you "have" to add it to GCC? You could only add it to LLVM instead.
antonvs 4y ago
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.

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.

sanxiyn 4y ago

This is a non-issue. YJIT only targets x86-64. After all, this is a JIT. If you designed a new architecture X, you need to port YJIT itself to target X, in addition to GCC, LLVM, etc.

throwaway-m3232 4y ago
Oh, so YJIT is highly coupled to x86-64? Porting GCC + yjit is less work than porting GCC + yjit + LLVM.
- FooBarWidget 4y ago
  It's not like new architectures appear very quickly, much less adopted very quickly. The benefits of maintenance overhead reduction and development speed increase, far outweight the theoretical downside of having to port LLVM to that new architecture.
- byroot 4y ago
  It’s not that it’s highly coupled, just that it’s still the early days and only x86_64 was on the roadmap. Arm64 is planned, and will hopefully make it into Ruby 3.2
  - FullyFunctional 4y ago
    And with an Arm64 backend, adding RISC-V is probably going to be a walk in the park.
- lalaithion 4y ago
  Why even port GCC at all, and not simply LLVM?
  - lnxg33k1 4y ago
    But why not just buy an existing CPU on amazon
- dkersten 4y ago
  So just port LLVM + yjit.

brobinson 4y ago

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 https://news.ycombinator.com/item?id=31085539)

infamouscow 4y ago
Because Ruby is already memory safe and JIT miscompilation is a logic bug.
- carlmr 4y ago
  How is JIT miscompilation or vulnerabilities in the JIT compiler not an issue?
  - infamouscow 4y ago
    A Ruby program can delete all of the files on a computer, insert arbitrary rows into a database, drop a table, send email with attachments, etc. Am I correct that you're concerned the Ruby JIT itself will have a security vulnerability in the act of JIT compiling Ruby code? This seems extremely myopic.
    - criticaltinker 4y ago
      JS engines have had many serious vulnerabilities in their JIT optimizers, it’s not myopic at all and is a well known technique in the industry. I agree that some folks aren’t executing untrusted ruby code so they wouldn’t have to worry about this - but how many PaaS/SaaS products out there are? Or how about third party dev tools that are blindly downloaded and executed on local workstations or CI pipelines?
      - infamouscow 4y ago
        > JS engines have had many serious vulnerabilities in their JIT optimizers, it’s not myopic at all and is a well known technique in the industry. HotSpot and V8 are both written in C++ and get more use than any other JIT on Earth. Can you provide a link to a CVE caused by JIT miscompilation and explain how Rust would have been able to prevent the bug in a way that C++ wouldn't? > I agree that some folks aren’t executing untrusted ruby code so they wouldn’t have to worry about this - but how many PaaS/SaaS products out there are? This is what Xen, KVM, and Hyper-V do. > Or how about third party dev tools that are blindly downloaded and executed on local workstations or CI pipelines? Are you suggesting a Ruby JIT shouldn't generate machine code that corresponds to the Ruby program, but somehow magically prevent stupid developers from doing stupid things?

matharmin 4y ago

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.

Tobu 4y ago
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/ https://lwn.net/Articles/847830/

cjg 4y ago

Rust has some GCC support.

unrealhoang 4y ago

Because Rust is much easier to learn than C++ so the authors are more comfortable with Rust?

cesarb 4y ago

> I will also will have to support LLVM. This won't be an issue for long, as there's already a GCC backend for Rust in development.

mustache_kimono 4y ago

I'm not sure I understand why some people really hate Rust, but when the argument feels like "But can't we be miserable forever?" I just have to laugh.

mustache_kimono 4y ago
FYI -- my technical thinking -- because Rust is a nicer language for the people who have to work with it. Full stop. Rust offers substantial memory safety guarantees, but that isn't the only thing it offers. People who don't know this are those that haven't tried it. Others have focused on security in this thread, and I think that's wrong headed. That's obviously not the reason for choosing Rust here. It's that it makes things that are important now and in the future, like say concurrency, easier and more likely to be correct. Yes, ergonomics and a nice dev experience actually matter even for the people writing your compiler! Moreover, Rust GCC support is far closer to being a thing that yjit is to being a thing. So -- let the kids play.

bilkow 4y ago

> If I want to design my own CPU, I will have to add it to GCC. Why do you "have" to add it to GCC? You could only add it to LLVM instead.

antonvs 4y ago

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.