4 ms·

I’d say the slowness of Ruby is really over exaggerated. For most web applications it’s good enough, and the speed of development (how fast you can ship) almost

by fyfy18 8y ago

I’d say the slowness of Ruby is really over exaggerated. For most web applications it’s good enough, and the speed of development (how fast you can ship) almost always outweighs any costs from it being slow. You can always replace the endpoints that are slow with something written in a more performant language like Golang or Erlang later. I’ve worked on all sorts of applications from corporate CRUD to mobile billing gateways written in Ruby (usually Rails), and in very few cases has Ruby itself been the bottleneck.

meesterdude 8y ago
iirc, the ruby 3x3 benchmark project is getting a ruby game (i think mario) to run at 60fps, and ruby 2.5 already hit that target. even if it's slow today; the runtime is being improved regularly and making a lot of code just faster with a version bump.
technion 8y ago
I think the rise of Mastodon is really pouring some hot water on that meme. Lots of really small VPSs are running some fairly big instances. Although I'm only personally using one of them, it's very fast, and the general view is that isn't unusual. I get that it won't hit Twitter scale but that matches the majority of "how do I build a prototype" use cases.
- busterarm 8y ago
  "Twitter scale" wasn't so much a Ruby/Rails problem as it was an RDBMS (write-many + read-many = road to fail) and writing their own in-house message queue problem. Starling performed worse than just about everything else out there (and their Scala replacement Kestrel isn't much better). One really insipid blog post and thousands of mindless followers later and the damage to Rails has been done. That's not to say Rails doesn't/didn't have other issues -- it did. It's just telling that Twitter is the first example people reach for instead of anything else.
  - jaggederest 8y ago
    Agreed. I've been working mostly in Ruby since 2006, over hundreds or thousands of apps, depending on how you count, and I have only worked on 2 apps that actually had scaling problems with Ruby. The rest were 100% improperly designed or scaled databases. Twitter is certainly of a scale that I would not be using Ruby on the primary load points. But even billion dollar companies don't often reach that scale.
    - jaequery 8y ago
      at twitter’s scale, its not jus ruby, you would also have problems with php, python, node, and maybe even java. only language that will work well at that point are languages built for concurrencies such as scala, elixir, and go.
      - busterarm 8y ago
        Or you break out your infrastructure into smaller components and move the more demanding/critical parts of your infrastructure to that other language and keep everything else you've built!
Perseids 8y ago
I second that resources consumption with Rails on the production system is only a problem in specific settings (e.g. when your business model depends on many cheap transactions, or when you are running on diverse sets of hosts outside of your control… I'm looking at you, GitLab). Nonetheless, as a junior Rails developer coming into a 5 people team on a mid-sized project, I saw a diverse set of performance problems during the development phase. E.g. asset pipelines that take ages to compile so that rapid development cycles become impossible or a test suite that took heroic efforts to get down to 15 minutes despite not really doing much computationally-wise. I'm open to alternative interpretations, but I've got the impression that in more performance oriented frameworks the best practice would not turn out to be setting up and tearing down half your server stack before and after each controller test, but instead we would have chosen abstractions that can be plugged together more efficiently.
WJW 8y ago
There are some properly large companies like github and shopify that run a large rails stack, it seems to work out pretty well for them. At my current workplace we have some streaming servers pushing about 15 gigabyte/second at peak load and the ruby processes easily saturate the available bandwidth on the EC2 instances. Like you say, the slowness of Ruby is greatly exaggerated. Sure we could rewrite the whole thing in Go/C++/Rust/etc, but it would not work any better and the gain of using 10% CPU instead of 20 is not really relevant since it's the NIC that is the bottleneck.
always_good 8y ago
> You can always replace the endpoints that are slow with something written in a more performant language like Golang or Erlang later. Maybe in an API server. But this is nontrivial in a monolithic application where you end up yakshaving the whole middleware stack to parity just to replace an endpoint.

by fyfy18 8y ago

meesterdude 8y ago

iirc, the ruby 3x3 benchmark project is getting a ruby game (i think mario) to run at 60fps, and ruby 2.5 already hit that target. even if it's slow today; the runtime is being improved regularly and making a lot of code just faster with a version bump.

technion 8y ago

I think the rise of Mastodon is really pouring some hot water on that meme. Lots of really small VPSs are running some fairly big instances. Although I'm only personally using one of them, it's very fast, and the general view is that isn't unusual. I get that it won't hit Twitter scale but that matches the majority of "how do I build a prototype" use cases.

busterarm 8y ago
"Twitter scale" wasn't so much a Ruby/Rails problem as it was an RDBMS (write-many + read-many = road to fail) and writing their own in-house message queue problem. Starling performed worse than just about everything else out there (and their Scala replacement Kestrel isn't much better). One really insipid blog post and thousands of mindless followers later and the damage to Rails has been done. That's not to say Rails doesn't/didn't have other issues -- it did. It's just telling that Twitter is the first example people reach for instead of anything else.
- jaggederest 8y ago
  Agreed. I've been working mostly in Ruby since 2006, over hundreds or thousands of apps, depending on how you count, and I have only worked on 2 apps that actually had scaling problems with Ruby. The rest were 100% improperly designed or scaled databases. Twitter is certainly of a scale that I would not be using Ruby on the primary load points. But even billion dollar companies don't often reach that scale.
  - jaequery 8y ago
    at twitter’s scale, its not jus ruby, you would also have problems with php, python, node, and maybe even java. only language that will work well at that point are languages built for concurrencies such as scala, elixir, and go.
    - busterarm 8y ago
      Or you break out your infrastructure into smaller components and move the more demanding/critical parts of your infrastructure to that other language and keep everything else you've built!

Perseids 8y ago

I second that resources consumption with Rails on the production system is only a problem in specific settings (e.g. when your business model depends on many cheap transactions, or when you are running on diverse sets of hosts outside of your control… I'm looking at you, GitLab). Nonetheless, as a junior Rails developer coming into a 5 people team on a mid-sized project, I saw a diverse set of performance problems during the development phase. E.g. asset pipelines that take ages to compile so that rapid development cycles become impossible or a test suite that took heroic efforts to get down to 15 minutes despite not really doing much computationally-wise. I'm open to alternative interpretations, but I've got the impression that in more performance oriented frameworks the best practice would not turn out to be setting up and tearing down half your server stack before and after each controller test, but instead we would have chosen abstractions that can be plugged together more efficiently.

WJW 8y ago

There are some properly large companies like github and shopify that run a large rails stack, it seems to work out pretty well for them. At my current workplace we have some streaming servers pushing about 15 gigabyte/second at peak load and the ruby processes easily saturate the available bandwidth on the EC2 instances. Like you say, the slowness of Ruby is greatly exaggerated. Sure we could rewrite the whole thing in Go/C++/Rust/etc, but it would not work any better and the gain of using 10% CPU instead of 20 is not really relevant since it's the NIC that is the bottleneck.

always_good 8y ago

> You can always replace the endpoints that are slow with something written in a more performant language like Golang or Erlang later. Maybe in an API server. But this is nontrivial in a monolithic application where you end up yakshaving the whole middleware stack to parity just to replace an endpoint.