3 ms·

> But I never found good use of it outside of small projects. Any serious business work becomes very painful to maintain and stay on top of for bigger projects.

> But I never found good use of it outside of small projects. Any serious business work becomes very painful to maintain and stay on top of for bigger projects. It's the ultimate irony reading statement like these, when ruby powers some of the largest web applications on the web today and handling millions of users and requests. Github, Gitlab, Shopify, Stripe, AirBnb, Crunchbase, Dribbble, Kickstarter, .. etc I'm not sure how many more are needed for this meme to die. Is ruby perfect? absolutely not, but to neither is any other language. You will always have to tweak things regardless of the tool you chose, because scaling is difficult.

pdimitar 7y ago
> You will always have to tweak things regardless of the tool you chose, because scaling is difficult. With some technologies, like Erlang/Elixir, scaling is almost effortless though. Only the deployment platforms with very strict boundaries like Heroku make it pretty much impossible to shard and distribute load. With most VPS-es you just share one file between them, introduce a well-setup VPC, and you're done, your servers are distributing load and you spent like an afternoon on it. Additionally, with very fast languages like Go and Rust (even Elixir but only on I/O bound projects, which is like most of them?) you delay your scaling measures that far in the future that most apps never even need to grow beyond one app server and one DB server, and the team never actually even thinks about scaling at all. Because let's face it, most apps will never exceed 500x - 5000x reqs/sec. A well-made Phoenix web app or API gateway easily achieves 500 reqs/sec even on a Raspberry Pi 4. I used Rails for 6 years and deployed it on Heroku, company-rolled Dokku setups, AWS EC2, DigitalOcean droplets and GCP -- usually servers in the range of $25 - $100 per month (I usually work for small or medium-small businesses). I hated that beyond 10-20 reqs/sec we had to start beefing up the server or add others. It's just how Rails (or rather, ActiveRecord) is: very inefficient, optimised for human productivity, and to hell with machine resources. Many business still like it though and that's cool with me. They don't mind a mean response time of 300ms with the minority of responses (95-th percentile) going to 2500+ ms. > Github, Gitlab, Shopify, Stripe, AirBnb, Crunchbase, Dribbble, Kickstarter, .. etc I wish for that meme to die. Bigger players using it means absolutely nothing except that they have the budget to keep working with Rails even after it showed its warts (hard to maintain when the project grows and big hosting costs being the top 2). Smaller players like Basecamp have very stringent policies on how to work with it. I've seen local companies utilise similar techniques mostly successfully. More power to them. I know it can be made to work with the right management techniques. Half-related: do remember that Facebook preferred to make a PHP runtime and maintain it, as opposed to actually train programmers to use another backend language. > I'm not sure how many more are needed for this meme to die. You might call it a meme. I call it "I tried for years and eventually got frustrated and moved on". Nothing against Ruby or even Rails. But they make me think of scalability much, much earlier compared to a "slow" dynamic language like Elixir (even though it maintains predictable lag even under very heavy load... and its Phoenix framework mean response time in identical setups as the Rails projects is between 5ms to 30ms). Let's not even introduce Go or Rust web apps in this picture. If made well (although that takes much more effort than Rails or Phoenix so for me their human productivity tradeoffs aren't worth it!) they can easily serve anywhere from 5_000x to 30_000x reqs/sec on the cheap business VPS-es ($25 - $100 a month). In all fairness, those had to use a bit more expensive DB servers though ($250+) because the cheaper DB servers couldn't keep up with the demand.

pdimitar 7y ago

> You will always have to tweak things regardless of the tool you chose, because scaling is difficult. With some technologies, like Erlang/Elixir, scaling is almost effortless though. Only the deployment platforms with very strict boundaries like Heroku make it pretty much impossible to shard and distribute load. With most VPS-es you just share one file between them, introduce a well-setup VPC, and you're done, your servers are distributing load and you spent like an afternoon on it. Additionally, with very fast languages like Go and Rust (even Elixir but only on I/O bound projects, which is like most of them?) you delay your scaling measures that far in the future that most apps never even need to grow beyond one app server and one DB server, and the team never actually even thinks about scaling at all. Because let's face it, most apps will never exceed 500x - 5000x reqs/sec. A well-made Phoenix web app or API gateway easily achieves 500 reqs/sec even on a Raspberry Pi 4. I used Rails for 6 years and deployed it on Heroku, company-rolled Dokku setups, AWS EC2, DigitalOcean droplets and GCP -- usually servers in the range of $25 - $100 per month (I usually work for small or medium-small businesses). I hated that beyond 10-20 reqs/sec we had to start beefing up the server or add others. It's just how Rails (or rather, ActiveRecord) is: very inefficient, optimised for human productivity, and to hell with machine resources. Many business still like it though and that's cool with me. They don't mind a mean response time of 300ms with the minority of responses (95-th percentile) going to 2500+ ms. > Github, Gitlab, Shopify, Stripe, AirBnb, Crunchbase, Dribbble, Kickstarter, .. etc I wish for that meme to die. Bigger players using it means absolutely nothing except that they have the budget to keep working with Rails even after it showed its warts (hard to maintain when the project grows and big hosting costs being the top 2). Smaller players like Basecamp have very stringent policies on how to work with it. I've seen local companies utilise similar techniques mostly successfully. More power to them. I know it can be made to work with the right management techniques. Half-related: do remember that Facebook preferred to make a PHP runtime and maintain it, as opposed to actually train programmers to use another backend language. > I'm not sure how many more are needed for this meme to die. You might call it a meme. I call it "I tried for years and eventually got frustrated and moved on". Nothing against Ruby or even Rails. But they make me think of scalability much, much earlier compared to a "slow" dynamic language like Elixir (even though it maintains predictable lag even under very heavy load... and its Phoenix framework mean response time in identical setups as the Rails projects is between 5ms to 30ms). Let's not even introduce Go or Rust web apps in this picture. If made well (although that takes much more effort than Rails or Phoenix so for me their human productivity tradeoffs aren't worth it!) they can easily serve anywhere from 5_000x to 30_000x reqs/sec on the cheap business VPS-es ($25 - $100 a month). In all fairness, those had to use a bit more expensive DB servers though ($250+) because the cheaper DB servers couldn't keep up with the demand.