6 ms·

Why not?

by joshmn 3y ago

Why not?

sigmonsays 3y ago
top three reasons to not use ruby for me are: 1. it's not compiled and evaluated at runtime, which make it harder to test. Pesky undefined variables in edge case code.. 2. deployment is tough when it's a ton of small files. Most things compile to a single executable binary 3. it's not concurrent or parallel easily. You're not going to easily use all your cores and also develop sane software.
- lockhouse 3y ago
  If I'm not mistaken, the vast majority of web app backends are written in interpreted languages like Ruby, such as PHP, Python, JavaScript, and Perl. For example, Github, Shopify, and Hulu were written with Ruby on Rails and they seem to do alright.
  - senorrib 3y ago
    "All right" is a stretch. Shopify employs a lot of amazing compiler engineers to constantly evolve the ruby compiler/VM to squeeze as much performance as possible without affecting the regular engineers, something most startups cannot do.
    - firecall 3y ago
      That's true of many companies at scale though. :-) Some of the work on Ruby and Rails that Shopify and Github have produced is available to the community as well. For instance: https://github.blog/2022-08-25-introducing-trilogy-a-new-database-adapter-for-ruby-on-rails/ https://github.blog/2022-08-25-introducing-trilogy-a-new-dat... Facebook heavily use, or did use, PHP dont they? IIRC the Threads backend is Python as well. Which seems to be doing OK!
    - fulafel 3y ago
      Being engaged in cost optimization engineering after you've "made it" doesn't mean failure, quite the opposite. And the parts before that are much harder bottlenecks, where other aspects of tech choices are rightfully weighed more.
- fulafel 3y ago
  Ruby parallelism with request-based server apps probably works the same as other managed languages with single threaded runtimes (eg v8, Python) - you run multiple server processes. Requests are independent so its's an "embarassingly parallel" problem without need for communication between threads of execution.
- vidarh 3y ago
  If you deploy in a container (and if not, why?), the number of files is irrelevant. Difficulties using all your cores with Ruby was a problem when I first started using it 18 years ago. It hasn't really been a problem for things like web serving for the last ~15 or so.
bickfordb 3y ago
Ruby web applications have a history of absurdly high resource usage and failure stories compared with something like Go. If the selling point of this is for individuals and small businesses to run this instead of AWS/GCP, it may not be any cheaper once you start running this control plane.
- vidarh 3y ago
  AWS/GCP is frequently 2x-3x as expensive as doing it yourself, depending on your usage patterns as some things are vastly more overpriced than others (e.g. egress), sometimes a bit lower, but if your control plane is more than a rounding error in your overall cost you're doing something very wrong.

Why not?

by joshmn 3y ago

Why not?

top three reasons to not use ruby for me are: 1. it's not compiled and evaluated at runtime, which make it harder to test. Pesky undefined variables in edge case code.. 2. deployment is tough when it's a ton of small files. Most things compile to a single executable binary 3. it's not concurrent or parallel easily. You're not going to easily use all your cores and also develop sane software.

lockhouse 3y ago
If I'm not mistaken, the vast majority of web app backends are written in interpreted languages like Ruby, such as PHP, Python, JavaScript, and Perl. For example, Github, Shopify, and Hulu were written with Ruby on Rails and they seem to do alright.
- senorrib 3y ago
  "All right" is a stretch. Shopify employs a lot of amazing compiler engineers to constantly evolve the ruby compiler/VM to squeeze as much performance as possible without affecting the regular engineers, something most startups cannot do.
  - firecall 3y ago
    That's true of many companies at scale though. :-) Some of the work on Ruby and Rails that Shopify and Github have produced is available to the community as well. For instance: https://github.blog/2022-08-25-introducing-trilogy-a-new-database-adapter-for-ruby-on-rails/ https://github.blog/2022-08-25-introducing-trilogy-a-new-dat... Facebook heavily use, or did use, PHP dont they? IIRC the Threads backend is Python as well. Which seems to be doing OK!
  - fulafel 3y ago
    Being engaged in cost optimization engineering after you've "made it" doesn't mean failure, quite the opposite. And the parts before that are much harder bottlenecks, where other aspects of tech choices are rightfully weighed more.
fulafel 3y ago
Ruby parallelism with request-based server apps probably works the same as other managed languages with single threaded runtimes (eg v8, Python) - you run multiple server processes. Requests are independent so its's an "embarassingly parallel" problem without need for communication between threads of execution.
vidarh 3y ago
If you deploy in a container (and if not, why?), the number of files is irrelevant. Difficulties using all your cores with Ruby was a problem when I first started using it 18 years ago. It hasn't really been a problem for things like web serving for the last ~15 or so.

bickfordb 3y ago

Ruby web applications have a history of absurdly high resource usage and failure stories compared with something like Go. If the selling point of this is for individuals and small businesses to run this instead of AWS/GCP, it may not be any cheaper once you start running this control plane.

vidarh 3y ago
AWS/GCP is frequently 2x-3x as expensive as doing it yourself, depending on your usage patterns as some things are vastly more overpriced than others (e.g. egress), sometimes a bit lower, but if your control plane is more than a rounding error in your overall cost you're doing something very wrong.