Series of articles table of contents
Ruby and Rust are, in a sense, opposite languages. Therefore,
I would like to expect that it may be.
Therefore, I would like to write an article about the cooperation between Ruby and Rust in several parts. (Because it's a person who doesn't last long, it may stop soon)
For the first time, I thought about the purpose of cooperation, when it would be nice to cooperate.
Although I have a long and slender Ruby life, Rust remains an amateur forever (or rather, I rarely write programs in Rust). I don't know the world of system programming at all, and I suffer from compiler phobia in the first place.
When I'm writing a script in Ruby, I often wonder, "Why don't I rewrite this part in Rust to make it faster?"
For example, the Helix [^ helix] demo showed an example of implementing ActiveSupport's blank? In Rust to overwhelmingly improve performance [^ blank].
[^ helix]: One of the mechanisms that connects Ruby and Rust. https://github.com/tildeio/helix
[^ blank]: Of course, it's the blank? Method that greatly improves performance. Not the entire Rails application will explode. That said, blank? Is run many times in Rails, so I don't think it's a good idea.
However, it's a common illusion that replacing Ruby with a system programming language (not just Rust) will make it faster (anything).
Taking string processing as an example, built-in methods such as String # gsub and String # downcase operate very fast in their own right. Even if an amateur rewrites the process of combining some of these methods with Rust, there is no win.
"Ruby is slow", but in what sense is it slow? Method calls and block evaluations are reasonably costly, so if you perform a process that combines a large number of method calls in a huge number of iterations, it will be much slower than you wrote in C or Rust. That is often the case. In that case, you might consider rewriting with Rust.
What you would like to expect from Rust's speedup is parallel / parallel programming. Rust advocates "Fearless Concurrency" [^ fc], and it seems that parallel programming has a mechanism that is less likely to be covered with bugs, and it seems that parallelization can be done very easily with highly parallel processing [^ para]. ].
[^ fc]: It is also the Chapter of The Rust Programming Language (TRPL).
[^ para]: In my near-zero Rust experience, the execution time was halved just by adding a little parallelization using rayon. was there.
It's related to the story of wanting speed, but isn't it possible that memory consumption can be reduced by Rusting the processing that causes an extremely large amount of garbage in Ruby? Garbage collection will occur frequently in programs that keep running, such as web applications. Performance may improve if the frequency is reduced.
For example, morphological analysis is likely to be a process in which garbage is likely to occur. Ruby also has a morphological analysis library based on MeCab, Juman ++, etc., so you can easily use morphological analysis. However, even if you just want to extract only nouns from the text, for example, a large amount of extra character strings will be generated. This is because the information obtained from those libraries is, for example, for each morpheme (using MeCab as an example).
Is a particle,Case particles,General,*,*,*,But,Moth,Moth
It is a character string (the tab after "ga").
If you divide this by tabs and commas, you can create a number of String objects. Most of them are unnecessary. These become garbage.
So, when I compare the part of speech with the " noun " ... and so on, I feel that it seems to be inefficient [^ inefficient].
[^ inefficient]: I don't know if it's really inefficient unless I measure it properly.
Since Rust manages memory without using garbage collection, it may be efficient if Rust is in charge of morphological analysis and extracting necessary information and passing the result to a Ruby script. ..
What about other than performance?
Sometimes you want to use some of the best Rust tools and libraries from Ruby. It is quite natural to use C software in Ruby, and most of the so-called "extension libraries" are probably made in C. Writing an extension library to be widely used in Rust is a high hurdle in that it requires a Rust compiler at the installation destination, but it is quite conceivable if it is an in-house tool.
The use of Rust software in Ruby, even if it's not in the form of an extension library, will increase in the future.
You could also use Ruby from Rust.
It is often the case that the process that can be written very concisely in Ruby is very troublesome in Rust, C, C ++, etc. It may be possible to partially write such processing in Ruby.
In fact, Rutie [^ rutie] seems to have a mechanism to call Ruby code from the Rust side.
[^ rutie]: One of the mechanisms that connects Ruby and Rust. https://github.com/danielpclark/rutie
Ruby called from Rust side may also be a candidate for mruby. Reference: mruby-sys