Is Ruby behind a global interpreter lock?

During our inaugural Paubox Engineering Summit yesterday, Ben Ternes (Python engineer) brought up the following question:

"Is Ruby behind a Global Interpreter Lock?"

This post will answer that question.

Global Interpreter Lock (GIL)

As context, I asked Ben Ternes for his definition of a global interpreter lock:

"The job of the global interpreter lock is to create a lock on top of the code to ensure only one thread can execute at a time. It's limited to the actual interpreted code though. You can still run things in parallel like I/O. Its intention is to make the language more thread safe."

Is Ruby behind a Global Interpreter Lock?

I then asked Joshua Montross (Ruby engineer) for his opinion on whether Ruby is behind a global interpreter lock.

He diplomatically answered, "it depends."

Here's more insight from Joshua:

"MRI, the original implementation and first version of Ruby, does have GIL, which enables concurrent execution of Ruby code. However it prevents parallel execution of Ruby code. 

JRuby and Rubinius do not have a GIL and give the ability to have parallel execution of Ruby."

Joshua then embarked on a tangent, which I'll include here for your enjoyment:
"As far as I’m concerned, Ruby is the Toyota of programming languages.  Python is the BMW or Volkswagen and JavaScript is the motorcycle. 

Python is the VW posing as the BMW and it's only better for machine learning IMHO.

Flask versus Sinatra is like the Supra versus the M1.  Same same but different. And the JavaScript creator himself disdains server side js and says he’s sorry for making JavaScript so bad, lol.  He had a deadline.  I met him. He’s hilarious in a nerdy way."

About Paubox

Our mission at Paubox is to become the market leader for HIPAA compliant communication.

We believe adherence to the big ideas at Paubox best enable us to achieve the mission.

Our company culture is reflected by The Paubox Foundations, which are principles and values we care intensely about.