Ruby is a flexible, high level, object oriented language that prioritizes ease of use for programmers, but how does it compare to tried-and-true JavaScript?
PRO - Easy to Learn and Use
Ruby was designed by Yukihiro Matsumoto with the goal of being simple, easy to read, and to allow for multiple approaches to achieve a programming goal. The language is known for being easy to interpret, with code being generally intuitive to grasp based simply on the syntax and plain English word choice for various commands, and often less verbose than other languages. To illustrate this, here is a snippet of JavaScript code which creates and then calls a function that will will greet the name passed to it as an argument, followed by a snippet of Ruby code which does the same thing:
JavaScript:
function greet(name){
const greeting = "Hello ${name}";
console.log(greeting);
};
greet("Marcus");
Ruby:
def greet(name)
greeting = "Hello #{name}!"
puts greeting
end
greet("Marcus")
As you can see, the Ruby code has a more natural feel to it, eliminating a lot of the more technical characters used by JavaScript, such as the curly braces and variable declaration keyword "const", and uses the keyword "end" to indicate where the function code stops. This makes it easier for a reader to parse, particularly with larger code blocks.
Of note, Ruby also allows more variation in syntax, allowing the programmer to choose what style they prefer. For instance, the function call in the code snippet above could have instead been written like this:
greet "Marcus"
CON - Sharing Code Between Programmers can be Problematic
Because of the design goal of allowing many different approaches to a coding problem, and especially the syntactic variations the language allows for, two programmers with different coding styles may find it difficult to make use of each others' code, at least by copying. This can make collaboration between multiple programmers on a single project a little more difficult than with other more syntactically strict languages, though it is worth it to note that Ruby does contain functionality to create plug-and-play libraries of programs, called "gems", which can easily be added to other Ruby programs to be made use of, which mitigates this downside to some extent.
PRO - Flexibility
While Ruby is most commonly used for GUIs and web apps/development, it is a highly adaptable language that can be used in a variety of situations. Since just about everything in Ruby is an object, even its base components can be altered or removed as needed to customize it to whatever end the programmer desires. This allows programmers to customize even the basic commands used in the program.
For example, take this code snippet pulled from the about section of the Ruby programming language webpage which adds a "plus" method that can be used in place of the addition operation:
class Numeric
def plus(x)
self.+(x)
end
end
y = 5.plus 6
CON - Programs Run Slowly Compared to Other Languages
Making just about everything an object does have its price: Ruby programs run notably slower than other coding languages, about 50-200% slower than JavaScript programs in fact. That may sound like a huge problem, but given that most code runs in almost imperceptible amounts of time regardless of language, this really only comes into play with code that requires extremely large numbers of operations to complete. Thus, while it is definitely an issue worthy of consideration, it's also true that it is not even a noticeable problem most of the time.
PRO - Robust and Welcoming Developer Community
Ruby is an open source language, a fact which draws many developers to it and generally encourages sharing and collaboration in its use. This has resulted in a large, friendly community which is very welcoming to those new to the language, be they beginner programmers or experienced ones looking to add a new language to their repertoire; the community continues to grow even to this day. This gives a lifeline to those still learning the language and those who have been using it for years alike, which is definitely a feather in Ruby's cap. A supportive community not only means updates, improvements, and sharing of tips and tricks, but also a place to go to for help or advice when a programmer's code isn't functioning properly despite their debugging attempts. And speaking of debugging...
CON - Debugging can be Difficult
Yes, even with help from the community debugging Ruby can be more difficult than with other languages. This is due in large part to some of the advantages mentioned earlier, namely the highly variable/adaptable syntax and the fact that Ruby is a simple to look at but fairly complex under the hood high level object oriented language. The variety in approach when using this language also means a wide variety of errors, with different users doing the same tasks potentially encountering very different hurdles to face. It is worth it to note that Ruby does have exception handling features to aid in error management, though the underlying complexity of the language means that those may not be enough in every situation.
Conclusion
The advantages that Ruby was designed to include are often double edged swords, but given how easy the language is to learn coupled with how adaptable it is, I would argue that it makes both a good first language for a beginner to learn and and a good "back pocket" language for any experienced programmer to pick up. While other programming languages like JavaScript might outclass it in certain areas, the fact is that Ruby is still a widely used language across a variety of coding professions, so learning it will certainly expand your portfolio without consuming too much of your time.
Sources:
https://www.ruby-lang.org/en/about/
https://blog.boot.dev/javascript/ruby-vs-javascript-which-language-should-you-learn-first/
https://careerkarma.com/blog/ruby-vs-javascript/
https://careerkarma.com/blog/what-is-ruby-used-for/
https://activebridge.org/blog/what-do-experienced-developers-think-of-ruby-the-ultimate-ruby-guide
https://www.youtube.com/watch?v=UYm0kfnRTJk
https://www.youtube.com/watch?v=vFEPkXybAlo
Top comments (3)
TL;DR Please move on, nothing to gain from this article.
I don't usually read "should you learn xy" articles, but the fancy infographic of this one caught my eye, particularly as it's more about visual balance than content. The article itself sounds like ChatGPT wrote it, not a human who's (according to the profile) "mostly learning Javascript, some experience with C++". Other than watching some videos and reading an article, what exactly is your first hand experience here? In a court of law, that's where the attorney jumps up and yells "hearsay, your honor!" There's not much to take from this article, even less so for a newbie.
If anything, you should retain that shitty and undocumented third-party code (libs) exist in any programming language, no surprise there. The article blames the language, but these are just the classic warning signs not to use that particular lib or code. Blindly clicking together libs is bad in any language.
And one last word on debugging: I have contributed fixes to many decent Ruby gems (aka: libs) and find it ridiculously easy to debug and navigate foreign code. The more experienced I am, the easier it gets, that again is true for almost anything in life. To state this as a downside for Ruby is just plain wrong, particularly in comparison to JavaScript which has quite similar debugging workflows – at least once you've come to terms with the clunky syntax of JavaScript.
I don't have any firsthand experience coding in Ruby, this blog post was based solely on the research I did and the pros and cons of the language as explained by the sources I used (which are all linked at the bottom of the post).
It was an assignment for a coding bootcamp I'm going through at the moment: we needed to choose topics we had no experience in to research and post about. I chose Ruby because the open source nature of it and the design focus of making things easier on the programmer intrigued me. The pros and cons were all things I'd seen at least one of my sources mention, most of them were covered by several. So, for instance, the comments on debugging were related to statements like this one from this source:
If you could suggest any other sources on the broad pros and cons of the language for me to look at I'd honestly love to see them. I am still learning about the language, and while I'm not at a point where I could pursue learning another (since I'm still in the process of getting JavaScript down), Ruby is a language I'm strongly considering picking up as a secondary one.
What I find problematic about your article is its definite tone which suggests you do have first hand experience:
This is not what your source says, it's your assumption which may be true for trivial things like a puzzle, but programming languages are not that trivial. There are many ways to write hard to debug code in both Ruby and JS. And mere syntax errors à la "missing a semicolon" are no biggies in neither.
Drilling a little deeper on this particular source, Ethan Scully, he doesn't seem to have any significant experience in neither Ruby nor JS. His bio on the site you mentioned as source in your comment:
From there, you can also move on to his LinkedIn and GitHub profiles. No indication of any Ruby or JS work. It's possible of course he doesn't make this work public, but the people worth quoting always do some work on open-source projects aside, he's not.
Making your sources transparent is good, but you should also make sure these sources are trustworthy.
I'm sorry if I sound like your teacher, by no means do I want to discourage you – all the contrary: Dive in, make your hands dirty and play around with as many programming languages as you can. It only takes two or three days to get a feeling. Until then, you might want to prelude such articles with some background on the author, very much like you did in your comment:
There's nothing wrong about not being experienced (yet), but you should tell your readers so – otherwise you sound just like ChatGPT who sells a statistically assembled soup of tidbits as "the truth". Or in very short: eloquence ≠ competence.