Hacker News Reader

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).

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.

> 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.

Thanks again, love the info!

> 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.

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.

> 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.

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.

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. :)

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.

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

At what cost?

Just their 1st born child

A hefty price to pay.

Use whatever you want!

Ruby is OOP.

Go is procedural.

They're different.

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.

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.

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.

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.

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.

Caching. There are multiple layers of caching in rails, including caching of rendered views/partials.

The Rails way to scale is caching. In your case, Rails has something called Fragment caching.

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.

FWIW, my experience on projects with a rails backend is it makes it really easy to fall into performance traps. Active Record is especially bad at encouraging N+1 queries, though the same could be true of many ORMs.

A second issue is that if you come from a background where everything is either explicit or obvious, you are in for a world of hurt. I've seen senior developers try to figure out where a particular method is defined by setting a breakpoint, connecting a REPL, then invoking some special methods to get Ruby to tell them the file and line for the source definition.

It is just a different way of developing, and (personally) I think the reputation is a bit cult-ish.

Easier for you is hardly easier for everyone.