SOME BACKGROUND
Ruby is "a dynamic, open-source programming language with a focus on simplicity and productivity. It has an elegant syntax that i...
For further actions, you may consider blocking this person and/or reporting abuse
It appears to be really popular at least over here in Japan. Not sure about other regions.
Nice post, it really helps to get these kinds of 1:1 comparisons.
Neat post, Christine! I love that you compared the syntax between JS and Ruby. What caught my eye was my that the first programming language that I spent significant time in was JS even though I had written some Basic, PHP, and Python before it.
A few things...
Sorry, I'm a bit of a pendant, but the relationship is inverse -- Rails is, more specifically, a web framework implemented with Ruby. To this day, though, I've always felt "Ruby on Rails" was such a cleverly chosen name that it still rolls off the tongue to this day...
Funnily enough, for as long as I've worked in Ruby, I never knew or ever paid attention to to year/time of Ruby's inception. I only knew about Matz and his motivations.
Might be a slight misinterpretation of "opinionated" -- there's a difference between the developer and their opinions when developing code/library/framework for use by other consumers, but there's also the opinion and interpretation of the consuming developers, like you and I that use it. I'm not sure that I've ever heard people say that Ruby is opinionated, but Rails, the framework most certainly is -- both a blessing and a curse as I've worked on small and currently work on a very very large Rails monolith.
I'll speak more to the users of the Rails framework, like you or I. Typically people, including myself, coming from JS will find Ruby's standard library "bloated". There are a multitude of ways to do things in Ruby, one simple example is: obtain the first element in an array:
How about determining if something is zero?
Glad that you pointed out that JS is a prototypal language compared to Ruby -- the class construct is literally syntactic only to make it more "welcoming" for OO devs
The last thing that I'll point out is that this post seems more of a comparison between JS and Ruby as languages rather than an intro to the Rails framework for JS devs without a JS analog (e.g., SailsJS, HapiJS, etc)
Thanks for your insights and perspective! I'm new to programming and have more experience with JS than Ruby, but I did experiment with it a bit back around 2015 when it was really hot. I'm curious how long you've been working with Ruby. As a new dev, I appreciate a framework that plays by tighter rules since I'm more apt to making mistakes, but I can understand that someone with more experience might find it limiting. Also, I have heard that many applications, especially those that must manage a lot of requests, would get bogged down with RoR, so Node.js is usually the speedier choice. In your opinion, what kind of applications are better suited to Ruby on Rails?
We all start somewhere and welcome aboard! :)
Yeah, Ruby and Rails has certainly lost some of its luster, but continues to make noise -- most recently, DHH (David Heinemeier Hansson), the creator of Rails and his company that's behind Basecamp spent two years on a brand new email service called Hey (hey.com). It is built entirely on with Rails and web-sockets via TurboLinks. It's not "cool" to start new projects today with Rails -- I wouldn't and I haven't, but I'll explain.
Rails comes packed with a lot of overhead -- an ORM (ActiveRecord) and SSR (server-side rendering), so it's unfair to compare Rails against JavaScript or NodeJS, the runtime built atop the V8 engine. However, there are benchmarks and both are plenty fast for most use-cases. When people say that languages are "slow", what they really mean are the runtimes are. To understand what I mean, let me digress a bit... a bit of computer science, if you will...
One must familiarize themselves with "Moore's Law" which generally stated that we got 2X speedup about every two years -- this was during the 90s and early 2000s when they kept packing transistors into CPU dies, so without any change to existing code, programs/applications would just run faster, so developers stopped or never needed to think about parallelism or too many optimizations from a software/code perspective, and these were the eras that saw the likes of "single-threaded" languages on their platforms (virtual machines) rise -- Ruby, Python, JavaScript. But as we've discovered in the last decade, hardware has limitations, there is only so small and so many transistors that can be packed into a CPU die before bad things happen, thus we've found ourselves now with multi-core computing systems. Because we can't double speeds anymore, to eek out performance, the onus is now on software developers and people that write code to do so -- we must optimize the instructions sent to the CPU or CPUs.
Parallelism generally means (multiple and disparate pieces of physical hardware, like CPU cores) -- can execute two things at EXACTLY the same time, like washing a pile of dishes that doesn't fit in a single washer, but having the availability of TWO physical washers at your disposal. Concurrency is a similar idea, but we don't have two washers available -- we have one. The difference is imagine that this single washer washes dishes faster than you can load them, therefore, there are moments that the wash is idly waiting for you to reload it. Now, if that washer can perform other functions during that time, you'd likely let it do so -- that's what concurrency is in relation to a CPU. Concurrent programming is writing software that manages to reduce idle resources, like an idle CPU or memory. In most languages, the default programming model is to write code procedurally -- where we are certain that line two runs after line one. If line one takes a long time to do whatever work it needs to do, it "blocks", for example, it may make an external request to some external API from your machine, but the CPU can do something else, it's like a millennia to a CPU while we await that 50ms HTTP response from the external API. JavaScript wraps an asynchronous programming model around this such that it allows us to have code doing other things as it awaits for that request's response. There are languages and runtimes that give us ways to easily control threads of execution and provide us with concepts/constructs to better write parallel and concurrent code. Ruby, by default on our machines run on MRI (Matz Ruby Interpreter), but the same Ruby code put on a different Ruby virtual machine, like JRuby (Ruby on the Java Virtual Machine) with minor tweaks will completely destroy JS running on Node in throughput.
One of the core contributors of Rails, José Valim, left the Ruby and the Rails community when he sought to bring Rails into a more concurrent-friendly future. He ended up creating a new language some of us know today as Elixir that runs atop the Erlang Virtual Machine. Each virtual machine has many language derivatives (e.g. Java Virtual Machine aka JVM has Java, Kotlin, Scala, Clojure, and many more). Elixir has its own super popular framework, called Phoenix which I've worked in and currently use for a side project. It has a Ruby-like syntax with many neat features borrowed from some of the most popular programming languages, but is HIGHLY concurrent and easy to debug. Writing concurrent code in JavaScript, Ruby, or Python is doable and has always been, but there are many pitfalls that make it a challenge. In JavaScript land, a lot of the top libraries, like ExpressJS was built by a guy by the name of TJ Holowaychuk who also left the Node community in search of better ways to do what he needed -- concurrent programming. Instead of Elixir or one of the popular JVM languages like Clojure or Scala, he decided to roll with Go likely due to popularity and its C-like syntax which he has experience in. JavaScript, too, has a C-style syntax.
So that was a long-winded way to answer your question, but to get directly at: "what kind of applications are better suited to Ruby on Rails?" Probably apps where request/response latency is okay -- because NodeJS and its plethora of libraries surrounding the ability to provide more real-time and low-latency support for real-time features over web sockets has more developers doing it. For people that get into web programming and full-stack web development, I'd argue that Rails conventions are a GREAT starting point to go from. It's conventions, while at times restrictive, does provide a level foundation -- those starting out have little idea what to do and why people do things in a particular way and often just run off with a popular tutorial or blog post and think it's "good enough" while possibly learning a bad practice. At least Rails conventions have been vetted by one of the largest community of developers that have managed to "argue" with each other before ultimately deciding on a given convention.
I really appreciate this incredibly interesting and super thorough reply! I am definitely looking forward to exploring new languages once I get more programming fundamentals down. Thanks so much for taking the time to read and reply and for giving me ideas for new things to learn about.
You're welcome! Enjoy the journey -- it's never ending and keep writing. I find it a good way to collect and solidify thoughts :)
Good stuff!
What about moving opposite directions from RoR to JS, are there some frameworks like Rails in JavaScript (as for 2020)?
Yes, Adonis.js is your closest bet.
I'm learning a little about Express.js right now, and I've also heard of Sails.js, which is designed to directly emulate Rails.
Cool, thanks for the info! It's definitely helpful to see how pros are really writing their code.