41–50 of 93 posts
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.
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.
This won't be an issue for long, as there's already a GCC backend for Rust in development.
Earlier quoted context omitted.
Because Ruby is already memory safe and JIT miscompilation is a logic bug.
How is JIT miscompilation or vulnerabilities in the JIT compiler not an issue?
How can they make this determination? Do they just eyeball a few sections of the machine code from each output? Is there some tool that can compare binaries? Is this just a very literal, function by function, translation from C to Rust?
I don't know much reading/comparing machine code.
I found this part odd > . If YJIT is built in dev mode, then cargo is used to fetch development dependencies, but when building in release, cargo is not required, only rustc I'm not finding any information on why they bypass cargo and build directly with rustc. I'm curious what requirements led to this.
There is only a single, optional dependency which is apparently only used for testing.
> ... it works the same way and largely generates the same machine code How can they make this determination? Do they just eyeball a few sections of the machine code from each output? Is there some tool that can compare binaries? Is this just a very literal, function by function, translation from C to Rust? I don't know much reading/comparing machine code.
Earlier quoted context omitted.
This is the first time I've felt that Rust is starting to eat C's lunch.
Rust will eclipse C++. C is a harder nut to crack, particularly for the embedded space where ease of implementing and maintaining a compiler back-end/code-emitter for your new weird 8-bit architecture is important. C is pretty close to an assembly macro and it's barely updated, which is great for that use-case. But for use cases like interpreters Rust is perfectly suitable.
Also until Rust compilers are bootstraped, they will always rely on a C++ infrastructure.
I found this part odd > . If YJIT is built in dev mode, then cargo is used to fetch development dependencies, but when building in release, cargo is not required, only rustc I'm not finding any information on why they bypass cargo and build directly with rustc. I'm curious what requirements led to this.
My guess is that this is a tradeoff made to make it more compatible with downstream distro packaging systems like Debian and Redhat, who generally look very negatively on requirements to use external package managers like Cargo. By keeping their set of dependencies very small, removing Cargo from their build process has tons of benefits in terms of how complex it will be to compile the Ruby codebase
(Okay actually I’m unsure about Red Hat, but this is how Fedora does it…)
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.
Earlier quoted context omitted.
Rust will eclipse C++. C is a harder nut to crack, particularly for the embedded space where ease of implementing and maintaining a compiler back-end/code-emitter for your new weird 8-bit architecture is important. C is pretty close to an assembly macro and it's barely updated, which is great for that use-case. But for use cases like interpreters Rust is perfectly suitable.
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…