I know what you're thinking but I want to start by saying that I love Ruby. Ruby is the language that made programming fun again for me after losing interest for a number of years. Ruby revitalised my career and allowed me to grow into the senior software engineer that I am today. Ruby is a lovely language. I just want you to stop using it.
For me Ruby came along in 2008 when I was working as a systems administrator at a local computer science department. I had written code in a bunch of languages before, and even enjoyed some of it but I was never able to feel completely productive or in tune with the language the way I felt when I started using Ruby. I was working with another team member to build a system to reimage lab computers using a combination of Rails, PXELINUX and BitTorrent. It was truly mad science. Also it worked really well - but that's a story for another day.
There was a bunch of reasons I stuck with Ruby after that first exposure and eventually transitioned into being a professional Rubyist. Below are the reasons I'm moving on and I think you should too.
Rails - the best tool for the job
If you wanted to make web applications in 2008 then Rails was simply the way to go. Sure there were other choices, but there were not other choices which were mainstream, had a reasonable talent pool available and were economic.
Rails drove the post-GFC startup economy. Not just because of the hipsters but also because it was the only framework at the time that allowed you to be so productive so quickly and to pivot your app easily when your hipster CEO decided to switch your dog food subscription website into an organic hemp running shoe e-commerce site.
Back then "the job" was a fairly constrained problem set: Take something from the database, squeeze it between brackets and serve it to the user. Then take some user input and stuff it back in the database.
These days the domain of a web app has expanded to include websockets, single page apps, APIs with their own query languages, web assembly and a bunch of tech that falls under the designation of "cloud". Web apps today look and behave completely differently to their 2008 counterparts - unless you look at a Rails app. Rails apps are still shuffling data back and forwards between databases and brackets - only these days there are more kinds of brackets.
Semantics - there can be only run
Ruby's DNA comes from a mixture of Perl and Smalltalk. Like Smalltalk Ruby features a dynamically typed classical object-oriented paradigm.
Ruby is a scripting language, meaning that the Ruby interpreter reads in source code, parses it and immediately starts evaluating it. There is no formal compile step. Runtime code defines (and redefines) constants, classes, methods and everything else. Runtime code can write more runtime code or modify or delete existing runtime code. In some cases the same class can have different behaviour depending on what lexical scope you're in. Ruby's semantics are so flexible that it was no wonder that Rails came along and told everyone their code had to fit into one of three folders.
When designing systems in Ruby you'll hear a lot about duck typing - the idea that you don't care what the type of an object is as long as it responds to the method you need. This is a way of having protocols without having to define them before hand, this makes sense because there is no "before hand", there's only runtime. In conventional cases it works quite well because most Ruby devs know that if you implement each then you can become an enumerable.
What this tends to mean in practice is that dynamic typing leads to subtle bugs because the wrong object is in the wrong place at the wrong time. The most common occurrence of this the infamous NoMethodError on NilClass. What this is saying is that you tried to call a method that doesn't exist on nil but what it really means is that somewhere below you in the stack a method returned nil instead of the thing you were expecting. It doesn't tell you where your bug is, just where the effects of it were finally intolerable to the system.
Because Ruby's semantics defy almost any kind of static analysis where a user of another language could add a type constraint or at least pattern match to avoid this situation the Ruby programmer is left with only one option: write a truly heroic number of unit tests in an effort to formalise what data is allowed to flow in and out of methods and objects and that it doesn't explode when the wrong input is given.
One other side effect of duck typing is the common use if backhanded type checking in the form of object && object.method to verify that the collaborating object is at least truthy before calling a method on it. This is so common that Ruby 2.3 added the &. safe navigation operator to turn this design problem into a virtue.
Performance - there can be only one
Let's get this out there first of all. Ruby is slow. Conventional wisdom is that Ruby is "fast enough" and that you can always throw more hardware at a problem. This is true to a certain extent, but most machines are multi-core these days and...
I don't consider myself as the threading guy, so I don't think I can make the right decision about the Actor library or the threading library.
Matz - creator of Ruby
...Ruby is also no good at concurrency. MRI has a global interpreter lock, which means that only one YARV instruction can be run at a time. There's a bunch of places where this can be worked around - like sleeping threads waiting for IO but fundamentally, if you want to do more than one thing at a time you need to run multiple interpreter processes.
Lastly, Ruby tends to use a lot of memory and it doesn't like giving it back to the operating system. There are ways to mitigate these problems to a certain extent, but most Rubyists are not aware of them or are simply used to the situation.
A lot of work has been put in by the Ruby core team over the last few years and I'll be the first to admit that Ruby 2.5 is much much faster than it used to be. Many would argue that it's fast enough. I would not.
Resilience - exceptional situations
As described above, even when running with multiple threads Ruby essentially runs a single interpreter with no built-in fault tolerance primitives so unhandled exceptions will take down the entire VM. There have been legendary efforts by the community at writing actor systems but ultimately those teams have given up and moved to languages who give them the tools they need to build reliability into their products (example Celluloid).
Tooling - from 0X to DX
The Ruby (and especially Rails) community lead the way in terms of good tooling to help developers achieve results quickly. Tools like Rake, Bundler, RSpec and the Rails command line really did blaze a trail for developer experience, however other languages have caught up and even overtaken Ruby in their tooling game. Rust's cargo, Elixir's mix and Scala's sbt all combine these tools into a single command and go the extra step of tightly integrating them directly into the language. And it's not just languages that have upped their tool game but also client side frameworks, DevOps systems and cloud providers.
Packages - to infinity and beyond
Ruby is blessed with a very large number of packages (or gems) which provide pretty much any kind of functionality you can think of. Not quite as many as that other language but I'd argue that on average they are of a much higher quality. Need an out-of-the-box authentication system? There's a gem for that. Need a massively overblown and architecturally questionable state machine that is weirdly tied to your database? There's a gem for that too.
Before Rubygems there really was only CPAN but no one needs to be reminded of that. Ruby's model of easily consumable and integrated packages paved the way and has been adopted by many many other languages, eg: crates, hex, CocoaPods and elm/packages.
So what should I use Ruby for in 2018?
For me, irb is still my go to tool to quickly work something out and I'll still write little Ruby scripts to orchestrate little one-off jobs like moving files around or sucking down an API responses.
When we talk about Ruby it's hard to ignore Rails, so I guess the question is "what should I use Rails for in 2018"? If you have an app that meets the following criteria then I expect that Rails will still be a good match for you:
- is almost entirely database driven,
- renders pages on the server or generates JSON,
- can be mostly assembled out of existing gems,
- doesn't have complicated business logic,
- doesn't need to be fast,
- doesn't need to serve many people at once,
- won't ever change.
I'd still argue that you have better options though.
Top comments (72)
So...respectfully, I am going to go in on this.
I really feel like we need to slow our roll on shit-talking Ruby on Rails. Very few of us are ever going to have to worry about scale on a level where Ruby‘s raw performance metrics are going to be that impactful. Plus, let us not forget one of the main tenets of Ruby: programmer happiness.
I did not go to school for CS, so I don’t have the acquired taste for FP that a lot of folks have, I guess. I’m a digital carpenter; I want the code to be clear, easy to understand and flexible. Ruby is one of the best for that.
If you really think that you’re going to be managing 1M connections on one node a la Elixir (WhatsApp), go for it. That said, let’s keep the click-baity holier-than-thou hot takes to a minimum.
You don't think there's anything holier-than-thou about idea that Ruby is one of the happiest languages to code in? Is the hardly subtle implication that engineers who care about performance can't possibly care about readability really going in on this respectfully?
What are the metrics for programmer happiness? How did you collect your data? What's your sample size? How can you even begin to honestly substantiate that claim beyond "I like it and everyone who insists on using it despite it's demonstrable problems likes it."
Everyone who insists on writing C# likes it, and people who insist on writing Elm are convinced that functional programming is obviously the most pleasant. Some people still swear by Ada.
Ruby is one language of many that allows you to write readable code.
And while there are languages that make it hard to write readable code; there are zero languages that make it hard to write unreadable code. Ruby doesn't even make writing unreadable code the least bit difficult.
I once was stuck on a rails error for 2 hours because I typed
validateinstead ofvalidates. Any compiled language's editor would have caught that as soon as I typed it. Ruby was able to spin up the whole app and run indefinitely without ever feeling the need to say "BTW, I don't know what that method is."Is "Please Stop using Ruby" a click-bait headline? For sure.
Are some of his criticisms of the language valid? Absolutely.
So yeah, this should have definitely been titled something like "Considerations to take into account before starting your next web project as Ruby on Rails"
I never said "Ruby is one of the happiest languages to code in". I said it's primary focus is "developer happiness', which is direct from Matz.
I think the fact that RoR is the de facto on-ramp for most devs coming out of boot camps says a lot for its accessibility. Is Ruby the happiest language? Highly unlikely! People are made happy for all sorts of reasons.
My whole point was addressing the obviously craven title and the nasty habit people have for shitting on other peoples' tools. Write your next app in mindf*ck for all I care. If that's what makes you happy and it does the job, great! The idea, however, well all need these super-concurrent, ultra-fast, functionally-programmed, EVERYTHING-less apps is silly. Very little of what most of us do is a) that serious and b) even going to be around in 5 years.
You’re absolutely right that shitting on people’s tools is bad.
I don’t know that i’m aware of sufficient evidence to agree that “what most of us do is [not serious enough for the performance concerns to matter].” And the claim that what most of us are doing isn’t going to be around in 5 years disagrees with my experience. Anecdotal I know, but a company a worked for until recently still maintains and adds new features to and ASP classic application.
I certainly agree that languages/frameworks persist. I work on a team as the only RoR guy with a bunch of Java developers. We have services in C# all over the place. All the more reason to cease and desist with the "mine is bigger than yours" malarkey.
validate is also a claim method in rails. Your example does not prove your point at all. It just shows you don't know rails well enough. Sorry, couldn't let someone be wrong on the internet. 😂
"I don't know rails well enough" exactly proves my point when the opposing point is "rails is a productive framework and makes developers happy!"
Just here to say that I love your "digital carpenter" phrase! Adopting it ASAP! 😆😆
IDK man. I am in like 7th company in my life, ranging from 10k employees to the current startup of 100, and in all of them, the apps deal with thousands of parallel connections. And it is big difference if your hourly batch takes 15 minutes on JVM or 3 hours on Ruby, because then you need to write your app as parallel right away (something not easy to do in Ruby) and them run it on 3 nodes, just because someone liked Ruby.
Your metrics for happines, clear code, easy to understand and flexible are subjective; personally, with Ruby, I was unhappy, the code was mostly messy, hard to undestand, ad very rigid.
sry...but do you think that this code is easy to understand:
vowelsCount = Hash['aeiou'.chars.map{|n| [ n, 0 ]}]
gets.chomp.chars.each{|n| vowelsCount[n] += 1 if vowelsCount.key?(n)}
I am doubt.
You can write unintelligible nonsense in any language, my dude. Ruby's focus is "developer happiness", and I feel that it delivers. If you prefer to make yourself miserable, Java will welcome you with open arms.
Please stop using absolutes in article titles. It's condescending and only serves to annoy, infuriate, or (worst of all) repel your prospective reader. 💚
It's strange to see someone who benefited so much in their career from using Ruby and RoR turn around and discourage others from using it as well. The reasons you list to not use Ruby lack nuance. For example, you claim Ruby is slow, but what are you comparing it to and in what situation? Yeah, Ruby doesn't take advantage of multiple cores, but that doesn't mean it's useless.
And the reasons you list why someone should use Rails are incredibly backhanded. Saying someone should use Rails if their app never changes or if it doesn't have complicated logic is not apart of a #healthydebate.
And just because a language is faster and compiled that does not guarantee that you will write better software.
The point of rails is that it lets you develop and iterate over a prototype very quickly. This is the reason a lot of successful companies were able to get off the ground and make money relatively fast.
Also, those same companies have used Ruby for very complex systems. An example is Airbnb, who wrote their large scale payment application initially in Rails. While they did migrate to Apache Kafka & Spark, they did it because of the massive increase in users, not because Ruby isn't multi-threaded.
Ruby and RoR were never meant to be the perfect tools but only focusing on their drawbacks isn't enough for telling people to stop using the language. And it's frustrating to see this kind of thinking in 2018.
I can relate to your experience, James. I tried moving to other frameworks, even to better option you mentioned.
But rails has one big upside, which is hard to ignore -- maturity of libraries (gems). With a big probability I can find a library that satisfies my picky requirements.
With Phoenix and Elixir I still find myself spending too much time on very trivial things. Since I'm an indie dev -- this is a luxury I can't afford.
But I can afford rewriting some components in languages that performs better, if there is a bottleneck in Ruby itself. But in a lot of cases, I just know how to make Ruby performant :)
I agree that Rubygems is one of the main reasons that people stick with Ruby and it is an amazing resource. I've written my fair share of gems over the years and I hope that they helped people in some way. Working with Phoenix can be pretty annoying when you can just get a hex package that just handles user authentication the way that devise does - you have to wire up a lot of code to get it to work. I think this is mostly about maturity but I think it will get there. I once joked that Elixir is powered by thousands of angry Rubyists and like all jokes I think there's more than a grain of truth in it.
Rubygems is great but I do not rely on it.
I can write whatever I need just fine, if I need it.
I wrote my own "package" manager in ruby and have been using that for ~13 years to manage my *nix systems.
Elixir has great ideas; erlang is awesome, but the syntax of erlang is UTTER SHIT.
But even then, too few people use elixir; and even fewer use crystal.
Say what you want about ruby but ruby IS used by LOTS of people.
This depends on how many people use a language. Crystal struggles a lot because of this - too few people go into crystal. Which is a shame. But I myself also am not using crystal, primarily due to lack of time; but also because the type-madness leads to syntactic monsters that I don't want to deal with.
Note that ruby 3.0 will get additional type information, so some of your fake-complaints above may be answered.
I still think your article is horrible though. Please try to make your points more objective in general.
Yep, as a one-man-show, it's tough to argue there are a lot of better options that allow for more productivity/hour than RoR.
If I find myself in a situation working on something that has 1mm connections simultaneously, sure, I'll use Elixir. But to spin up a CRUD app, which honestly, are still to this day, most online web apps, Rails and Ruby are tough to beat.
I use my own fake-webframework (created before rails came out).
Granted, it is way below feature parity with rails. But it also does not want to be feature equal.
I also use sinatra so I more belong into this world of simplicity.
And I am mega-productive related to the www there too, without needing RoR (but I value simplicity at all times; I hate the complexity of rails).
I just wonder why people think the www in ruby belongs to rails. I don't see it that way at all.
what is your framework?
While I agree with the assumption that we need to watch our website's performance and we should stop deliberately using slow languages (like Python and Ruby) and frameworks, this article missed the chance to point out that the most common problem with slowly loading websites is that they include a few megabytes of JavaScript which needs to be downloaded and parsed first.
BOOM
And executes code on your machine...
The #healthydebate hashtag and this clickbait title doesn't match.
A few points:
Rails is adapting to this world that just doesn't ony "shuffle data back and forth" (integrating webpack, adding websocket support). Also stimulus.js by Basecamp goes into that direction
Ruby is getting better and better (well it would be funny if it got worse :D): there's talk of adding JIT compilation, guilds (sort of isolated processes in user space) and type decoration
Maybe it won't innovate fast enough and lose developers (it happens to every technology I guess) but there's a valid argument for it you didn't make: there are still tons of Rails jobs :-)
Rails (and Django) are turning into "boring technologies", which is not inherently bad :-)
I'm more optimistic about their future.
My sense of parcel anxiety from yesterday is eased big time from leadership in the Rails community which does a great job of sniffing bullshit in web development and keeping things smooth.
This probably keeps me in Ruby more than anything else.
Although Rust and Elixir and others have a lot of former Rubyists leading the way in DX and pragmatism, as the post implies. Still, Rails makes me feel like I have some serious teammates in the game from small-to-medium-to-big organizations and lots in between. It's such a rock solid boring ecosystem.
This is really great to hear and I am forced to admit that I stopped following along with changes to Ruby a few years ago.
I also agree that "boring" is exactly what you want in production. But boring and slow?
"Fast enough". This is a really good article from an expert in Ruby and Rails: Is Ruby Too Slow For Web-Scale?
No, I won't. I would only agree that Ruby is not the go to language for everything you do or for everyone / every project.
That being, please weigh your choices with care, use matrices that make sense and avoid noisy opinions you see on web.
I will leave it here:
Looks like Javascript+Flow to me, which is by far not as capable as Typescript. I love Ruby, but typing is a language feature and does not belong into a library. IMHO. Hope Ruby 3.x will come with optional typing.
This will not happen. I saw a quote from Matz that he believes that type signature will be obsolete in 10 years and he doesn't want to add them (I will need time to find it). Important: he didn't say that he against static types (he is for it), he didn't say he against static analysis (he is for it).
The second point, nobody wants to repeat the Python2 vs Python3 situation, so it will be a gradual type system (I guess).
I'm doing a series of blog posts on Flow and TypeScript. There are, for sure, differences, but not so dramatic. The biggest issue with Flow is closed development, awful tooling and not very big community, but not the power of the type system itself. It is fairly comparable to TypeScript.
So it's basically a long and click baity article about static types > dynamic types? Wow never heard that argument before. Oh yeah and the performance issue, of course. Happens to me everyday at work when I need to sprinkle more performance on my app but alas Ruby fails yet again. If only it was written in java.
I didn't see any reason to stop using ruby in my private automation tasks. Using ruby in the company productions is usually question of managers that keep in mind a lot of reasons that sometimes is not technical related.
So, It is totally your solution to stop programming in ruby. Ruby get losing its positions in competition with python, it's the fact. And I feel sick of it. I suppose it happens mostly because of marketing reason, not technical. Guido living in America has much more ability to promote python in Hi-Tech than Matz living in Japan. Plus Matz is pretty introvert guy. So...
Not really. Ruby has been always inferior to Python technically and practically. Python had cleaner C bindings (which enabled Numpy, Cython and numerous other libraries). Python code is easier to debug and maintain: more explicit, less metaprogramming, fails early, better documentation.
Python also had "threading" library for ages. And its Unicode support was much better than Ruby's even in the days of Python 2.
I find it's hard to take seriously OP's arguments about Rails being "the only tool" in 2008 (I remember writing easily maintainable MVC websites in Python around 2006-2007) and Rubygems being the only package library (PyPI appeared 2 years earlier).
It always seemed to me that the only reason to love Ruby is to know nothing about Python.
Actually I don't care what comes early or later. The point is what more or less comfortable to use in practice. It's absolutely subjective.
By example I am eager with Ruby for ability to write one-liners like:
This one for example calculates how many files of what types exist in current directory and it subdirectories. I write similar one-liners in bash CLI without editor. How to write similar things things in python, I have no idea.
I know Python pretty well. I use it everyday for ALM automation for already 3 years. But anyway there still is wondering things in Ruby for me.
Rails is "the only tool ruby need for" mostly for people that usually far anough from ruby community. It's just popular internet mem that far from actual state.
I don't envy any person that would support such "one liners", but here's the Python version:
which one is easier to read, what do you think?
Your claim that you know Python "pretty well" seems dubious.
Good engineering is about writing a code which is reliable and easy to maintain. In my experience, Ruby's track record is abysmal on both counts.
P.S. Since I'm in the golfing mood, here's an one-liner in a statically typed language, which would be OBVIOUSLY not as elegant as the wonderful Ruby, right?
To talk about "easiness to read", you should learn more about functional programming and Ruby, of course. It's difficult for everyone to understand text or code if language it's written by is not known well.
I'm impressed that you reach an insight that not all prog.languages looks the same good in different applications.
So you still need only couple of steps to reach things that I talk about in beginning. And everyday exercises is very good habits. So You are definitely on the right way. Good job!
But your way to discuss here is boring me. I don't see any point to continue talk in this style. Good luck!
No. I will continue to use Ruby and whatever languages best addresses my use case. Fuck off with your stupid titles. Please stop writing shitty articles. Thanks. Fyi rails supports websockets and actioncable. And ops uses vms so just run a bunch of vms on multicore machines if you need concurrency and configure the appropriate port forwarding to apache nginx. Finally Airbnb and Shopify as well as Github are made with ruby and they make $$$. 1 man can do a lot with rails.
Stop posting articles here then, because this site is on Rails.
1) Rails, out of the box, doesn't have (trend) - The current trend in webdev is to make sites that are so slow, most phones and laptops can't run them comfortably. I like this, because exactly zero of my clients want to arbitrarily exclude 95% of their potential customers because of fashion concerns they have never heard of and don't care about. I enjoy taking business from people who feel my style is "dated".
2) Typing holy war - I understand why dynamic typing and duck typing are less preferable, but in practice, I have never seen any of the major disasters that people predict.
3) Ruby is slow - See point one. My apps run pretty fast, and it's easy to be fast when the competition has 100% deprioritized speed.
4) Concurrency - Ruby doesn't have the best concurrency model, so on a project where that's important, I don't use Ruby. Hardly enough reason to abandon ruby altogether.
Thanks all for the feedback. I agree that the title is a bit clickbait, but if I hadn't given this article this name would you have commented?
I agree with most of the points raised here (and on the Ruby NZ slack where I cross-posted it). I'm sorry if it appears that I'm shit talking Ruby and Rails. This is my day job too. We have a joke around these parts that Rails is "New Zealand scale" - ie perfectly good for most workloads in this country and I would tend to agree (although I've worked on a few projects now where that assumption was wrong).
I guess the point I'm trying to make is from a purely technical standpoint Ruby is not up to the job we're doing any more. I want to know what factors continue to support it's (obviously widespread) adoption.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.