[masukomi]

yeah, you'll see this argument a lot.

If someone feels like re-implementing all the wonderful conveniences of rails in Go, more power to them. However, that's a MASSIVE amount of work that you'll be doing _instead_ of actually making the webapp.

Go is great, but it's built in HTTP support isn't even _remotely_ equivalent to the many years of accreted utility in Rails.

To put it another way, it's a false equivalence. No-one should EVER say "learn go" instead of rails. Now, if they said "lean Buffalo" ( https://gobuffalo.io/ a Railsish framework in go) instead of Rails you could have a very reasonable discussion.

[0des]

This is fairly inaccurate. The stdlib accomplishes a lot and unless you absolutely must have a wizard in your CLI to generate routes then you really aren't missing much at all. Having designed products in both, I'd prefer Go these days because unless I'm making todo apps there is a lot of decision and freedom taken out of my hands by using rails.

All of this disregards the speed advantage of go. There is no comparison between the two.

[ryanbrunner]

Generators, while nice, are nowhere near the most important thing that Rails brings that are often overlooked, even by "full featured" frameworks in other ecosystems.

- Migrations are well-implemented, and I've definitely wasted many cycles at other startups dealing with hand-rolled migration tools that are nowhere near Rails.

- The ORM (ActiveRecord), while very opinionated, is pretty full featured and suitable for 95% of use cases (and makes it fairly easy to drop out of it if needed)

- There's a host of security features that are taken care of you by Rails out of the box, including CSRF protection, session security and password hashing with a sane strategy and good algorithms (I'm sure there's others I'm missing)

- Websocket functionality comes out of the box with newer versions of Rails

- Asset handling, including minifying and digesting assets is included.

- Directory structure is set up for you (seems minor, but it's a huge productivity boost when joining a new team knowing where everything should be).

- A standard approach to background queueing, built in a way that it's extensible for different queue / worker backends (i.e. your jobs are cross-compatible with different background libraries and backend servers - I can come onto a Rails job that stores background jobs in Postgres, SQS, Redis, or anything else and how the jobs work is consistent).

Regarding speed, I'm certainly not going to argue that Ruby is faster than Go, but at least for the problems that I tend to work on, raw language execution performance is never really the bottleneck. It's cheap to throw money at, and 99% of the time when I look at poorly performing actions the culprit is the database or an external service.

[tomca32]

There are a lot of things that rails gives you out of the box automatically which require either a lot of additional code in Go’s ecosystem.

CSP, csurf tokens, param parsing with array and hash map params, strong params, automatic response codes (201 for created for example), etags, … just from the top of my head. I’m sure I could find dozens more if I start looking.

All of those are possible in every stack of course but rails already gave you all of that from the time you typed “rails new”