Ruby on Rails is “vilified” for being an opinionated framework. While one cannot really disagree that it has strong opinions as a framework and that it will make your life a bit of a misery if you attempt to deviate from its well established and recommended patterns, it is hard to argue that a number of other languages and frameworks also do not fall into this category.

Let’s take my most recent, favorite language, Golang. It is a beautiful language that is both strongly typed and extremely fast at runtime. But, does it have strong “opinions” about what to do and what not to do. I think so.

Is Ruby on Rails an opinionated framework? You bet!

Is it the only opinionated framework out there? Definitely not.

Let’s take a look at a simple function written in Golang (this snippet is taken from our Access Control API).

Even if you are not familiar with Go, what is something that immediately stands out? Yes, the multiple return statements. This is something that is generally frowned upon in a number of other languages with the argument being that there should be one (and sometimes, utmost two) return statement(s) in any given function. We see 3 above and there will be many more for more complex functions.

Is this behavior accepted in Golang? Well, it is not just accepted but it is actually expected. This is how you write Go code. If a fair number of languages reject this approach that is idiomatic in Golang, could one also call Go opinionated?

The way I look at it is this.

Be a Roman in Rome.

If you wrote Java code as a Ruby programmer, or Golang code as a TypeScript programmer, you want to ensure Java doesn’t smell of Ruby, and Golang doesn’t smell of TypeScript. We live in a polyglot world where most developers are context switching on a weekly, or sometimes, even a daily, basis (hint: developers at Snowpal) so this can happen time and again (and inadvertently), and it will unless you have due processes in place to catch this before it is pushed to higher environments.

Here’s what I would recommend:

• Look up a few repos to get a sense of a new language (or framework)
• See how other contributors write code
• Understand the rationale behind anything that you disapprove of (at least, initially)
• Write code — first, the way you would have written agnostic to the language, and then, tweak it to suit the style of the language/framework, and the repo it ends up sitting in as well
• Ask for feedback from more experienced programmers in that language
• Improve continuously!