The reason I dislike the twitter argument is, even if ruby was the root cause, the choice of ruby still launched the business and got them to that first success disaster.
The deeper reason I think it's a bad argument is because twitter ran into a problem native and new to them - massive fan out (celebrity tweet -> millions of followers). that's not the kind of thing any language typically does while responding to a web request.
Lastly - heavy survivorship bias here. We will never hear about all the startups which were "scalable from day 1" on java or whatever and fizzled out.
Looking at https://www.wired.com/author/sheon-han/, this author's whole strategy seems to be bear poking. The writer is skilled but at least in this ruby one they are definitely hate-farming. I'm a little sad to see content of this quality in Wired.
Anyway, I'm off. Returning to be part of the usually silent majority who is happily using ruby to ship useful software!
> The reason I dislike the twitter argument is, even if ruby was the root cause, the choice of ruby still launched the business and got them to that first success disaster.
This only works if there was no better language to launch a similar business in, which would've avoided the disaster
Was there one at the time? My impression is that back then you could either have a language/framework combo that's easy to work with _or_ one that solved all these technical problems, but not both.
In the original article, author never actually went into why they disliked their experience with Ruby. They listed some historical shortcomings which we can only presume they were experiencing on the code base they found themself working on. I think the best point out of that first article was don't pick Ruby as a development language in 2025, there are better options for any advantage you might think it will give you.
I think that should've been the main point to attack.
In the present article, the author went for pathos instead and in some ironic sense confirmed the previous article's notion that Ruby is powered by sentimentality.
Many people that adore Elixir also think Ruby is a no go, despite the latter being a strong influence. Arguments against Elixir tend to revolve around its lack of traction, not its lack of seriousness.
> Many people that adore Elixir also think Ruby is a no go, despite the latter being a strong influence. Arguments against Elixir tend to revolve around its lack of traction, not its lack of seriousness.
Elixir is funny. I've done Elixir for years now, and did some Ruby at the beginning of my career. A ton of people come to Elixir for the familiarity of the Ruby-like syntax but with a functional programming basis. They like Ruby but get tired of OOP and mutable state and want to try something else. They tend to stay for the runtime/VM, called the BEAM.
Don't get me wrong, the Elixir language is nice, but the BEAM and its operational characteristics feel night-and-day compared to Ruby and most other languages that were designed for a world of single-threaded programming.
When you're using the BEAM (any language - there are a few now) there's this amazing sense that you're using something that was _designed to be operated_. You can instrument anything. You can trace anything. You can see the live state of anything. You can restart anything. It's a holistic _system_ for building systems, not just a language.
> When you're using the BEAM (any language - there are a few now) there's this amazing sense that you're using something that was _designed to be operated_. You can instrument anything. You can trace anything. You can see the live state of anything. You can restart anything. It's a holistic _system_ for building systems, not just a language.
Well said. Question for elixir fans or the haters, what's the perception re: current blockers for widespread adoption? Years ago, it was nothing more or less than third-party libs and frameworks. That must be better by now, or there's a short-list of what's missing?
Somewhat of a tangent, but TFA doesn't mention python and I would think for rubyists this is (still) the elephant in the room. It kind of won to the extent they target the same niches and same audiences, for better or worse. I know it's kinda naive, but I was really hoping elixir would get all of the ruby crowd excited, and they'd move the best parts that they can't live without into elixir. Why didn't they / don't they? Is it all about OOP? Or if rails is the killer app, would a rails "skin" for phoenix not go a long way towards scratching the itch?
I'm surprised that Crystal[1][2], a heavily inspired by Ruby compiled language, was not mentioned in all of this. Though it has more of an issue than Elixir, where various people can feel it has not gained enough traction[3][4] (according to various rankings). Elixir at least ranks in the top 50, per TIOBE.
YMMV, but both articles are two nothingburgers. First one doesn't say a thing about what's possibly wrong Ruby language but rambles something about StackOverflow popularity and Twitter issues, second one doesn't say a thing about what's wrong with the first article and just tells a tale about Ol' Good Times and aesthetic differences.
The fact that it's not some LLM-produced slop for engagement, but something that was written by real humans and is somehow paid attention by real humans is sort of depressing.
Here is my single way of deciding what your favorite language is.
It is not "I like to write code in this language" but "If I am handed down a production ready system, I would prefer it to be written in this language".
A lot of people won't say the same answer to the first and the second question.
I think those are two separate concerns.
Writing code and running a tech business are two different things. I personally love Ocaml and think it's an excellent language and very underrated. However, I (probably) wouldn't want a production-ready system written in it, because it has a weaker ecosystem of libraries and frameworks, and it's harder to hire experienced people who already know or are willing to learn the language.
Indeed.
And the latter, that is, taking over and maintaining code written by someone else, is the more common concern in day-to-day jobs. More likely that you will get to build and improve an existing system than create one from scratch.
This heavily depends on the particular era of the language and the particular coding practices of the team though.
For example, I'm happy to maintain Python codebases with type annotations and type checking enabled. Those without better have a pretty solid docstring culture and be willing to add progressive type checking. It doesn't so much matter what version of Python it is.
Yes, but ... this depends strongly on whether your task is to maintain that production system in its current state indefinitely, or to keep developing it and continuously integrate with new technologies under time constraints. If the former, the right answer would probably be COBOL. If the latter, this is where things get interesting.
I love ruby. It's certainly not sentimental; I enjoy writing it and working in it, certainly a lot more than javascript.
I do feel like these sorts of attacks on ruby are quite weird. It's totally ok not to enjoy working in any particular programming language, but I wonder what the angle is to write about it is.
Arguments regarding ruby's successes are always so weird to me. Github, Twitter, Coinbase, and Shopify are all examples of great success. Challenges with scaling are successful problems.
It's a great tool and if you read this, consider and evaluate if ruby is appropriate for your next project. :)
This is a weird response to a weird article. The original article doesn't define its terms and, as Robby points out, that makes it hard to critique. If a language is only "serious" if it can scale infinitely for all use cases then sure Ruby isn't serious - most languages aren't.
That said - this response and the critique seem to basically agree. The critique can be summed up as "Ruby doesn't work forever" (and so it should never be used) and this is saying "Ruby doesn't work forever" (which is fine). I could almost understand this post as saying: 'Ruby isn't serious and that's not a problem for anyone who uses it.'
I will say that I found it funny that the original article attacked Ruby for being all the way down at "18th place" (This is inaccurate - it's 14th in 2024) on the SO dev survey - while talking up Scala which is 9 places further down on the survey[1].
> critics love the Twitter example. But look closer. Ruby carried them further than most companies will ever reach. They outgrew their shoes. That’s not an indictment… that’s success.
> I’ve never seen a team fail because they chose Ruby. I have seen them fail because they chose complexity. Because they chose indecision.
> GitHub held the world’s source code together for years using Ruby.
There are many examples of companies that used Ruby at one point very successfully but moved on from it once it no longer fit their situation. This isn't a critique of Ruby! But it is agreeing that Ruby can be outgrown and that, if you are looking to start with a language your usecase probably won't ever outgrow, Ruby might not be the best choice.
Neat. How is offlineasm used? (Without going into the details about the background of LLInt, that is—what I mean is, how is the compiler invoked?) Is it just the reference compiler, corresponding to some other machinery inside JSC?
I see people waxing poetic over Ruby a lot saying that it's a language "built for the human". The thing is, every language is built for humans (or at least should be) but we tend to have different definitions for what "built for humans" means. Ruby certainly has some clean and expressive syntax, but I personally find it difficult to use because of its dynamic typing (which makes it hard to know what the types are while I'm writing it) and the heavy use of macros and other magic (which does unknown operations without my knowledge and introduces symbols into the scope mysteriously). That said, it clearly works great for some humans, just not for this human (me).
Obviously ruby is bigger than just rails, but rails definitely popularized the idea of magical objects that are automatically syncing state and doing things on your behalf. This is presented by fans as surprising and delightful, rather than surprising and terrifying.
Popular python projects like requests and flask also lean into the idea of providing a programmer interface that is expressive but also maximally brief on the happy path—see especially the context local proxies in Flask (request, session); these look like global module imports, but they're actually request specific despite not being passed into your handlers... eek.
On the other side of things, languages like zig and go feel like a bit of a backlash to this, that no, magic is bad and everything should be explicit, even if it costs us a bit of code to do so.
Rust I think sits at an interesting place in this, because it's all pretty strict and explicit, but all the macro and type system stuff does re-open the door to offering some DSL-like things in a way that's perhaps a bit cleaner than what other languages would have to do to get to the same place programmer interface-wise.
Funny that you mentioned Flask, which literally started as an April Fool's joke [0], but that hasn't stopped it from becoming the 10th [1] or 11th [2] most popular web framework, with over double the number of devs compared to Rails, so "seriousness" likely has nothing to do with making people want to use it.
> see especially the context local proxies in Flask (request, session); these look like global module imports, but they're actually request specific despite not being passed into your handlers... eek
I switched from Ruby to Elixir about 10 years ago for a number of reasons. 10x performance on various algorithms I translated into Elixir was one. Another one was 100% immutability, ruling out an entire class of bugs. A third was excellent concurrency support, which was of course aided by the immutability. A fourth was that they tried to retain the friendliness of Ruby.
At least a few emerged later. Pattern-matching + guards are godlike and eliminate tons of boilerplate argument-checking logic. Per-process GC, no GIL, etc. etc.
A small learning curve to master functional-language semantics and I haven't looked back.
Elixir simply scales better in every way- long-term maintenance, load, etc.
The Ruby community is/was amazing, though.
The only thing I wish it could do was compile down to a native executable or run in the browser.
I still somewhat "think in Ruby" though. It was really the first language that let me comfortably build large projects and really lean into metaprogramming. I prefer Elixir/Erlang for personal projects though.
Haven't lucked into an Elixir/Erlang job yet to experience working on such a codebase with others yet, so for that my preference is still C++.
Work makes me use Golang and Python and I find no joy in either.
I still drop into Ruby if I need a small script for something personal.
Ruby is 1000x better than Go or Python IMHO. Personal opinion, of course.
I've been lucky to work in Elixir jobs for a few years. Funny thing, though, I've been curious about getting closer to the metal after messing with LuaJIT and its C FFI and seeing the rather shocking performance (coming from a high-level scripting background). I content myself with converting some of my more unfortunately-sophisticated Bash utility functions to LuaJIT, which so far has been an all-positives experience.
I'm not a fan of Ruby, but the original Wired article is pure, distilled rage-clickbait, and nobody should be dignifying it. An interesting case where there'd be a more generous reading had the piece run solely on a blog, rather than on Wired.com.
But even if it had been written in good faith, this species of article (specifically: harsh critiques of popular programming languages written by people who aren't ongoing practitioners in that language) are a toxin to HN, the resulting language fights they gin up one of our closest equivalents to a cytokine storm. Don't feed into them.
Readit News
The deeper reason I think it's a bad argument is because twitter ran into a problem native and new to them - massive fan out (celebrity tweet -> millions of followers). that's not the kind of thing any language typically does while responding to a web request.
Lastly - heavy survivorship bias here. We will never hear about all the startups which were "scalable from day 1" on java or whatever and fizzled out.
Looking at https://www.wired.com/author/sheon-han/, this author's whole strategy seems to be bear poking. The writer is skilled but at least in this ruby one they are definitely hate-farming. I'm a little sad to see content of this quality in Wired.
Anyway, I'm off. Returning to be part of the usually silent majority who is happily using ruby to ship useful software!
This only works if there was no better language to launch a similar business in, which would've avoided the disaster
I think that should've been the main point to attack.
In the present article, the author went for pathos instead and in some ironic sense confirmed the previous article's notion that Ruby is powered by sentimentality.
Many people that adore Elixir also think Ruby is a no go, despite the latter being a strong influence. Arguments against Elixir tend to revolve around its lack of traction, not its lack of seriousness.
Elixir is funny. I've done Elixir for years now, and did some Ruby at the beginning of my career. A ton of people come to Elixir for the familiarity of the Ruby-like syntax but with a functional programming basis. They like Ruby but get tired of OOP and mutable state and want to try something else. They tend to stay for the runtime/VM, called the BEAM.
Don't get me wrong, the Elixir language is nice, but the BEAM and its operational characteristics feel night-and-day compared to Ruby and most other languages that were designed for a world of single-threaded programming.
When you're using the BEAM (any language - there are a few now) there's this amazing sense that you're using something that was _designed to be operated_. You can instrument anything. You can trace anything. You can see the live state of anything. You can restart anything. It's a holistic _system_ for building systems, not just a language.
Well said. Question for elixir fans or the haters, what's the perception re: current blockers for widespread adoption? Years ago, it was nothing more or less than third-party libs and frameworks. That must be better by now, or there's a short-list of what's missing?
Somewhat of a tangent, but TFA doesn't mention python and I would think for rubyists this is (still) the elephant in the room. It kind of won to the extent they target the same niches and same audiences, for better or worse. I know it's kinda naive, but I was really hoping elixir would get all of the ruby crowd excited, and they'd move the best parts that they can't live without into elixir. Why didn't they / don't they? Is it all about OOP? Or if rails is the killer app, would a rails "skin" for phoenix not go a long way towards scratching the itch?
[1]: https://crystal-lang.org/
[2]: https://en.wikipedia.org/wiki/Crystal_(programming_language)
[3]: https://archive.md/sJRyf (TIOBE November 2025)
[4]: https://www.slant.co/topics/15430/~compiled-programming-lang... (Slant Rankings)
The fact that it's not some LLM-produced slop for engagement, but something that was written by real humans and is somehow paid attention by real humans is sort of depressing.
It is not "I like to write code in this language" but "If I am handed down a production ready system, I would prefer it to be written in this language".
A lot of people won't say the same answer to the first and the second question.
Indeed. And the latter, that is, taking over and maintaining code written by someone else, is the more common concern in day-to-day jobs. More likely that you will get to build and improve an existing system than create one from scratch.
For example, I'm happy to maintain Python codebases with type annotations and type checking enabled. Those without better have a pretty solid docstring culture and be willing to add progressive type checking. It doesn't so much matter what version of Python it is.
"Python codebases with type annotations and type checking enabled" is not the norm. Consider a random file from the famous `pytorch` framework.
https://github.com/pytorch/pytorch/blob/main/torch/_functorc...
Even this file does not have type annotations everywhere.
/s but also true
I do feel like these sorts of attacks on ruby are quite weird. It's totally ok not to enjoy working in any particular programming language, but I wonder what the angle is to write about it is.
Arguments regarding ruby's successes are always so weird to me. Github, Twitter, Coinbase, and Shopify are all examples of great success. Challenges with scaling are successful problems.
It's a great tool and if you read this, consider and evaluate if ruby is appropriate for your next project. :)
That said - this response and the critique seem to basically agree. The critique can be summed up as "Ruby doesn't work forever" (and so it should never be used) and this is saying "Ruby doesn't work forever" (which is fine). I could almost understand this post as saying: 'Ruby isn't serious and that's not a problem for anyone who uses it.'
I will say that I found it funny that the original article attacked Ruby for being all the way down at "18th place" (This is inaccurate - it's 14th in 2024) on the SO dev survey - while talking up Scala which is 9 places further down on the survey[1].
[1] https://survey.stackoverflow.co/2024/technology#most-popular...
Where does the response even address this?
All I know is that Ruby code I wrote 10ish years ago is still going strong, for example a whole compiler https://github.com/WebKit/WebKit/tree/main/Source/JavaScript...
> critics love the Twitter example. But look closer. Ruby carried them further than most companies will ever reach. They outgrew their shoes. That’s not an indictment… that’s success.
> I’ve never seen a team fail because they chose Ruby. I have seen them fail because they chose complexity. Because they chose indecision.
> GitHub held the world’s source code together for years using Ruby.
There are many examples of companies that used Ruby at one point very successfully but moved on from it once it no longer fit their situation. This isn't a critique of Ruby! But it is agreeing that Ruby can be outgrown and that, if you are looking to start with a language your usecase probably won't ever outgrow, Ruby might not be the best choice.
Neat. How is offlineasm used? (Without going into the details about the background of LLInt, that is—what I mean is, how is the compiler invoked?) Is it just the reference compiler, corresponding to some other machinery inside JSC?
Popular python projects like requests and flask also lean into the idea of providing a programmer interface that is expressive but also maximally brief on the happy path—see especially the context local proxies in Flask (request, session); these look like global module imports, but they're actually request specific despite not being passed into your handlers... eek.
On the other side of things, languages like zig and go feel like a bit of a backlash to this, that no, magic is bad and everything should be explicit, even if it costs us a bit of code to do so.
Rust I think sits at an interesting place in this, because it's all pretty strict and explicit, but all the macro and type system stuff does re-open the door to offering some DSL-like things in a way that's perhaps a bit cleaner than what other languages would have to do to get to the same place programmer interface-wise.
[0] https://lucumr.pocoo.org/2010/4/3/april-1st-post-mortem/
[1] https://www.statista.com/statistics/1124699/worldwide-develo...
[2] https://survey.stackoverflow.co/2025/technology#most-popular...
I guess that was a Bottle thing that Armin Ronacher borrowed: https://bottlepy.org/docs/dev/api.html#request-context
A bad idea in retrospect, but hard to change now: https://github.com/bottlepy/bottle/issues/761
At least a few emerged later. Pattern-matching + guards are godlike and eliminate tons of boilerplate argument-checking logic. Per-process GC, no GIL, etc. etc.
A small learning curve to master functional-language semantics and I haven't looked back.
Elixir simply scales better in every way- long-term maintenance, load, etc.
The Ruby community is/was amazing, though.
The only thing I wish it could do was compile down to a native executable or run in the browser.
I still somewhat "think in Ruby" though. It was really the first language that let me comfortably build large projects and really lean into metaprogramming. I prefer Elixir/Erlang for personal projects though.
Haven't lucked into an Elixir/Erlang job yet to experience working on such a codebase with others yet, so for that my preference is still C++.
Work makes me use Golang and Python and I find no joy in either. I still drop into Ruby if I need a small script for something personal.
I've been lucky to work in Elixir jobs for a few years. Funny thing, though, I've been curious about getting closer to the metal after messing with LuaJIT and its C FFI and seeing the rather shocking performance (coming from a high-level scripting background). I content myself with converting some of my more unfortunately-sophisticated Bash utility functions to LuaJIT, which so far has been an all-positives experience.
But even if it had been written in good faith, this species of article (specifically: harsh critiques of popular programming languages written by people who aren't ongoing practitioners in that language) are a toxin to HN, the resulting language fights they gin up one of our closest equivalents to a cytokine storm. Don't feed into them.