4 ms·

I have a question and anecdote. I’ve been on teams in the past that had to deal with rails apps (legacy code usually) and I found ruby to be really difficult t

I have a question and anecdote. I’ve been on teams in the past that had to deal with rails apps (legacy code usually) and I found ruby to be really difficult to understand. There are so many ways to do one thing, and with the rails addition there are now so many conventions to follow. Then when those conventions don’t work anymore, and the code base goes off the rails (no pun intended) and the out of the box conventions no longer make sense. Granted most of my experience is writing Go, followed by dart, swift, and typescript. I have a hard time navigating codebase of a dynamic language and it’s a pita to have to rely on tests (not everyone writes good tests). I use Go for all my backend tasks and it is not only fast performance, but really easy to be productive in because there is usually one way to do things and the std lib is amazing. Where does rails fit in? Like I can build an entire production ready backend service that can scale in like 2 days with Go that is easy to deploy and maintain, and not need to bring in any big Go framework or libs besides like uuid, managed sdk, or db driver. Why would someone choose rails over Go or even node JS with express and a few middlewares? (In 2023)

revskill 4y ago
Ruby is OOP. Go is procedural. They're different.
- deleted 4y ago
  [deleted]
- moomoo11 4y ago
  I know. I'm asking why someone would choose rails to build software (a company) than something like Go which is IMO easier to learn and way easier to actually manage.
  - revskill 4y ago
    Ruby provides a complete hackability/customization framework for you to use. So library locked-in is out of place. For example, you use a library which gives you 99% of functionalities you want. Now there's a 1% use case you want different behaviour and you can't directly modify library code. There's an escape hatch here, it's Ruby. It's like "fork" on steroid. Why Rails ? Because it's the "only" web framework in Ruby. No second choice for large scale application.
    - moomoo11 4y ago
      thanks. one more question - from a cost perspective, again I'm not super experienced in rails but enough to debug production issues and ensure stuff works - I recall that for this one rails application, there were like 30 instances of it running on some beefy configurations and it was getting hammered quite a bit. We saw it was only able to manage like 300 req/second. A lot of time was spent rendering the template, like a few ms. I ported that thing to Go and it takes microseconds to render a template. A single Go application running on cheap, shared configuration can handle like 10x the traffic.
      - revskill 4y ago
        The de-factor Ruby/Rails way to application development is DRY. DRY everything if possible, performance is not 1st priority. Less code >> more performant in general use case. TL;DR is: Vendor lock in vs performance lock in. It's hard to not have both at once.
        moomoo11 4y ago
        Ah I see. How do rails-first places handle performance issues, such as this template rendering issue? I'm curious to know what I could have done differently than a re-write.
        revskill 4y ago
        The Rails way to scale is caching. In your case, Rails has something called Fragment caching.
        moomoo11 4y ago
        I see. But that would increase memory usage no? I'll look into it, thanks. And I understand now, the priority is not to chase high performance but have some set of standards that you can adopt without to much bike shedding. I still am not convinced to use rails over Go for my needs, but I am glad you helped me get some more insight.
  - BillSaysThis 4y ago
    Easier for you is hardly easier for everyone.
kayodelycaon 4y ago
Ruby on Rails is designed for making entire websites, not just small services. It has a massive amount of built-in libraries, integration, and a rich plugin ecosystem for that purpose. If you wanted to write a small backend in Ruby, you would typically use Sinatra. So you’re comparing apples to orchards. :)
- moomoo11 4y ago
  Yeah for sure. It comes with a lot of things. But all that comes at a huge cost. You can use Go for making websites (its a general programming language) in fact we use it for exactly that. You can render templates easily.
jacobsenscott 4y ago
I can build a backend service that can scale in 1 day with Rails.
- moomoo11 4y ago
  At what cost?
  - canadiantim 4y ago
    Just their 1st born child
    - moomoo11 4y ago
      A hefty price to pay.
temeritatis 4y ago
> and I found ruby to be really difficult to understand This is my one pain point with JS actually. I've tried getting comfortable for literally years. Sometimes when i look at how stuff is done in JS, it's so incredibly alien to me. I just can't wrap my head around what is happening. I was hoping it would go away with time. Unfortunately it doesn't. Maybe it's the "flexibility" of the language or something.
- moomoo11 4y ago
  imo JS is one of those languages that is hard to master. It has quirks, and there are a lot of ways to do something just like ruby. Whenever I have to use typescript, I use es6 classes with static methods on them. Helps me keep no internal state and everything is organized.
