4 ms·

Maybe start moving away from Ruby on Rails. Good web stacks in Golang and Rust do exist and at that scale they're likely the only sensible choices. How far mus

Maybe start moving away from Ruby on Rails. Good web stacks in Golang and Rust do exist and at that scale they're likely the only sensible choices. How far must the sunk cost fallacy go before something is done?

speedgoose 4y ago
Which Golang or rust web stacks are as good as rails?
- pdimitar 4y ago
  I'm not saying they are as good -- I'm saying that they are good. Meaning that at one point extra programmer difficulty is worth it if your everyday web stack can't keep up.
  - speedgoose 4y ago
    Oh I see. It’s difficult to justify replacing rails, that has been successfully used for many years, by something not as good (worse?).
    - pdimitar 4y ago
      Rails is convenient and intuitive, I don't think anyone reasonable is arguing that. My point is that if the stack regularly falls over then the programmer convenience has to be sacrificed in favor of stable and mega-fast alternative that requires more programmer energy. I love working with dynamic languages. I can prototype almost anything that I want to do, in hours. But I also recognized the need for a hardcore stack for a previous contract and went the long and painful route with Rust. Result: the project is running for 7 months now, has only been restarted 4 times for updating it (re-deployment), never crashed once, handles 5000+ network connections and streams data from them 24/7. Peak CPU usage on a 4-core VPS: 27%. Peak memory usage: 180MB. Normal average memory usage: 80MB. Right tool for the job.
      - eddsh1994 4y ago
        Why do you assume the outages are language related and not due to the complex product having bugs? How does Rust prevent bad schema changes or missing data in the DB?
        pdimitar 4y ago
        Because I worked with Rails for 6.5 years. Outages beyond smaller scales were at best a weekly occurrence. Obviously I can't know for sure but it's not an uninformed assumption.
        byroot 4y ago
        You know you can just click on the post title, that will open the posted link in which you can read the detailed cause of all the outages they had that month. If you do this, you will realize that none are close to what you describe. Also have you considered that if you had weekly outage when billion dollars companies continued to stick with Rails, maybe you were the problem?
        pdimitar 4y ago
        I did read the article. One of the incidents was about their webhook worker(s) being swamped -- plus had errors due to deleted DB workloads that were necessary for the event to be processed. So I'd count that one as a slow endpoint attributed to Ruby on Rails (and it's famous for that). And even if zero of their incidents alluded to performance problems with Rails I still worked a lot with it and I know for a fact that it's a factor. Your snark doesn't change reality but you are free to pretend otherwise, fine with me. > Also have you considered that if you had weekly outage when billion dollars companies continued to stick with Rails, maybe you were the problem? Indeed, a programmer not having executive powers to influence change of deployment tech and server (was Puma at the time) is indeed me being a problem, surely. Especially after he made a study demonstrating the problems and calculated how much programmer time is wasted on these matters every week and he still got ignored. Perhaps I am the problem indeed!
darksaints 4y ago
Rails is a huge problem, but the most mature libraries/frameworks in Go/Rust are all micro-frameworks, which isn't much of a replacement. Maybe some .NET frameworks would be a better choice.
- pdimitar 4y ago
  Well I mean if stability plus performance are the main requirements then I'd disqualify everything except Rust. Though I'd personally do it in Elixir but again, speed. GitHub is huge and should rise up to the challenge.
- hit8run 4y ago
  It’s quite the opposite: Rails is a big enabler.
  - pdimitar 4y ago
    Only in the first project phases. After that the teams start fighting over which MV-ABCXYZ abstraction to use. :) I've seen good and productive Rails teams but they had to deliberately stop themselves from certain practices, otherwise they ran into problems. Long topic though, and people get very emotional and preachy defending Rails so it's a fruitless discussion 99.9% of the time. In the end use what you feel works best for you and your team. Objective differences in programmer productivity, machine speed, iteration speed and other metrics does exist though and it's very tiring to see people constantly pretend otherwise.
  - darksaints 4y ago
    The only thing Rails enables is getting started quickly. Maintenance is a complete nightmare. I have no problem refactoring large Scala apps or F# apps or even Rust apps...but that one fucking Rails app I have in my portfolio is the absolute worst. Still stuck on rails 4 because the time I upgraded it to 4 took two whole weeks of my life away from me. Never again. I'd rather rewrite from scratch than do that again.
