[BringTheTanks]

Odd. RoR and Go address entirely different app domains.

The only thing that connects them is that RoR was trendy yesterday, and Go is trendy today.

If this is the rationale for replacement, the author will be writing plenty of "replacing" articles in the years forward.

[jfroma]

Yes, and I remember how a lot of .Net people moved from .Net to ruby because of the type system. Now you are going to move to an inferior type system that doesn't even support generics and with worse type inference.

[iends]

What do you see the app domains of Rails and Go as?

[thibaut_barrere]

I've worked (as a freelancer) on a number of apps recently using Rails for the "front back-end" and either Erlang or Go for the "back back-end" and it's been working great.

Rails works great for things like authentication, creating a nice and maintainable UI, handling billing code, sending emails, managing the database schema, and all the web related stuff.

Erlang and Go work nicely for all the "heavy work", think sending tens of million of push notifications quickly, crunching data etc.

They can communicate using a shared, Rails-maintained database, and things like Redis to trigger updates or orders.

You can even do Erlang-backend processing of Sidekiq payloads, pushed from the Rails side etc.

All in all: use each tool for its own strengths.

[aikah]

> Rails works great for things like authentication, creating a nice and maintainable UI, handling billing code, sending emails, managing the database schema, and all the web related stuff.

Nothing that Go cannot do. The only difference between Go/web and Rails is the maturity of the libraries.

Of course Go libs are way less mature for various "business tasks".

[thibaut_barrere]

You can do that in Go, yet like pointed out in [1], it tends to take more effort (well, this has been my experience at least).

But well: do what works for you, really :-) I'm not commenting to persuade you, I'm just sharing one data point.

[1] http://blog.gopheracademy.com/advent-2014/atlas/

[aikah]

Did you write Gopher academy (fellow french?) ?

[thibaut_barrere]

No I didn't! Yet I felt exactly the same. Sorry if my message was confusing :-) (I'm french indeed).

[PopsiclePete]

Everything can be done in Go, sure, but at least the current direction of Go is to provide small reusable libraries, not frameworks. And there's a huge difference between the two.

I don't like frameworks like RoR or ASP.NET MVC. Too much magic. Things break in weird places. They're slow. But they give programmers some kind of safe, happy sandbox that hides the "scary" web.

It's a whole different philosophy I think. Almost every week I see a new rubyists on golang-nuts looking for the "RoR equivalent" in Go-land.

[matthewmacleod]

It's also 'nothing that C cannot do', but we still don't generally find it being used for such!

I've tried writing web front-ends in Go. It's a fiddly pain in the arse, and the benefits aren't really obvious. If it works for your situation then use it, but IME they're targeted at different problem domains.

[BringTheTanks]

With RoR it's pretty much in the description. Monolithic web apps with relatively standard and simple domain logic (i.e. CRUD). Lots of presentation code (HTML templates, handling of static assets and what not).

Go is for writing small, focused, paralellizable and likely distributed services. If I wanted to crunch data, I'd try Go.

I'd expect, say, a RoR app to connect to a Go service for some of its heavier domain logic. I'd neither write a RoR-type app in Go, nor a Go-type service in RoR.