hakunin 4y ago
Advantages of Rails over Go: 1. REPL. Huge. You can be insanely productive with it. If you're integrating with APIs and therefore dealing with complex nested data structs, you can explore them live. You can explore what's possible with any lib, try things before you write any code. You can also debug errors on the fly as soon as they occurred, right in the browser. 2. Your app is organized around entry points by default. Nobody knows the proper architecture up front for a brand new application. Rails gives you rake tasks for CLI, controller actions for web requests, ActiveJob as a convention for background jobs. You can grow your app's inner architecture over time, but you got all the entry points laid out up front, and they rarely ever change. 3. A lot of built-in security risk mitigation. Cross-site request forgery, encryption for cookies and sessions, convenient encrypted configs and secrets, log filtering functionality, escaping everything by default, and many more. Everything is already handled out of the box. 4. Veteran open source packages (gems) with large companies sponsoring maintenance. Decades of dev and polish on most needed gems, still going. 5. Analytics and monitoring out of the box. Completely wired for tracking performance of everything out of the box. No need to manually integrate performance trackers, just one-line install and you have full profiling capabilities of every part of the app, with many popular dashboard services. 6. Error monitoring out of the box. Many ways to notify exceptions via chats, email, and services, with typically zero integration work. 7. Completely thought-out testing environment out of the box, for both integration and isolated testing. Clean slate on every test without manual setup. 8. Lots of Ruby and Rails tools/functions (e.g. Enumerable) for transforming data via functional pipelines (select, reject, tally, map, take_while, etc) out of the box. 9. Ability to write incredibly reusable code to solve a problem for all data types, not just one particular type (this has gotten better in Go with generics).
- moomoo11 4y ago
  Thanks for your deep rely, I appreciate it. A lot of those things make sense to me and I can see why people would prefer to use a framework like that. I guess for me, I already know what a web service needs like adding CORS, setting up csrf protection, cookies, logging, etc. so its trivial to add that to a project whether its Go or Node or whatever. Conceptually I know what is required. As for project structure clean architecture has helped me basically not have that be an issue. I guess its a matter of trading high performance and robust scaling for developer convenience. Like I said to another comment, I probably won't ever use rails but I understand now why people use it. It is probably good for teams that have "fresh" employees like folks out of college or something to quickly be up to speed without having to hand hold too much. Thank you for taking the time to explain your points.
sparker72678 4y ago
Use whatever you want!

revskill 4y ago

Ruby is OOP. Go is procedural. They're different.

deleted 4y ago
[deleted]
moomoo11 4y ago
I know. I'm asking why someone would choose rails to build software (a company) than something like Go which is IMO easier to learn and way easier to actually manage.
- revskill 4y ago
  Ruby provides a complete hackability/customization framework for you to use. So library locked-in is out of place. For example, you use a library which gives you 99% of functionalities you want. Now there's a 1% use case you want different behaviour and you can't directly modify library code. There's an escape hatch here, it's Ruby. It's like "fork" on steroid. Why Rails ? Because it's the "only" web framework in Ruby. No second choice for large scale application.
  - moomoo11 4y ago
    thanks. one more question - from a cost perspective, again I'm not super experienced in rails but enough to debug production issues and ensure stuff works - I recall that for this one rails application, there were like 30 instances of it running on some beefy configurations and it was getting hammered quite a bit. We saw it was only able to manage like 300 req/second. A lot of time was spent rendering the template, like a few ms. I ported that thing to Go and it takes microseconds to render a template. A single Go application running on cheap, shared configuration can handle like 10x the traffic.
    - revskill 4y ago
      The de-factor Ruby/Rails way to application development is DRY. DRY everything if possible, performance is not 1st priority. Less code >> more performant in general use case. TL;DR is: Vendor lock in vs performance lock in. It's hard to not have both at once.
      - moomoo11 4y ago
        Ah I see. How do rails-first places handle performance issues, such as this template rendering issue? I'm curious to know what I could have done differently than a re-write.
        revskill 4y ago
        The Rails way to scale is caching. In your case, Rails has something called Fragment caching.
        moomoo11 4y ago
        I see. But that would increase memory usage no? I'll look into it, thanks. And I understand now, the priority is not to chase high performance but have some set of standards that you can adopt without to much bike shedding. I still am not convinced to use rails over Go for my needs, but I am glad you helped me get some more insight.