hit8run 4y ago
Because you like Go or Rust better? Makes sense… muhahaha
- pdimitar 4y ago
  I don't like either very much. But I've worked with them extensively and they are a better fit for when you want to squeeze more resources and more stability (the latter depends on certain details but it's certainly easier to achieve compared to Rails).

speedgoose 4y ago

Which Golang or rust web stacks are as good as rails?

pdimitar 4y ago
I'm not saying they are as good -- I'm saying that they are good. Meaning that at one point extra programmer difficulty is worth it if your everyday web stack can't keep up.
- speedgoose 4y ago
  Oh I see. It’s difficult to justify replacing rails, that has been successfully used for many years, by something not as good (worse?).
  - pdimitar 4y ago
    Rails is convenient and intuitive, I don't think anyone reasonable is arguing that. My point is that if the stack regularly falls over then the programmer convenience has to be sacrificed in favor of stable and mega-fast alternative that requires more programmer energy. I love working with dynamic languages. I can prototype almost anything that I want to do, in hours. But I also recognized the need for a hardcore stack for a previous contract and went the long and painful route with Rust. Result: the project is running for 7 months now, has only been restarted 4 times for updating it (re-deployment), never crashed once, handles 5000+ network connections and streams data from them 24/7. Peak CPU usage on a 4-core VPS: 27%. Peak memory usage: 180MB. Normal average memory usage: 80MB. Right tool for the job.
    - eddsh1994 4y ago
      Why do you assume the outages are language related and not due to the complex product having bugs? How does Rust prevent bad schema changes or missing data in the DB?
      - pdimitar 4y ago
        Because I worked with Rails for 6.5 years. Outages beyond smaller scales were at best a weekly occurrence. Obviously I can't know for sure but it's not an uninformed assumption.
        byroot 4y ago
        You know you can just click on the post title, that will open the posted link in which you can read the detailed cause of all the outages they had that month. If you do this, you will realize that none are close to what you describe. Also have you considered that if you had weekly outage when billion dollars companies continued to stick with Rails, maybe you were the problem?
        pdimitar 4y ago
        I did read the article. One of the incidents was about their webhook worker(s) being swamped -- plus had errors due to deleted DB workloads that were necessary for the event to be processed. So I'd count that one as a slow endpoint attributed to Ruby on Rails (and it's famous for that). And even if zero of their incidents alluded to performance problems with Rails I still worked a lot with it and I know for a fact that it's a factor. Your snark doesn't change reality but you are free to pretend otherwise, fine with me. > Also have you considered that if you had weekly outage when billion dollars companies continued to stick with Rails, maybe you were the problem? Indeed, a programmer not having executive powers to influence change of deployment tech and server (was Puma at the time) is indeed me being a problem, surely. Especially after he made a study demonstrating the problems and calculated how much programmer time is wasted on these matters every week and he still got ignored. Perhaps I am the problem indeed!

darksaints 4y ago

Rails is a huge problem, but the most mature libraries/frameworks in Go/Rust are all micro-frameworks, which isn't much of a replacement. Maybe some .NET frameworks would be a better choice.

pdimitar 4y ago
Well I mean if stability plus performance are the main requirements then I'd disqualify everything except Rust. Though I'd personally do it in Elixir but again, speed. GitHub is huge and should rise up to the challenge.
hit8run 4y ago
It’s quite the opposite: Rails is a big enabler.
- pdimitar 4y ago
  Only in the first project phases. After that the teams start fighting over which MV-ABCXYZ abstraction to use. :) I've seen good and productive Rails teams but they had to deliberately stop themselves from certain practices, otherwise they ran into problems. Long topic though, and people get very emotional and preachy defending Rails so it's a fruitless discussion 99.9% of the time. In the end use what you feel works best for you and your team. Objective differences in programmer productivity, machine speed, iteration speed and other metrics does exist though and it's very tiring to see people constantly pretend otherwise.
- darksaints 4y ago
  The only thing Rails enables is getting started quickly. Maintenance is a complete nightmare. I have no problem refactoring large Scala apps or F# apps or even Rust apps...but that one fucking Rails app I have in my portfolio is the absolute worst. Still stuck on rails 4 because the time I upgraded it to 4 took two whole weeks of my life away from me. Never again. I'd rather rewrite from scratch than do that again.

hit8run 4y ago

Because you like Go or Rust better? Makes sense… muhahaha

pdimitar 4y ago
I don't like either very much. But I've worked with them extensively and they are a better fit for when you want to squeeze more resources and more stability (the latter depends on certain details but it's certainly easier to achieve compared to Rails).