All of us have a mother tongue, a mother language. There’s something similar for engineers, a “mother programming language”. While not a proper “mother language”, it is still essential as it forms a developer’s tech thinking, and for many it’s more than just a habit. I’d describe it as a technology that a developer enjoys the most or spent the most time working with.

For me personally it’s .NET, but back in 2018 I decided to try Ruby on Rails. I had multiple reasons to choose this language specifically. One of them was that at the time I looked into pretty much every nook and cranny that C# has, and was wishing to try something new, which would broaden my technological thinking. Another reason was that life gave me an opportunity and placed me in the right place at the right time. I had a chance to work with my friends in Mixbook, but their engineering standards were higher than at my previous job.

So here I was on a new adventure with a new tech stack in front of me. The whole experience was similar to traveling to a different part of the world. The Ruby/Rails stack felt like the Australia of technologies to me (even though I’ve never been to that continent). On this adventure I met things I was already familiar with (e.g. classes) and things that were totally new to me — like debugging techniques using the command line. Going through the technical weeds, I approached everything with the mindset that I’m on a journey: look, a kangaroo, what a curious creature; look, echidnas, hmm…interesting, and I guess, debatable.

I have to mention that I don’t regret the decision to try a new technology and I can see how it broadened my horizons, and made me stronger and more diverse from a technical point of view.

But I also can’t say that I enjoyed everything about Ruby/Rails. There are things that I enjoyed more about C# and .NET. But, there certainly are things that can be achieved better with Ruby/Rails. Having said that, here are the top 5 things I like which can be done better in the Ruby/Rails community, compared to my former experience with the C# stack:

1.The instrumentation for writing unit-tests/specs. The Ruby way of writing tests is one of the most laconic things out there with almost 0 boilerplate code. Two of the most popular tools out there are Rspec and Minitest, with the former one being my personal favorite. Rspec is a DSL(Domain-specific language) written in Ruby to test Ruby code. In short, Rspec benefits are:

• Possibility to test more with less code by heavily exploiting language + framework features. The possibilities to DRY the spec code are limitless. What I can achieve with X lines of code/Y words in Rspec I probably need 1.5–2x lines of code/words in C#/Java.
• A strong community offering guidance on how to best structure and organize the tests. It includes Best Guide Practices, supporting tools(e.g. — scaffolding tool like factory bot), excellent documentation.

2. Expressiveness/“Syntactic sugar” fun. The author of the Ruby language is Yukihiro Matsumoto(Mats). One of his famous quotes is:

I believe that the purpose of life is, at least in part, to be happy. Based on this belief, Ruby is designed to make programming not only easy but also fun. It allows you to concentrate on the creative side of programming, with less stress.

Lots of concepts in Ruby have been designed with fun in mind. Let me give a few examples of the Ruby fun:

• DSL In Rails. In different places including routing, migrations, rspec. Ruby almost invites you to create a DSL. The goal of it is increased readability, sometimes you can think you read a text in English rather than code.
• Code constructs like 3.days.ago
• !/? in method names tells a lot
• array = [ “apple”, “orange”, “pear”]

array.map(&:capitalize)

which is exact equivalent of

array = [ “apple”, “orange”, “pear”]

array.map{|item| item.capitalize}

• Memorization. I can talk a lot about it but this article describes it in more details than the scope of this blog post can afford.

3. Community. Rails is an open-source framework with a large army of maintainers with an obvious care for the future of the thing they are contributing to. I would like to emphasize a few things which I like about the community:

a. Maturity. At the moment of writing this article, Rails is 17 years old and still actively developing. Obviously as the tool matured, it has been adjusted to the needs of engineers around the world, all the small issues have been addressed and the tool became more refined over time (e.g. — dependency management(bundler + gemfile), Rake — comfortable standard Ruby syntax makefiles with laconic syntax, etc.). Despite being that old it is still actively used, with each new release exploring the use of new technologies and adopting new standards on the Internet.

b. Still well maintained. Every year the community releases a new minor/major version of Rails, taking into account the trends. The large variety of 3rd party gems goes hand in hand with the community and releases. New versions of software addressing usability issues and security vulnerabilities, enriching the feature set.

c. A high level of pragmatism. Being pragmatic is in the DNA of the Rails community. There is a high urge to not introduce artificial/accidental complexity and do the larger scope changes only in the case of the strong argument for it. That might sound “corny”, but the truth is that Rails prefers minimal options for developers trying to abstract away complexity and exclude code entropy from them.

4. Excellent linter. You might be thinking that I went crazy and I am in love with what — a linter? Really? Does it sound like a good reason to try out a platform/framework?

The reality is that Ruby is different from C-like languages and assumes a certain mindset. The linter does an excellent job at enforcing the Ruby-style code and is a mature 10-year old tool itself. It both guides the engineer in:

a. More high level decisions — how to better split the code into classes/methods by controlling their length/ABC size

b. More low/code line level decisions — with suggestions like to use unless instead of an inverted if or prefer or checking the right namings. If you are new to rspec, there is a standalone extension to write them better.

I might not have persuaded you, but believe me: this linting tool is great (and like the unit-tests) and can help you in sharpening the design of your system and enhancing the readability of each line of code your team produces.

5. Being opinionated. It’s the gift & the curse of the Rails community. The curse is that going against the community tide is the best recipe for creating problems for yourself in the future with Rails application. On the bright side is that if you want to implement something (validate a model or protect against a hack attack), the Rails community perhaps has a very clear recommendation on how to achieve it.

Of course there is flexibility, but it is much more opinionated here. For example, Rails comes with ActiveRecord as the recommended built-in ORM. And 90% of the apps can do fine supporting it and you better use it as it was designed. If the performance of the database is a bottleneck and you want to work closer to the database and minimize the level of abstraction, sequel-rails can be the way to go.

Another example can be increasing the security of the data sent to the server. Rails recommends using strong params. If you go against the tide, you might find out later that you are in the race against time.