> You interpreted my comment as an attack on the author. If they have a special case they want to optimize FFI for this seems like a great way to do it.
My mistake. I assumed the conversation was relevant to the post. I hadn't realized the topic had diverged.
> I think you’re vastly overestimating the fork/exec overhead on Linux. If your hot path is this hot you better not be calling Ruby functions.
We're talking about running a Ruby application. Let's use Rails to make it more concrete. That's going to be a lot of Ruby on the hot path. Avoiding that is tantamount to rewriting the application in another language. But, Ruby on the hot path can be fast, particularly when JIT compiled. And that's going to be faster than spawning a new process. The article even demonstrates this showing hot `String#bytesize` is faster than all other options. That's not to say writing a program in C is going to be slower than Ruby, but rather that integrating Ruby and C, which will involve translation of data types, is going to favor being written in Ruby. And, of course, the implementation of `String#bytesize` is in C anyway, but we don't have to deal with the overhead of context switching.
> You’re already doing it. Do you have a database? Nginx? Me cached? Imagemagick? Do you use containers?
All of those things ship as packages and are trivial to install. I don't need to compile anything. Packaging this theoretical application in a container out of band isn't going to help. Now, I need to `docker exec` on my hot path? No, that won't work either. So, instead, I need to add an explicit compilation step to what is otherwise a case of SCPing files to the target machine. I need to add a new task whether in the Dockerfile or in Rake to build an application to shell out to. At least with a native extension packaged as a gem there's a standard mechanism for building C applications.
There's no getting around that this complicates the build. I'm not sure why that's debatable: not having to do all of that is easier than doing it.
> Consider the alternative: is the ideal world the one where all software is available as a ruby package?
I'm not saying we should rewrite everything in the world in Ruby. But, yes, for a Ruby application the ideal world is one in which all code is written in Ruby. It's the simplest option and gives a JIT compiler the most context for making optimization decisions. I'm not interested in using Ruby as a glue language for executing C applications in response to a routed Rails request. At that point I may as well use something other than Ruby and Rails.