4 ms·

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 d

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.
- hakunin 4y ago
  > clean architecture has helped me basically not have that be an issue If you setup your Go app structure like a Rails app structure (basically what clean architecture is), then you have it covered. However, I believe you do have to set it up by hand each time in Go, or write your own generators. > 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. Architecturally speaking, yes and no. Rails does a lot of non-obvious (to new devs) things for very good reasons, that these devs would have to spend quite a bit of time to understand. Try to write Rails without knowing all the wheres and whys, and you will quickly become frustrated. In Go, you can kinda guide new devs along as you build out most things from scratch. Both of these situations require guidance from experts. Syntactically speaking, the opposite is true. Ruby lets you write incredibly expressive code by giving you nearly limitless flexibility. In newbie hands this could become a disaster. It's a common misconception that Rails is beginner-friendly. Its authors have been trying to correct the record on that, by using sharp knife analogies. You have to be very careful with Ruby and Rails, since there aren't nearly the same guardrails as you get with Go.
  - moomoo11 4y ago
    Thanks again, love the info!
- 0xblinq 4y ago
  > so its trivial to add that to a project whether its Go or Node or whatever The thing I think you're missing, is that it's trivial TO YOU to do this, and of course you will understand it end to end and be supe productive. What happens when more people join you to work on that project? What happens when you leave and the next developer needs to understand all of this? What if he doesn't agree in the way you did things? Did you write thorough and detailed documentation for all the decisions you've taken? Can you guarantee it has no security flaws? What if the translations library you've picked has gone unmaintained because the developer that was building it as his side project got something more interesting to do on their weekends? That's the problem. Ending with a custom snafu that once made sense to somebody. Of course this can be made, and of course the next developer can pick it up, refactor, improve, etc. But from a business point of view it just makes literally zero sense. Think about all the time (and thus money) spent integrating things or writing your own infrastructure code and documenting it (because you're documenting it right?) and testing it (because you're testing it right) that could have been spent on actual business code. Compare that with the situation where you've just picked Rails/Laravel/Django/etc. The next developer knows what to expect. Knows how the most important parts work, has tons of documentation and material for learning, and when applied to the position they already knew more or less what to expect. The benefits of a "batteries included" framework is not the framework per se, is the community around it.
fellellor 4y ago
Elixir also fits every one of those points plus OTP. I think even Spring Boot matches those advantages, except for a working REPL. Or is there a way to use JShell on a running app? I don't know. But Spring Boot apps are super quick to get started on. Much faster than Rails in the boiler plate department.

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.

hakunin 4y ago
> clean architecture has helped me basically not have that be an issue If you setup your Go app structure like a Rails app structure (basically what clean architecture is), then you have it covered. However, I believe you do have to set it up by hand each time in Go, or write your own generators. > 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. Architecturally speaking, yes and no. Rails does a lot of non-obvious (to new devs) things for very good reasons, that these devs would have to spend quite a bit of time to understand. Try to write Rails without knowing all the wheres and whys, and you will quickly become frustrated. In Go, you can kinda guide new devs along as you build out most things from scratch. Both of these situations require guidance from experts. Syntactically speaking, the opposite is true. Ruby lets you write incredibly expressive code by giving you nearly limitless flexibility. In newbie hands this could become a disaster. It's a common misconception that Rails is beginner-friendly. Its authors have been trying to correct the record on that, by using sharp knife analogies. You have to be very careful with Ruby and Rails, since there aren't nearly the same guardrails as you get with Go.
- moomoo11 4y ago
  Thanks again, love the info!
0xblinq 4y ago
> so its trivial to add that to a project whether its Go or Node or whatever The thing I think you're missing, is that it's trivial TO YOU to do this, and of course you will understand it end to end and be supe productive. What happens when more people join you to work on that project? What happens when you leave and the next developer needs to understand all of this? What if he doesn't agree in the way you did things? Did you write thorough and detailed documentation for all the decisions you've taken? Can you guarantee it has no security flaws? What if the translations library you've picked has gone unmaintained because the developer that was building it as his side project got something more interesting to do on their weekends? That's the problem. Ending with a custom snafu that once made sense to somebody. Of course this can be made, and of course the next developer can pick it up, refactor, improve, etc. But from a business point of view it just makes literally zero sense. Think about all the time (and thus money) spent integrating things or writing your own infrastructure code and documenting it (because you're documenting it right?) and testing it (because you're testing it right) that could have been spent on actual business code. Compare that with the situation where you've just picked Rails/Laravel/Django/etc. The next developer knows what to expect. Knows how the most important parts work, has tons of documentation and material for learning, and when applied to the position they already knew more or less what to expect. The benefits of a "batteries included" framework is not the framework per se, is the community around it.

fellellor 4y ago

Elixir also fits every one of those points plus OTP. I think even Spring Boot matches those advantages, except for a working REPL. Or is there a way to use JShell on a running app? I don't know. But Spring Boot apps are super quick to get started on. Much faster than Rails in the boiler plate department.