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.
I have heard that many applications, especially those that must manage a lot of requests, would get bogged down with RoR, so JS is usually the speedier choice. In your opinion, what kind of applications are better suited to Ruby on Rails?
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.
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 :)