5 ms·

If you look at the breakdown per service, EC2 (assuming mostly Ruby) seem to be at best 20% of the bill: https://twitter.com/dhh/status/1613508201953038337 http

by byroot 4y ago

If you look at the breakdown per service, EC2 (assuming mostly Ruby) seem to be at best 20% of the bill: https://twitter.com/dhh/status/1613508201953038337 https://twitter.com/dhh/status/1613508201953038337 So if you are to make Ruby ~10% faster, you might reduce Basecamp hosting bill by 2% at best.

DoctorOW 4y ago
> Remember, this excludes the current Basecamp and Basecamp 2, which use our own hardware for this https://dev.37signals.com/our-cloud-spend-in-2022/ https://dev.37signals.com/our-cloud-spend-in-2022/
pantulis 4y ago
Thanks for spotting that, I had missed it! This goes to show (again) that the "Ruby/Rails does not scale" myth is fictional.
- earthnail 4y ago
  There are organisational scaling issues that you may hit with a language like Ruby that strongly typed languages like Java can solve. And so Ruby may scale in cpu performance, but not with your number of teams. That’s why Spotify switched to Java (I think they were a heavy Python user before that, not Ruby, but not sure anymore - but the organisational problem is the same for those two). Note that I still choose Rails for all my projects, but my company is small.
  - gtirloni 4y ago
    > There are organisational scaling issues that you may hit with a language like Ruby that strongly typed languages like Java can solve. Such as?
    - pantulis 4y ago
      This also interested me. I'd guess that the idea parent is trying to convey is that for a given size of a Ruby codebase the engineering organization needs to be structured like successful cases like Github, Shopify or whatever, but I'd be interested in the technical aspect to this. I agree with this idea when reasoning about microservices, but this is the first time I've seen it applied to the choice of language. It's intriguing.
      - gtirloni 4y ago
        Judging by parent poster's comments everywhere, they have an habit of saying such facts without much substance. I wouldn't hold my breath but I'm interested as well.

by byroot 4y ago

DoctorOW 4y ago

> Remember, this excludes the current Basecamp and Basecamp 2, which use our own hardware for this https://dev.37signals.com/our-cloud-spend-in-2022/ https://dev.37signals.com/our-cloud-spend-in-2022/

pantulis 4y ago

Thanks for spotting that, I had missed it! This goes to show (again) that the "Ruby/Rails does not scale" myth is fictional.

earthnail 4y ago
There are organisational scaling issues that you may hit with a language like Ruby that strongly typed languages like Java can solve. And so Ruby may scale in cpu performance, but not with your number of teams. That’s why Spotify switched to Java (I think they were a heavy Python user before that, not Ruby, but not sure anymore - but the organisational problem is the same for those two). Note that I still choose Rails for all my projects, but my company is small.
- gtirloni 4y ago
  > There are organisational scaling issues that you may hit with a language like Ruby that strongly typed languages like Java can solve. Such as?
  - pantulis 4y ago
    This also interested me. I'd guess that the idea parent is trying to convey is that for a given size of a Ruby codebase the engineering organization needs to be structured like successful cases like Github, Shopify or whatever, but I'd be interested in the technical aspect to this. I agree with this idea when reasoning about microservices, but this is the first time I've seen it applied to the choice of language. It's intriguing.
    - gtirloni 4y ago
      Judging by parent poster's comments everywhere, they have an habit of saying such facts without much substance. I wouldn't hold my breath but I'm interested as well.