Learning Ruby: 2 Things I Like, 2 Things I Miss From Python

I’ve recently had the fortune to join Workpath as VP of Engineering. Workpath’s backend runs on Ruby on Rails, and while coding won’t be a part of my day-to-day duties, I still need and want to learn the stack.

Since most of my experience is with Python, let me tell you about 2 things I’ve liked in Ruby, and 2 that made me want to start up PyCharm again!

Python vs. Ruby

Python and Ruby are really similar. They’re both interpreted, dynamically typed, general-purpose languages. There are similarities in the syntax, and they even share implementation details:

• You can write extensions in C.
• They’re compiled to bytecode and then both Python and Ruby interpreters are basically a giant fascinating switch-statement in C.
• Their interpreters are both plagued by a global interpreter lock, which limits parallelism … the similarities are eerie!

But Python and Ruby occupy different spaces today: Python’s stronghold is data science, whereas Ruby is inseparable from the Rails framework. However, I posit that this might as well be accidental; the language designs are so similar that I could just as well imagine a world where Python is the web development lingua franca, and Ruby has all the machine learning libraries.

Me at PyCon 2016 with … yeah, a real Python 🐍 #noanimalswereharmed

Now, my thoughts on learning Ruby:

I Like: The Syntax

Ruby’s syntax is concise, and the language is opinionated in areas where Python is not:

• OOP all the way. In Ruby, you just structure your code with classes and methods. In Python, OOP is optional, and it’s a matter of debate if it is actually “Pythonic”. OOP did not get much love from Python language designers, so you’ll have to make do without a private keyword and similar syntactic sugar. And the deeper you look at its type system, the more likely you are to find leaky abstractions shining through from its C interpreter.
• Blocks. Ruby has a reputation of permitting multiple ways of doing the same thing (more on that below). But I find that blocks hold such a privileged position in the language syntax that you’re just nudged to use them in your interface design.

When leading a team around a large codebase, I appreciate a language that encourages a certain design. Fewer technical decisions, more time to focus on creating value for customers!

I Dislike: … Some Of The Syntax

On the other hand, Ruby takes the “concise” part a bit far. There are nearly always different ways of expressing basic syntactic concepts. And Rubyists have a knack for loaded one-liners — take this Rails scope:

scope :registration_on, ->(date) { where created_at: date.beginning_of_day..date.end_of_day }

Sure, if you just read the English words from left to right, you grasp what this does. But to my beginner’s eyes, this is much more readable with a few more parentheses.

And it seems that Ruby is determined to keep adding syntax. Ruby 3.0 comes with rightward assignment, which makes these gems (heh) possible:

I Miss: Generators

They say a programming language is worth learning if it changes the way you think.

From Python, the thing that’ll stick with me is generators. Especially for processing data, it just becomes so natural (and memory-efficient) to express generation or transformation of data through generators.

In fact, I wrote a Python script to generate different Ruby representations of the Rails scope I mentioned as an example above. I would struggle to crank out this code as quickly in Ruby or any other language:

Write a comment if you want to see the output of this thing.

Generators gradually evolved to become the basis of async coroutines in modern Python versions. And Ruby 3.0 comes with Fibers, a very similar concept, which means maybe I won’t have to miss generators for long.

I Like: The Ecosystem

An open-source language lives and dies with its community and ecosystem. And Ruby seems at a disadvantage here, since it’s a well known language, but rather niche in the workplace, and often absent from top 10 rankings.

However, my limited experience has been that tooling and libraries are very mature. Ruby seems to be focused around a few key projects, but these are rock solid. If you want to write a web application in Python, or write a BDD test suite etc. etc. you’ll almost always be faced with a myriad of choices.

There’s another upside to this focus around a few key open source libraries: While Ruby developers are still few and far between, when you do get to interview one, they tend to have experience in at least 80% of the tech that we use.

More To Come!

There’s much more to talk about — the heavy presence of Rails in the Ruby language, the emergence of type hinting in Ruby 3.0, and then finally, how we put all this together to deliver great products here at Workpath. So stay tuned for more!

→ Learn more about Workpath, or see our open Rails software engineer positions in 🍻 Munich, 🇩🇪 Berlin and 🇪🇸 Madrid