5 ms·
> Ruby has the same thing that every other language has, call outs to C code under the hood for most of the real work. Yes, this is exactly the problem. Ruby i
by sfkdjf9j3j 7y ago
> Ruby has the same thing that every other language has, call outs to C code under the hood for most of the real work.
Yes, this is exactly the problem. Ruby is so slow that you end up writing C extensions when you want to do any non-trivial computation. The documentation is bad, the tooling is bad, the build/CI complications are bad, and there's not much community info online about the process. And now your RoR developers have to support a C library, where a segfault can kill an entire Ruby interpreter.
I don't think most RoR apps run into these problems, which is why RoR is such a great thing in the first place, but we shouldn't brush aside how slow it is, and the implications of that when it becomes a problem.
- brightball 7y agoDon’t get me wrong, there are faster languages out there. The trade off that Ruby has always made was maximizing developer productivity. It’s never tried to be the fastest, but it’s plenty fast enough.
- Rotareti 7y ago> And now your RoR developers have to support a C library In Python you can write your low level extensions directly in Rust via PyO3 [0]. I guess there is something similar for Ruby. [0]: https://github.com/PyO3/PyO3 https://github.com/PyO3/PyO3
- dragonwriter 7y ago> Ruby is so slow that you end up writing C extensions when you want to do any non-trivial computation. The documentation is bad, the tooling is bad, the build/CI complications are bad, and there's not much community info online about the process. Perhaps for a classic C extension that's true, but (for portability across Ruby interpreters and other reasons), using FFI is usually the preferred way to do new C interop, and none of that is true for FFI.