We had some problems to solve. The technical management decided we should use Ruby. Now we have bigger ones. Let’s go into it…

Ruby is known as the silver bullet for every issue: a strongly and dynamically typed language, deeply object-oriented (everything is an object), general purpose, implicit resources management approach, metaprogramming, schemaless modelling, easy deployment, lots of ready-to-use tools, cool native resources like symbols, hashes (“hash maps” for javists, “dictionaries” for everyone else), and nested modules (like namespaces), developers around every corner. Above all, Ruby On Rails.

It has a self-centered community that believes anything can be solved by Ruby better than by any other – if you think about it, not much different from Java, PHP, or Python communities.

’Til here everything sounds good, but that’s because we’re only looking at the propaganda, not the real world.

Metaprogramming everywhere

The first cool feature, that’s not so cool up close, is the unblessed metaprogramming. It’s the most non-straight approach you can find and, like any other indirection, everything becomes cloudy.

Typically you do not write the code: you write a code that writes the target one implicitly. So you never quite see the final code, that one which indeed runs.

This is the debuggers’ hell. Just try to find a logical bug’s origin, an inconsistency, in a code that doesn’t really exist.

It leads us to the next trouble: monkey patching.

Monkey patching

Because of metaprogramming approach, Ruby simply loves monkey patching. Every gem, every library injects codes into your code.

So new unexpected methods and classes just fall from another dimension. Your own coded resources can be rewritten by some other anytime. Looking at the code, you can’t find what it does, you must know all resources you’re using by heart. The documentation becomes more relevant than the code you write – and the doc (almost) always lies.

Therefore, the best Ruby developers are those who memorise the main resources of each gem, not the one who understands programming and logic.

Self-centeredness

Like mainly the Java and PHP communities – and after both – the Ruby community is self-centered. All kinds of falsehoods about other programming languages and patterns are spread.

“Ruby is the best solution for X” (where X is actually anything), “no other language can do what Ruby does,” “metaprogramming is the best practice,” and some suspicious design patterns like implicitness and the above-mentioned monkey patching.

After self-centeredness, arise weak and dumb integrations.

JRuby

You can think “what great idea running Ruby on the JVM!” But the reality is poorer.

JRuby comes to solve a very specific issue: running Ruby On Rails applications on the JVM, and it alone. So all JRuby does is enable the JVM to perform Ruby (On Rails) codes.

It supplies only a way to run and/or compile executable Ruby scripts. You simply cannot compile a Ruby library to bytecode and access it on a Java (or other language over the JVM) context.

Jython, Scala, Kotlin, Groovy – virtually every language over the JVM supports foreign integration to any other, but JRuby.

Just like Ruby itself, JRuby promotes the platform shutting, afraid of developers’ escape.

And it makes a lot of sense: if a bright programmer actually gets in touch to another development platform, in deep touch, he or she can see how far behind Ruby is, and then he or she will be lost. Finally only the less perceptive programmers will remain, defending the indefensible. They better keep people unaware.

Also in Medium.