7 ms·

Interesting choice on Ruby. Why Ruby in first place ?

by revskill 3y ago

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.
fdr 3y ago
I work on Ubicloud. REPL, testing, a few key high quality libraries. In turn: The REPL: lets you have unified development and operation. Makes it easy to record and review methodology when taking administrative action. Testing: both made more necessary by the dynamic typing of Ruby, but more importantly, without disturbing the program under test much you can inject any input, any fault, nearly anywhere. In this way you can accrete invariants guarding against a large class of bugs encountered in production into the test suite, a form of retained learning. The libraries: Sequel, Roda, Rodauth, part of the Jeremy Evans universe. They're very good by any standard, not even as confined to the Ruby world. The maintenance level on those is something I aspire to, but have never been able to duplicate. I did copy the 100% line (and later, branch) coverage project practice from this, though, in Citus Cloud and later projects, and it seems like a good thing, though not for the reasons people might anticipate. An anti-requirement: control planes often have fairly lax performance needs relative to operation value. A few crucial loops, like monitoring, may indicate something with more efficient machine code. But mostly it's a fancy SSH client with quite a few tests, and some carefully designed concurrency patterns. Of the above factors, I'd say the REPL is the most dispositive for why I tolerate the performance and parallelism ramifications of Ruby, though, they all add something to my decision to use it for this. This design theory is the fourth in a progression for me, though there are other clades by now. Heroku Postgres was the first, Citus Cloud was the second, Crunchy Bridge is the third, this is the fourth.
- throwawaymaths 3y ago
  I'd have picked elixir... Much better concurrency and distribution support. SSH is built into the (erlang) standard lib, really fantastic support for templating via EEx (if you're using libvirt, e.g.). Easy to deploy as an on-metal or containerized platform using releases. Ruby deployment dependency management can be tricky unless you have a way to isolate from the host (containers e.g.) but that's not the best for being a hypervisor.
  - fdr 3y ago
    I've considered at various points (but not with deep seriousness I admit), typescript, julia, scala, swift. You might notice all of these have a REPL in common. Elixir might be a reasonable alternative, but not one I exercised here. In areas I wanted to take risk, I had some other stuff going on.

Interesting choice on Ruby. Why Ruby in first place ?

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.

fdr 3y ago

I work on Ubicloud. REPL, testing, a few key high quality libraries. In turn: The REPL: lets you have unified development and operation. Makes it easy to record and review methodology when taking administrative action. Testing: both made more necessary by the dynamic typing of Ruby, but more importantly, without disturbing the program under test much you can inject any input, any fault, nearly anywhere. In this way you can accrete invariants guarding against a large class of bugs encountered in production into the test suite, a form of retained learning. The libraries: Sequel, Roda, Rodauth, part of the Jeremy Evans universe. They're very good by any standard, not even as confined to the Ruby world. The maintenance level on those is something I aspire to, but have never been able to duplicate. I did copy the 100% line (and later, branch) coverage project practice from this, though, in Citus Cloud and later projects, and it seems like a good thing, though not for the reasons people might anticipate. An anti-requirement: control planes often have fairly lax performance needs relative to operation value. A few crucial loops, like monitoring, may indicate something with more efficient machine code. But mostly it's a fancy SSH client with quite a few tests, and some carefully designed concurrency patterns. Of the above factors, I'd say the REPL is the most dispositive for why I tolerate the performance and parallelism ramifications of Ruby, though, they all add something to my decision to use it for this. This design theory is the fourth in a progression for me, though there are other clades by now. Heroku Postgres was the first, Citus Cloud was the second, Crunchy Bridge is the third, this is the fourth.

throwawaymaths 3y ago
I'd have picked elixir... Much better concurrency and distribution support. SSH is built into the (erlang) standard lib, really fantastic support for templating via EEx (if you're using libvirt, e.g.). Easy to deploy as an on-metal or containerized platform using releases. Ruby deployment dependency management can be tricky unless you have a way to isolate from the host (containers e.g.) but that's not the best for being a hypervisor.
- fdr 3y ago
  I've considered at various points (but not with deep seriousness I admit), typescript, julia, scala, swift. You might notice all of these have a REPL in common. Elixir might be a reasonable alternative, but not one I exercised here. In areas I wanted to take risk, I had some other stuff going on.