[sfkdjf9j3j]

> 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.

[dragonwriter]

> 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.

[brightball]

Don’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]

> 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