Through Highscalability.com I came across a case study titled "How Rust is Tilde’s Competitive Advantage" in which it is explained how the company saved time and money (the customer's and their own) and created a very robust monitoring agent for their service. They were apparently also able to "retrain" their workforce without spending an excessive amount of time on the training or handling gratuitous complexity.
The first version was in Ruby, sometimes exceeded 100MB in memory occupation, wasn't very robust and created issues for their customers.
The new version was in Rust, its memory occupation was around 8MB, the customers were happier and they were able to deliver more features with the same occupation of memory and stability.
(taken from the case study)
I find this very remarkable.
Not being fluent in either language I would be curious to know if they considered Go at all and if so why they discarded it.
Bonus point: our own @vaidehijoshi is quoted in the case study :-)
You can find it here: "How Rust is Tilde’s Competitive Advantage"
Top comments (8)
Their switch makes total sense for the resource constraints and the low level at which they are operating. It should probably not be read as the article advocating migrating your rails app to rust.
No, definitely not :-) I just intended as a case study about when to use Rust instead of Ruby to improve performance
Using less memory doesn't mean a performance improvement. It's just space optimization.
My definition of performance improvement doesn't only mean that a piece of code is going to be "faster", it also means that it's going to perform better than the one it replaces.
The Rust code according to the PDF performs better because it has a constant memory occupation, it doesn't crash and it's more "deterministic".
It uses less resource -> performs better -> performance improvement.
You don't agree?
And I can't imagine reading and writing 8MB of memory has worse CPU usage than managing 100MB with a garbage collector also involved. The article doesn't directly mention CPU, but says that their Rust solution was the clear winner in "raw performance".
In your particular case, using less memory performs better (I don't doubt it) but in general this is not true. For instance take any DBMS, if you give it not enough memory it will perform worse because the cache hits will be low (ideally it should be near 100%). Give it a lot of memory and it will fly because most of the pages will be retrieved from cache instead of disk.
ps: I don't know Ruby or Rust.
I understand your point but I think we are talking about two different things :)
Obviously if you restrict the available memory of a piece of code it's going to perform worse, because as you said it is not enough.
Thanks!