Comment by quesera

This does not match my experience at all, and I think your "near zero" claim is silly.

> difficult to deploy from source

I won't argue with you here. There are a lot of moving pieces in a Rails deployment. This isn't different from most web app frameworks, but it is difficult.

That said, I've never worked on a Rails app where deployment was any more difficult than a variation on `bin/deploy v123 production`, because I wrote that script and it works 100% of the time.

> and written in Ruby so the chance of being able to actually modify it for some feature you want is near zero

But this is still silly. You just don't know Rails or Ruby well, and don't want to learn them. Fine, but if you hadn't already made that decision, you would find the solution simple enough. No judgement intended -- different framework/language paradigms fit different people differently.

Rails has great IDE support also. Static typing can be a useful language feature, but a lack of same has not ever, in my experience, made it more difficult to understand real-world code.

There is a lot to love about Go too, don't get me wrong. But I would guess that the number of random developers who could drop in and be immediately productive in a Ruby/Rails app, vs a Go webapp, is basically equivalent. The overlap of projects where both would be highly appropriate choices is a bit thin.

[I hire into Ruby/Rails jobs regularly. I often hire senior developers with no Ruby/Rails background, but I do not hire people into these positions who are not open to learning. It takes a senior dev (from the C/Algol family) one day to learn Ruby, and (from a web dev background) a week or less to learn Rails. I have never seen a failure.

I also hire into Go jobs almost as frequently. The hiring criteria is a bit different (less emphasis on web awareness), but I do find it easier to teach Go to a Ruby dev, than Ruby to a Go dev. Make of that what you will.]