You should try Go first (or at least go through what I wrote) before bringing up Rail’s “convention over configuration” pick-up line. The Go language itself, unlike Ruby, is design to be conventional and very simple. It already comes with most packages needed to build a web app, and if any is lacking one can always use external packages instead of adopting a whole framework.

Since you’ve brought up Rails, here is a few arguments which made me stayed out of the framework and stopped using Ruby altogether:

• Rails uses a lot of magic. This appeals to inexperienced developers but it is also very inflexible. It’s nice for the first first runs to see that things “just work” but the more you work the more you wish it gives back some controls.
• The creator of Rails wrote about convention over configurations. In fact, I’m quite sure he made this mantra sticks. He argued that learning the convention of a framework is worth the time. That may be true to the extend that you become very inflexible to other technologies. I think a framework should introduce very little new conventions and stay close to its language’s way of doing things, so the knowledge is transferable.
• Last but not least, most frameworks (in any languages, especially Go) aren’t a hit like Rails. In fact, Rails even made Ruby well-known. This fact made Rails’ conventions transferable because it has inspired so many other frameworks of many languages. However, most frameworks are poorly maintained, hardly battle-tested, and brittle. There is always a risk of introducing a huge layer of framework abstraction into your project and having to scrap everything when the framework is broken, just plain unscalable, or the author just declare it dead.

Go has seen a lot of web frameworks being developed lately due to its simplicity. You can literally piece packages together in Go and name it a framework. I have been programming in Go for more than a year and haven’t had any success adopting a framework that’s more intuitive than piecing packages myself.