- BillSaysThis 4y ago
  Easier for you is hardly easier for everyone.

kayodelycaon 4y ago

Ruby on Rails is designed for making entire websites, not just small services. It has a massive amount of built-in libraries, integration, and a rich plugin ecosystem for that purpose. If you wanted to write a small backend in Ruby, you would typically use Sinatra. So you’re comparing apples to orchards. :)

moomoo11 4y ago
Yeah for sure. It comes with a lot of things. But all that comes at a huge cost. You can use Go for making websites (its a general programming language) in fact we use it for exactly that. You can render templates easily.

jacobsenscott 4y ago

I can build a backend service that can scale in 1 day with Rails.

moomoo11 4y ago
At what cost?
- canadiantim 4y ago
  Just their 1st born child
  - moomoo11 4y ago
    A hefty price to pay.

temeritatis 4y ago

> and I found ruby to be really difficult to understand This is my one pain point with JS actually. I've tried getting comfortable for literally years. Sometimes when i look at how stuff is done in JS, it's so incredibly alien to me. I just can't wrap my head around what is happening. I was hoping it would go away with time. Unfortunately it doesn't. Maybe it's the "flexibility" of the language or something.

moomoo11 4y ago
imo JS is one of those languages that is hard to master. It has quirks, and there are a lot of ways to do something just like ruby. Whenever I have to use typescript, I use es6 classes with static methods on them. Helps me keep no internal state and everything is organized.

hakunin 4y ago

Advantages of Rails over Go: 1. REPL. Huge. You can be insanely productive with it. If you're integrating with APIs and therefore dealing with complex nested data structs, you can explore them live. You can explore what's possible with any lib, try things before you write any code. You can also debug errors on the fly as soon as they occurred, right in the browser. 2. Your app is organized around entry points by default. Nobody knows the proper architecture up front for a brand new application. Rails gives you rake tasks for CLI, controller actions for web requests, ActiveJob as a convention for background jobs. You can grow your app's inner architecture over time, but you got all the entry points laid out up front, and they rarely ever change. 3. A lot of built-in security risk mitigation. Cross-site request forgery, encryption for cookies and sessions, convenient encrypted configs and secrets, log filtering functionality, escaping everything by default, and many more. Everything is already handled out of the box. 4. Veteran open source packages (gems) with large companies sponsoring maintenance. Decades of dev and polish on most needed gems, still going. 5. Analytics and monitoring out of the box. Completely wired for tracking performance of everything out of the box. No need to manually integrate performance trackers, just one-line install and you have full profiling capabilities of every part of the app, with many popular dashboard services. 6. Error monitoring out of the box. Many ways to notify exceptions via chats, email, and services, with typically zero integration work. 7. Completely thought-out testing environment out of the box, for both integration and isolated testing. Clean slate on every test without manual setup. 8. Lots of Ruby and Rails tools/functions (e.g. Enumerable) for transforming data via functional pipelines (select, reject, tally, map, take_while, etc) out of the box. 9. Ability to write incredibly reusable code to solve a problem for all data types, not just one particular type (this has gotten better in Go with generics).

moomoo11 4y ago
Thanks for your deep rely, I appreciate it. A lot of those things make sense to me and I can see why people would prefer to use a framework like that. I guess for me, I already know what a web service needs like adding CORS, setting up csrf protection, cookies, logging, etc. so its trivial to add that to a project whether its Go or Node or whatever. Conceptually I know what is required. As for project structure clean architecture has helped me basically not have that be an issue. I guess its a matter of trading high performance and robust scaling for developer convenience. Like I said to another comment, I probably won't ever use rails but I understand now why people use it. It is probably good for teams that have "fresh" employees like folks out of college or something to quickly be up to speed without having to hand hold too much. Thank you for taking the time to explain your points.

sparker72678 4y ago

Use whatever you want!