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?
> 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?
It's complicated.
The library/framework situation is much better than it used to be. There isn't much that's glaringly missing anymore. Some things have lighter maintenance than one might like, but most stuff is there.
I think Elixir and the BEAM have a weird problem in that it's somewhat hard to understand their benefits until you use them. This is not the case with a lot of other stuff. If you were coming from Java in the 90s and you saw Ruby, you didn't have to use Ruby to realize just how much less code it took to do similar things. You could just see code examples.
If you used Perl back in the day, you didn't have to actually use Python to see how much easier it was to read Python as a novice compared to Perl's eccentricities.
The BEAM is tough to sell because its benefits are not something you can easily see on a screen at a meetup, for example. "What if you had a VM that was designed for the ground up for concurrency" doesn't sell. People respond with "well my language already has threads and promises". "What if your language gave you a builtin toolkit to partition and restart the various different subsystems in a rigorous, well-defined way?" People say, "I already have systemd and it restarts my services."
Having done it for some years now, the BEAM kinda has "the quality without a name"[0]. It feels "whole" in a way that other environments don't, and that's difficult to show. This is not something that shows up trivially on a slide deck or a landing page, and most people don't want to take a gamble on a smaller language community that's seen as different and weird compared to the more mainstream language they already know, especially when the most positive things they hear are "it's a functional language that does concurrency better". For most people, this just isn't a compelling enough pitch to get them to leave Python or Javascript or Java (or Ruby).
By the way, I'm not blaming folks, this is both a rational and normal way of evaluating risk when faced with an unintelligible upside and an immediately apparent downside (small community, uncertain career prospects, questionable library coverage, etc.). I think as a community, we (Elixir) have done a poor job in making Elixir seem less risky.
> 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.
IMHO Python won the war. Ruby won server-side webapps battle with Rails, which is still going strong, but Python won literally everything else by a landslide. And Python still even has Django. Python is _everywhere_. There's no stats on this that I know of, but I bet 90%+ of Ruby usage is Rails. This is not the case with Python.
To be clear, this is all in the context of adoption. Ruby may never have Python's adoption, but Ruby has been hugely influential. Tons of other technology can trace its lineage to Ruby, whether it's Elixir as a language, or Rust's tooling (Cargo), etc.
> 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?
Rails still has a large amount of inertia, both technically and culturally. It's still very good at its niche. Getting Rails folks to move away from Rails would take something as better as Rails was than the Java stuff that came before it. Plus, some people just love Ruby! Elixir isn't Ruby. Elixir is more explicit, doesn't have mutability, doesn't have objects, etc. The similarity really ends at syntax, and I think a lot of Ruby folks are happy with what Ruby is, which is totally fine.
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.
They're becoming the norm for newer systems written in Python though. So I don't think the language is enough information to go on. This heuristic simply biases against languages that have been around a long time because more of their code was written before practices evolved.
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.
COBOL is used for the longest continuously running systems, particularly in the financial industry, many of which have been in production since the 1960s - mainly on mainframes, but noawadays also increasingly in cloud environments. There's nothing that comes close to the level of reliability that these offer, with the next closest probably being Fortran, Ada and Erlang.
I found this article with some numbers [0], with the top one being that "95% of ATM swipes rely on COBOL code". If you just need to maintain something in production, and only occasionally update the business logic, without having to upgrade the architecture, COBOL is the way to go.
My old boss wrote COBOL code for a core finance process… in 1975, well before I was born. He retired in 2019, and that code is still there with a few mods and probably will remain for another decade.
In fairness, it’s pretty fundamental stuff. But… the company has been working on moving to some Oracle bs for 5-6 years.
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?
That’s how the interpreter in JavaScriptCore gets compiled. The interpreter is written in a macro assembly dialect I invented and this is the compiler for it.
(I say compiled, not assembled, because it’s higher level than normal assembly. There’s an actual pipeline of transformations that happens. Plus a Turing complete macro language)
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 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
This article feels like someone is defending their language. And that doesn’t bother me, but I don’t value that.
I don’t care about what’s popular or what feels most familiar. What I want is a dispassionate discussion of how different language features impact code quality, and I think you can only find that in more abstract discussions. The kind that turns people off with its talk of monads and applicatives.
> What I want is a dispassionate discussion of how different language features impact code quality
This can be difficult because code quality, productivity, safety are hard to objectively define and measure, so we always fall back to differences in interpretation and experience.
I would be interested in serious attempts to argue for this, even if they can't reasonably be backed up by data.
For example, I think there's a pretty strong argument that immutability makes it easier to write multithreaded code (perhaps at some performance cost), because it entirely prevents common types of bugs.
Similarly there's a good argument that making methods open to extension (like Kotlin or Julia) makes it easier for an ecosystem to adopt unified APIs without explicit coordination.
There's obviously a very strong argument that Garbage Collection prevents a lot of memory safety bugs, at costs to interoperability and performance.
> dispassionate discussion of how different language features impact code quality
I think we can start disagreeing here.
The metrics shouldn't be solely code quality, but also simplicity, readability, and how fast you can express yourself in it.
Code quality will go up the more language friction you add: types, "one way" of doing things, and function-oriented programming. Same code in a language with heavy types and strict functions will be of course "more solid". However, it will take 10x the time to write, be less flexible, and harder to understand.
Do you know of any articles/papers that try to do in-depth analyses of which features are helpful for building big systems?
Most posts I can think of basically say "X language is good" or "Y language is bad", but I'd really be interested in arguments like "feature A is better at accomplishing goal Z than feature B"
Not quite the same, but I find "data-oriented programming" to be a very strong method for managing large codebases. By that I mean having data structures that designate the end state that you want, having another set of code that gets you to those end states, and maintaining a pretty clear boundary between the two.
(If you like with "Functional Core, Imperative Shell", this is a way to further divide the Functional Core.)
It works well because it narrows the surface area of a lot of possible bugs: either your configuration is wrong, or your code doing the transformations is wrong.
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.
I indeed really liked Ruby because of it's expresiveness, it being totally OO, the lovely readable and writeable syntax.
But yeah, that was 20 years ago. These days I find Kotlin to be the perfect fit for my projects, because of the static typing and its ergonomic syntax. I just don't feel confident about Ruby projects when they start growing. But, I still love the language, although mostly for small things.
Yeah. I was pretty neutral on ruby, until somewhere I worked some coworker put an @ on a variable relating to sessions and suddenly people started seeing each other's accounts.
Now some people won't fault the language for that, but it feels like a footgun and I've noticed a trend that often the worst (I.e. most dangerous) gravitate toward languages with the fewest safeties in them (less type safety, no compile checks, no memory safety, little concurrency safety, less safety around shared state)
Why do you think this is worse than someone saying about Java: "some coworker put `this.` on a variable relating to sessions and suddenly people started seeing each other's accounts"? Because it's less obvious what "@" means rather than "this."?
Edit: I forgot that Java has implicit `this`! That's so, so much worse!
I'm pretty sure you mean @@ on a variable and are not common in a Ruby project. @@ is a class variable and I can see that causing all sorts of problems with data across sessions.
I have been using Ruby for 13 years and only once have I seen anybody use an @ on a variable…and it was part of a distributed caching strategy for an ad randomizer.
How about the fact that Ruby makes immutability difficult, and Hash does not copy keys on write and read? Almost every program uses a hash table, and Ruby makes them especially dangerous.
Ruby is a joy to program in. I started exploring it after using Haskell and Smalltalk and was pleasantly surprised when the language would do things like both of them.
fwiw As someone without Ruby programming skills, my experience was that it does unpredictable "magic" things, which I did not find helpful when writing mundane code. fwiw
If people want to know the main reasons why Ruby or by extension RoR, is popular, please check this excellent article by the author of a non-popular programming language Stanza [1].
From the cited article [1]:
"Casual website designers can safely completely ignore the concepts of types and memory deallocation because Ruby is dynamically-typed and garbage-collected. These features are simply not available in all other languages. Java's meta-programming features, for example, are just not powerful enough to implement a system like ActiveRecords. Rails is only possible because of Ruby."
But I'd argue that you can still have types and still have a very powerful meta-programming features and abilities of compiled language for example D to implement a system like ActiveRecords [2].
So glad someone already spoke up about this -- I love Wired, and I think that piece is really poor (not because I love Ruby or think it's without fault, but because the argument it makes is essentially "it's not Ruby or Python, which have static typing tools.")
I enjoyed ruby as a language for a while, but the one truly maddening aspect of it is that (as of 10 years ago anyway) nobody actually wrote threadsafe gems (because everyone was writing for Rails, which was single-threaded). That and the rampant monkeypatching that made the standard library hard to count on. These are the things that make it feel really "unserious" to me. I have no idea if these complaints are still current, though. I assume thread safety has been tackled at the very least.
> rampant monkeypatching that made the standard library hard to count on
That was very frustrating when doing regular development after using Rails, all the "built-ins" were actually patched into the stdlib by Rails and not available without it.
Ruby is one of the most fun programming languages out of the 6+ languages I've worked with, and I was very productive with it. Unfortunately, due to my experience working at a Ruby shop where Rails misuse and abuse crippled the company, I don't enjoy using Ruby anymore, and will never recommend using Rails for production-grade software. Hopefully you've had a better experience with Ruby and still enjoy writing beautiful software with it - hopefully not with Rails.
It's one thing for J.K. Rowling to write Harry Potter outlines on cocktail napkins. A pen and a cocktail napkin can be quite the foundation for expression, indeed. But the same flexibility lets other people doodle, and still others blow their nose.
The capacity to enable greatness is neither the same as the encouragement to enable greatness, nor the guarantee to enable greatness, and there's a lot of survivor's bias at the top of the Ruby and Rails communities.
This is exactly what I've done. I don't enjoy Rails very much but I love working with Ruby and Sinatra. The community has done a great job to keep Rails separated from Ruby when they release tools, so that they don't depend on or require Rails.
A lot of the aversion towards ruby I've gotten from people that have worked with it before mainly stems from complaints I share with the philosophy of Rails (making big changes to it when needed is like driving a freight ship instead of a small boat) and the complexity that can go with that, or with horror stories around poorly implemented metaprogramming, which are both valid points to me because I honestly share them. But Rails is not Ruby, and the community in general has been a lot more responsible with using metaprogramming carefully than it was in the early days.
Ruby becoming successful through Rails was a boon for it in the short term but I think also detracted from it's future growth at the same time as it became hard to untether developers' bad experiences with huge Rails apps with their experience using Ruby itself.
Personally, I love using Ruby so much for my own needs that if it ever was to fall into obscurity to the point of being unusable for modern tasks, I have decided that will be the point that I probably retire from programming and move on to other things in my life. It's not that I can't learn a new language for my daily driving, it's that I... don't really want to at this point.
The language I thought was pretty cool and similar was Crystal, but I've never run into the use case to try it, because I've never had something I couldn't handle with Ruby itself. Performance in my world is rarely a bottleneck, and I would not want to build a very large web app with a lot of complex business logic with it.
This take is almost as condescending as saying that Ruby isn't a serious language.
Ruby arose and became popular because it caters to a niche that was underserved by the competitors of the time (and while I'm no historian, I think Rails had a big role to play in Ruby's popularity).
Ruby is very ergonomic, and so is Rails. Frankly, almost 10 years after moving on from it, ActiveRecord is the yardstick by which I measure the ergonomics of all other ORMs in other languages, but what ergonomic means will vary from domain to domain.
With languages like Ruby and Python, it's very easy to get from nothing to an app that will work generally well enough almost straight away. A lightweight syntax, a lot of implicit functionality, and a flexible type system are all great for that, but in my current niche, I couldn't use it (I currently work with Rust, and the explicit control is a huge selling point, despite the much heavier syntax and more complicated semantics). That doesn't mean Rust was built without the human experience of using it in mind, though, and arguably the opposite's true.
At the time, Java. J2EE (entity beans and session beans), Java Server Pages, Apache Struts. I think it's hard for people who didn't live through it to appreciate just how painful it was to work in that stack circa 1999-2003, like it just doesn't seem plausible that the whole industry would go along with a stack with that much boilerplate for that little added value.
Back then, Ruby and Rails opened a lot of people's minds to the idea that we were allowed to make "delightful" a consideration in API design, not just S.O.L.I.D. or whatever. These days, there are way more mainstream languages, frameworks, and communities that take humane APIs seriously.
Putting aside the fact that this is about ruby vs other languages, not rails vs other frameworks, I cannot help but feel like ruby optimizes for fitting code onto slide decks rather than other human concerns (like, unambiguous communication of semantics at a glance).
I certainly have written a great deal of ruby and have no strong opinions about the language aside from "I will shoot the next person who uses method_missing", but I find the people who do have strong attraction to the language endlessly fascinating. By far, the most human aspect of the language is the community built around it.
This really resonated with the way I feel about Ruby. I haven't had the opportunity to seriously write Ruby in years, but I measure every development environment against the classic ruby/rails/rake/gem/bundler experience and I always find myself missing how productive Ruby was to work with, inside and outside of Rails. I think Ruby particularly excels in its ability to mold itself structurally to match its problem domain. Rspec and ActiveRecord and to a lesser extent Bundler and Rake are still the most ergonomic versions of tools in their class that I have used to date, and they all expose some sort of powerful DSL that feels magical in just the right way.
These days I mostly use more "serious" languages (python, Java, C#, C++), but it's because I want to work on a domain within those languages and I don't have the time to commit to bringing the domain to Ruby. I should call her...
> Critically, Ruby’s performance profile consistently ranks near the bottom (read: slowest) among major languages.
Without a cite, perhaps because it's not really true. Ruby's performance is similar to python's. Granted, neither one is going to win any competitions, although I'm not sure what the field of "major languages" is.
> Ruby's performance is similar to python's. Granted, neither one is going to win any competitions...
It's not just that they won't win any speed competitions, but that Ruby and Python are bound to come in last place. The only question is, which one comes in last and which 2nd to last. Runners up include Perl, PHP, and sometimes non-JIT Lua. Choose any benchmark, the results are consistent: https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
There are many good comments here about why the "Ruby is not a serious programming language" article is trash, and it is. What bothers me is that this article is on wired.com. I would expect more from Wired, and unfortunately, the article will get many views.
> I’ve never seen a team fail because they chose Ruby. I have seen them fail because they chose complexity. Because they chose indecision. Because they chose “seriousness” over momentum. Ruby just needed to stay out of the way so people could focus on the real work.
I am entirely indifferent to the topic of Ruby, but this sentence really resonated with me. I'll take momentum over premature optimization for scale any day of the week.
My response is a lot more terse: none of the complaints in the article actually impact usability, if it was actually less useful than other languages people wouldn't be using it. I wish Shopify was the primary example, because its the exact kind of high scale, data-rich kind of apps that Wired alleges to be near impossible.
As someone that is slowly being dragged into agents, and AI powered tooling, I am start to see language wars even more worthless than they used to be.
Manual memory versus GC, JIT, AOT, interpreted, begin/end or curly brackets, unsafe or not, whatever.
We will be slowly moving into some kind specifications for autonomous systems (please not YAML based), up to a point, and language wars will become a moot point, only relevant to the selected few implementing the low level parts of how everything comes together.
My only complaints about Ruby, as someone that never really did much with it, would be a more Smalltalk like dev experience (not sure how RubyMine fares), given its influences, and a proper JIT in the box (which is happening).
Seriously, I think it is a petty mistake to characterize Ruby as unserious. I am not drawn to the language myself, and my previous interest in it waned after debugging dependency rot in a cloud deployed Rails app more than 10 years ago. However, to label it as unserious would be nearly as unserious as labelling python unserious.
If Ruby pays your bills, then I think calling it a not serious language is a bit of a stretch. Just look at Mike Perham's Sidekiq - he made a living out of selling a RubyGem.
The majority of the world's Ruby programmers are in Japan, where it's used for a whole lot more than building Rails apps. So Ruby isn't going anywhere, although it may become a curiosity in the West over time.
> Culture doesn’t reliably reward the serious. Neither does business.
It rewards the resonant. The clear. The human. The work that connects.
Culture maybe, but business rewards what make business going on. Only that and Ruby proved that it can make businesses start and keep them going on. The few ones that exceed the capabilities of the runtime had to pivot to something else, in part or completely, but would we had a Twitter if they started coding in pick-your-favorite-serious-language? Maybe a competitor would have overrun them. We'll never know.
What I know for sure is that Ruby has been paying my bills for nearly 20 years. That's more than any other language I used, serious or not serious. It worked for me.
Do the user of _any_ language care how serious the language is?.. nowdays there are so many options to pick from, I love Ruby, I use it all the time, but I also like Python, Elixir and system languages like C++..
The original wired piece is effectively a lot of words that swirl around one poorly argued point: ruby is falling behind because of it's lack of static typing support. "Seriousness" is an ironically unserious way to evaluate, well, anything, but if you were trying to force a definition based on the rest of the poorly formed narrative, it must be "static typing". Performance doesn't work as serious critique, because...python, and it probably shouldn't anyway (within some semi-reasonable range).
Except for static typing and ruby's particular style of metaprogramming (one could argue python enables decorator-based "meta" programming, but whatever), ruby and python are basically the same language, with some obvious semantic differences. Of course there is much about ruby and python that is very different -- adoption, library support, community, vibe, whatever. And you could say that python is at it's core functional with OOP layered on top, while ruby is the opposite, it's all sort of irrelevant, they are basically the same, in the fundamental daily experience of using the two languages, in that ruby/python and go (or java, or elixir, whatever) are very much NOT the same. Minus static typing support.
I'm optimistic ruby will figure this out soon, because the sort of static typing support that has propelled javascript and python is the kind that ruby can and should support. By that I mean neither really have static types. Typescript is another language that compiles to javascript, and python's typing support remains and probably always will be optional, and like javascript, is enabled by external tools (mypy, pyright, etc). Neither python nor javascript have a type-centric/aware runtime, or even one in which types are considered at all. They are still both very much dynamic languages that basically have nice developer tooling to help developers write "type-safe" code, but really, in production, we're just pretending that the types we work with in development exist at all in the runtime.
This is not so much a critique of the approach, but the mass pretending we do when we critique a language like ruby for "not having types" and praising javascript or python for "having types" which they clearly do not. But the approach is good, at least if you agree that optional typing is better than java/go style static typing.
I don't know what's holding ruby back from better supporting optional typing, but i hope they fix it soon. My sense is, to over-simplify, sorbet got too popular, but it's fundamentally an approach you would take if you had to build a type system around the language rather than in the language.
Personally I can't wait for the "type hype" to die down. I see the utility of type hints for optimization, but I'm tired of people acting like you can't safely write code without types. Mostly they trot out examples of types guarding against the most trivial errors. You can do just as much within an object oriented message-passing paradigm. Objects ARE types, as far as I'm concerned, with the bonus of also defining operations on those types in a (for lack of a better term) type-specific way. Bolting types on to JavaScript isn't going to make all the warts go away, and forcing them into Ruby wouldn't be transformational (at least I hope not). There's crystal for that sort of thing.
Setting aside performance for the moment, the valid criticisms of languages like Ruby center around the amount of magic that can happen behind the scenes (and what can happen to programmers who use libraries without understanding said magic). Magic isn't intrinsically bad, though. Yes, it can make programming in the large more difficult, but its also a force multiplier that can make it much easier. We shouldn't make programming suck for everyone because there's a shortage of good programmers. We should be figuring out how to make more good programmers-- and that is one thing I think Ruby can definitely help with. It's accessible, and it has support of all kinds of programming paradigms despite being an OO language. You can explore all kinds of things with it. By the time someone has outgrown Ruby, they should be in a good position to understand why and evaluate the tradeoffs of changing horses.
Yea, you're probably right. I meant more stylistically, in that python lets you export functions from files, and it's style of OOP feels way more basic and bolted on than ruby, which gives you lots of different ways to do OOP and throw state around (classes, modules, etc).
Anyone else feeling like discussions like this feel archaic? due to Generative AI?
For all its problems, the presence of AI feels like it should solve some of these quibbles for the vast majority of people who program. I can't quite put my finger on why just yet, though.
No, because pairing with AI is not the same as how we've come to define coding/programming.
It's something different. To say that it'll be _better_ relative to some stated measurement is fine.
Let's use a driving analogy. You can say cars get you from point A to point B so self-driving and teleportation are better evolutions. But you wouldn't say if someone wanted drive a car, enjoyed driving a car, wanted to get better at driving a car, they should get in a Waymo. Or teleport.
Right, but lets keep that analogy going, it's a good one.
One can envision perhaps a future where, e.g. the majority of people (everywhere) don't drive cars because of public transport + Waymos.
In that world, issues surrounding "humans driving" take on a completely different flavor and relevance. Safety matters less, preferences of interfaces can matter more, etc. etc.
And I suppose it feels like the programming equivalent is around the corner, if not already here.
What do you mean? Programming languages all have different strengths and weaknesses that are completely orthogonal to LLMs.
Even if you vibe code an entire system, a human will eventually have to read and modify the vibe code. Most likely in order to refactor the whole thing, but even if by some miracle the overall quality is alright, somebody will have to review the code and fix bugs. The programming language and it's ecosystem will always be a factor in that case.
Yeah, but those perceived strengths and weaknesses I'd say more often than not end up being non-issues i.e. popular chatter about whether a language is good or not and how it is used in real life pretty much never line up.
And my guess is that this "disparity" only widens with AI.
I'm not saying discussions like this aren't theoretically interesting or that people who are into it shouldn't have them. But my guess is they overwhelmingly won't matter large-scale.
That is a naive view to have. Languages have massive differences which directly impact how software is developed, built, distributed, and executed at runtime. Not to mention how it is used and maintained.
And I've yet to see an LLMs have any impact on making any of these differences disappear. The one thing I've seen LLMs do is generate more work for senior developers who have to fix vibe coded spaghetti. There language matters a lot.
No, but as I said elsewhere -- it feels like a possible, perhaps likely, case that "personal preferences in programming and style" become significantly less relevant.
I feel the same. I think the reason is that GenAI has effectively abstracted away the tooling layer. Not perfectly, and not always efficiently, but in terms of going from requirements → workable outcome, it has removed much of the pain of choosing one developer experience over another.
I read this whoel article and I still do not understand what criteria make a programming language serious. Obviously it's very different from Python but I don't understand "serious" or "non-serious" as a way to describe this.
RoR was a breath of fresh air when it was released, things could be done quicker and with much fewer lines of code but nowadays I don't think I would choose to use it again. Other languages has caught up.
A couple of nice projects I can think of are DragonRuby [1] - a 2d engine that uses SDL under the hood and mruby for its game logic. I created this [2] game jam entry in under two weeks of part time effort (has a few bugs but works)
[3] Sonic Pi - Music creation tool that uses ruby for instruction
The article significantly misses the mark by treating Ruby as nothing more than Rails — a perspective that currently detracts from the language. The author clearly hasn't explored the strong features of Ruby 3. Not to mention, it's a very nice language to learn as an entry point into programming.
Ruby is incredibly versatile: NASA has used it for simulation, it's a popular choice for scripting, DevOps automation, and static site generation. It's a simple, dynamic language ideal for quickly prototyping solutions.
Elixir, however, is a separate conversation. Having used it in production for years, I can attest that the ecosystem is fantastic. Its lack of mainstream popularity doesn't matter; its true strength lies in the BEAM, an incredibly well-architected piece of software. Elixir is simply a great way to access that power. Beyond its Ruby-like syntax, it has become its own distinct entity. It used to exist mainly as a alternative to erlang but it's become its own thing in recent years.
I really hate language-based dogma, every virtually every programming language has place as a tool in in a programmer's tool belt. There is even value in learning and using deprecated languages because doing so gives you a perspective beyond whatever ecosystem that you're currently tied to. There is a reason that languages like fortran and lisp have persisted as meaningful choices in certain domains and I suspect that Ruby will stick around for a very long time.
> Culture doesn’t reliably reward the serious. Neither does business.
> It rewards the resonant. The clear. The human. The work that connects.
Enshitification is a very rewarding strategy, depending on which side of it you're on, and I think you'd struggle to argue that's, 'The resonant. The clear. The human. The work that connects.'
The fact of that matter is that business and culture reward a vast range of different approaches in different contexts, and this holds over multiple levels of abstraction. From the sort of staff you want in particular jobs, all the way through to your position as a company relative to the market. Do you want your payroll admin to be playful? Really getting down, feeling that vibe - pay them whatever man - it's all in the vibe dude? Or do you want them to do their job to a standard? Do you want your impression as a company producing finance software to be that you're all about the resonant, the clear, the human, the work that connects? Or do you want it to be that you help the organisation meet its audit burden?
And just as business rewards different things in different contexts - so does programming. I'm not going to do low level systems programming in Ruby. I'm not going to go and do graphics programming in Rust. I'm not going to engage in banging out a CRUD app in C. You choose the best tool for the job given what's reasonably accessible to you at the time the problem occurs. Sometimes it's because a particular language gives you good access and support to a set of libraries - sometimes it's because the code you're working with was already written in that language. Sometimes the features of the language are well suited to particular tasks.
It's not a matter of the tool being serious or not. People are serious or not. Languages are just things and what makes the language serious when you pick it up is whether you're approaching your work seriously or not.
Ruby is a fine language that puts humans over machine.
however the success of rails was also its biggest albatross. Ruby though fine for system tasks (such as system automation etc, chef existed yeah - but we haven't seen new gen tools built after) - people forgot it could do those.
the other is failure of certain sjws to separate say dhh the programmer vs the person. & not being aware to how money (velocity & gravity) move the world e.g shopify involvement in the ruby ecosystem.
failure to understand that beginners are the lifeblood of an ecosystem - till this date don't know if ruby can be effectively used on windows. most people have windows machines not mac's or linux boxes.
it didn't fail cz it was too slow (its fast enough)
I agree with the author that in the era of AI generated code and dev burnout that languages like Ruby will maintain the joy of programming. But programming is increasingly going to become like picking seeds from cotton yourself, instead of using a gin.
Ruby is indeed a cotton pickin good time. I use C# every day and find it the balance between a fun and serious language. But I've always preferred Ruby over Python and all the others outside of my C# bubble. I do love working in C#, to be clear. It's a shame Ruby hasn't been on the rise.
This reads as if it was written with ChatGPT, find-replacing all the em-dashes with elllipses. Nearly every paragraph ends in a "That's not X, that's Y" -type statement.
If this isn't AI slop it's certainly badly written.
I have the strangest feeling that at some point this received a 's/—/...' pass.
That aside, while I'm "old" enough to remember this kind of cultural/vibe-based rivalry between programming language communities, and read enough to know it predates the greyest of living greybeards (TIMTOWTDI vs the Zen of Python, "Real Programmers Don't Write Pascal", "BASIC considered harmful"), I am not sure that this works any more as an argument.
It's a bit tone-deaf to suggest that the difference between Ruby and other communities is that Rubyists are the (only?) ones who care about "how code feels"; that's a pretty core part of the sales pitch for every PL I've ever seen promoted. I am actually nervously awaiting the first big PL that advertises on the basis of "you may not like it, but LLMs love it".
I suspect the real problem is that data science + ML/AI drove (roughly) a bajillion people to Python and LLM training corpus makeup will keep them there. Meanwhile all the Rubyists (ok, I'm being a little inflammatory) that cared about performance or correctness went to Rust (or had already left for Erlang or Haskell or Elm or... whatever). Who's left over there in the dynamic-types-or-bust Ruby world? DHH? (Not an uncontroversial figure these days.)
Back in the olden days, maybe about 20 years ago, two web frameworks were really starting to change the way a lot of people thought about web development. Not the people at the company I worked for, sadly, which is why I went to work for someone else, but there you go.
These were Django, and Ruby on Rails. I already knew Python, and Django was really well-written, and had great documentation, and I could get going with it really quickly. If the docs didn't explain it, I could read the source code. Super.
The place worked at hired a guy who was big into Ruby on Rails, and I really wanted to like it. I liked the stuff the guy was doing, he seemed like a decent sort, and all, and I'm not egotistical enough to go "No we will use my thing" if someone has a perfectly good alternative. Well, okay, I am that egotistical, but not in this case. The point is, I didn't really care which framework we used although I was already able to write Python, because anything was better than the hideous ball of unstructured PHP4 intermingled with HTML that the company's sites were written in at the time.
I really really wanted to like Ruby on Rails, but the documentation kind of assumed you already knew a lot about Ruby and indeed Rails. Okay, let's learn some Ruby.
The IRC channel pointed me at some video tutorials you had to pay for because "that's the future, everyone watches videos to learn stuff now", and why's (Poignant) Guide to Ruby.
I did not like w(P)GtR, at all. I didn't like the "I'm so wackywackywacky" humour on every page. I didn't particularly care about the dog story, which put me off the rest of the whole chapter. I've tried reading it again, maybe about five times since, and I just do not get on with that American Gibberish Poem style of writing.
(I don't much like Alan Ginsberg either, FWIW).
Then the whole Basecamp thing blew up, and DHH was widely known as a total shithead from the motor racing scene so it's not surprising that he turned out to basically be the sort of person my grandfather would have shot if he'd been around in the 1940s.
So, that's kind of why I've never got on with Ruby, much as I'd like to.
Frankly I don't think the article even deserves a response. One of the worst pieces of journalism I've read in a long time, which makes me think it's AI slop.
> Ruby attracts a particular kind of person. Not better. Not smarter. Just… different. People who care how code feels to write and read. People who see programming as a craft that can be expressive. People who understand that most of our careers are spent living inside someone else’s decisions, so joy isn’t a luxury… it’s the only way this work stays humane.
The idea that caring about how your programs feel to write or read is somehow “different” seems weird to me. I don’t write Ruby so maybe I just don’t appreciate this difference.
But I mean, I write fun-to-write, silly little experiments in Octave, Fortran, and Python… I don’t know if anyone would enjoy reading them, but I don’t really see how a language could prevent you from finding joy in programming (other than Java of course /s).
>I don’t really see how a language could prevent you from finding joy in programming
By saddling the writer with tons of syntax and gotchas that is hard to keep at the top of his mind when trying to create.
Languages like c++ and java might be powerful, but there are so many hurdles that are between start and end that unless you are proficient in the language or have a desire to learn the language, it's very tempting to just give up.
Languages like ruby and python are not fast, but their syntax is so straight forward, the effort to go from a to z is a fraction of other languages, leading to the developer to be able to deliver faster.
From the point of view of a developer that loves to learn, simpler languages inspire me to learn more complex languages, which in turn gives me more opportunity to enjoy my chosen craft.
C++ is not that complex, and honestly it's one of the best documented languages out there. The semantics are very clear and you can easily decide to stick to a smaller subset of C++ if you don't like the advanced features like concepts, template metaprogramming, and class hierarchies (I would in general advice against OOP in C++, just as I would in any other language).
Ruby does a lot of magic stuff to help beginners. That means the semantics are unclear. IMO this is similar to how Apple optimizes UI/UX for first impressions to drive sales. The journeyman user is neglected, simple things are easy to do, but the most powerful features are missing for journeyman and advanced users.
I'm not saying Ruby is a bad language. Just saying that I have the opposite view. I too love to learn, but Ruby did not help me learn, it actively got in my way.
You can make a simple language without confusing semantics, see Go, C, python.
C++ is so complex that you can take 10 C++ devs, put them in the same room, and none of them will be able to read any others' code because they've each written it in a mutually exclusive C++ feature set.
Have you written C++? There are no "mutually exclusive" feature sets. The only deprecated language features I can think of are auto pointers and trigraphs, and I have never seen them in the wild.
It doesn't really work as a joke if there's no truth to it.
I understand what mutually exclusive means. There are no two people writing C++ with no overlapping language features. I struggle to understand what you might even mean.
Non-equal subsets of the full language feature set? Yes, that will happen with any nontrivial language.
It is very hard to take a statement like yours seriously when even veteran developers continue to ship software with memory bugs that exfiltrate data and crash systems to this day.
When I said it's not complex I did not mean it's perfect or that it is easy to write flawless code in C++. And obviously C++ is most relevant within its own niche: video games, scientific computing, and performance critical software. The issues you mentioned are tradeoffs that C++ suffers from the higher degree of control a developer has. They're real, and that's a valid point.
What I meant was that if you wish to fully understand how the language works, I bet you that C++ has a clearer path to get there than Ruby does. The documentation and surrounding ecosystem of conference talks, content creators, and longer texts on new features is excellent. Not to mention public online communities like the irc channels on libera.chat.
The original poster I answered to was saying that C++ requires a lot of dedication to understand, but I would say this is true of every language, and C++ is very good at getting you there.
I love Ruby (… contextually, with the most important part of that context being “for small programs”) and its general culture (_why is/was amazing) but hate Rails.
In practice this means I don’t use Ruby professionally any more, because there aren’t a lot of non-Rails Ruby jobs. And since I write a lot of python at work, that’s my go-to for my own quick little personal scripts, too, just for simplicity’s sake as far as what I have to keep in “working memory”, if you will. Plus it’s already installed on most systems I touch, unlike Ruby.
Like I do care about how “joyful” a language is but I also care about how hard it is to work with if a codebase has been through a bunch of contractors’ and agencies’ hands and it’s kind of a mess and the test suite hasn’t been updated during two full years of active development. For my own “joy”’s sake, give me Go or c# or maybe even Java if you must, under those circumstances. It’s unlikely I’ll find much joy in Ruby when that’s happened, which is often.
Well, robbyonrails mentioned that he is an atheist. From my own experience in general, I have found that most people are not atheists. They just replaced God with their ego. In software engineering I have seen so many egos and self-rightousness, I just think I made a mistake of following the craft.
There are major gaps in platforms slapped together in the VC Party / Ruby era that seem to have unresolvable tech debt. Or perhaps Ruby just attracts the types of people who would rather talk about F1 racecars on Twitter than instruct a few of their thousands of employees to fix the shipping calculator.
Ruby was not designed to be a serious language. It was designed to be fun like PHP but not ugly like PHP. Meanwhile PHP grew up and Ruby grew out.
It's okay to love a thing and realize that it has some unsolvable issues and some people around it destined to keep it that way. Most things are like that these days.
The reason people attack Ruby is because Ruby users are vocally conceited, claiming “their language” holds some set of special place, uniquely created for developer joy and developer happiness.
It’s this ridiculous conceit and arrogance that in some way (never quantified mind you), that makes people want to bring the Ruby conceit back to earth.
That’s why Ruby gets attacked - because it’s nothing special but the Ruby lovers club all claim it is.
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.
appreciate you for adding this context
Countless time has passed since then, ruby isn't the same.
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 believe this Elixir based project is influenced somewhat by Rails:
https://hexdocs.pm/phoenix/overview.html
Not tried it, but I came across it whilst updating my knowledge on what was out there that was similar/influenced and/or opinionated like Rails.
Also, off topic re: Elixir, found this for Rust:
https://loco.rs/
I guess it's difficult to justify moving away from tried and tested Rails for a new startup if you know how to spin things up with it already.
> 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?
It's complicated.
The library/framework situation is much better than it used to be. There isn't much that's glaringly missing anymore. Some things have lighter maintenance than one might like, but most stuff is there.
I think Elixir and the BEAM have a weird problem in that it's somewhat hard to understand their benefits until you use them. This is not the case with a lot of other stuff. If you were coming from Java in the 90s and you saw Ruby, you didn't have to use Ruby to realize just how much less code it took to do similar things. You could just see code examples.
If you used Perl back in the day, you didn't have to actually use Python to see how much easier it was to read Python as a novice compared to Perl's eccentricities.
The BEAM is tough to sell because its benefits are not something you can easily see on a screen at a meetup, for example. "What if you had a VM that was designed for the ground up for concurrency" doesn't sell. People respond with "well my language already has threads and promises". "What if your language gave you a builtin toolkit to partition and restart the various different subsystems in a rigorous, well-defined way?" People say, "I already have systemd and it restarts my services."
Having done it for some years now, the BEAM kinda has "the quality without a name"[0]. It feels "whole" in a way that other environments don't, and that's difficult to show. This is not something that shows up trivially on a slide deck or a landing page, and most people don't want to take a gamble on a smaller language community that's seen as different and weird compared to the more mainstream language they already know, especially when the most positive things they hear are "it's a functional language that does concurrency better". For most people, this just isn't a compelling enough pitch to get them to leave Python or Javascript or Java (or Ruby).
By the way, I'm not blaming folks, this is both a rational and normal way of evaluating risk when faced with an unintelligible upside and an immediately apparent downside (small community, uncertain career prospects, questionable library coverage, etc.). I think as a community, we (Elixir) have done a poor job in making Elixir seem less risky.
> 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.
IMHO Python won the war. Ruby won server-side webapps battle with Rails, which is still going strong, but Python won literally everything else by a landslide. And Python still even has Django. Python is _everywhere_. There's no stats on this that I know of, but I bet 90%+ of Ruby usage is Rails. This is not the case with Python.
To be clear, this is all in the context of adoption. Ruby may never have Python's adoption, but Ruby has been hugely influential. Tons of other technology can trace its lineage to Ruby, whether it's Elixir as a language, or Rust's tooling (Cargo), etc.
> 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?
Rails still has a large amount of inertia, both technically and culturally. It's still very good at its niche. Getting Rails folks to move away from Rails would take something as better as Rails was than the Java stuff that came before it. Plus, some people just love Ruby! Elixir isn't Ruby. Elixir is more explicit, doesn't have mutability, doesn't have objects, etc. The similarity really ends at syntax, and I think a lot of Ruby folks are happy with what Ruby is, which is totally fine.
Sorry for the long answer.
[0] - https://onluminousgrounds.wordpress.com/2010/04/24/the-quali...
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.
[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)
ruby comes preinstalled on macos. so if you want to script a mac without installers or non oob software, it’s that or perl or bash or appkescript.
Pretty sure theyentioned that it will be removed soon
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.
> I think those are two separate concerns.
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.
> For example, I'm happy to maintain Python codebases with type annotations and type checking enabled.
"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.
They're becoming the norm for newer systems written in Python though. So I don't think the language is enough information to go on. This heuristic simply biases against languages that have been around a long time because more of their code was written before practices evolved.
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.
Why COBOL?
COBOL is used for the longest continuously running systems, particularly in the financial industry, many of which have been in production since the 1960s - mainly on mainframes, but noawadays also increasingly in cloud environments. There's nothing that comes close to the level of reliability that these offer, with the next closest probably being Fortran, Ada and Erlang.
I found this article with some numbers [0], with the top one being that "95% of ATM swipes rely on COBOL code". If you just need to maintain something in production, and only occasionally update the business logic, without having to upgrade the architecture, COBOL is the way to go.
[0] https://www.pragmaticcoders.com/resources/legacy-code-stats
I think the correlation here is pretty solid but I wonder about the causality. There are a few big confounding variables; off the top of my head,
1. COBOL systems are typically written on a much shallower software stack with less room for unreliability
2. banking systems have a ton of effort put into reliability over decades of development.
My old boss wrote COBOL code for a core finance process… in 1975, well before I was born. He retired in 2019, and that code is still there with a few mods and probably will remain for another decade.
In fairness, it’s pretty fundamental stuff. But… the company has been working on moving to some Oracle bs for 5-6 years.
As long as I’ve written the system, any language is fine. Otherwise, hand it down to someone else!
/s but also true
Yes, this exactly. I like to write code in Forth but I sure as FUCK don't want it to be my day job.
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].
[1] https://survey.stackoverflow.co/2024/technology#most-popular...
> "Ruby doesn't work forever"
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...
Here's some places I noticed it:
> 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.
GitHub is an example of something that worked better with ruby than react...it got much worse.
It also may have had a better time with more recent versions of Ruby.
> 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...>
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?
That’s how the interpreter in JavaScriptCore gets compiled. The interpreter is written in a macro assembly dialect I invented and this is the compiler for it.
(I say compiled, not assembled, because it’s higher level than normal assembly. There’s an actual pipeline of transformations that happens. Plus a Turing complete macro language)
Thanks, that's helpful. (I mistook the compiler as being one that deals with JSC bytecode, either as input or output.)
It's also funny he wisecracks Java and then loves Scala for it's robustness (much of which it owes to Java).
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.
Very similar story here.
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 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.
[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...
> 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 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
This article feels like someone is defending their language. And that doesn’t bother me, but I don’t value that.
I don’t care about what’s popular or what feels most familiar. What I want is a dispassionate discussion of how different language features impact code quality, and I think you can only find that in more abstract discussions. The kind that turns people off with its talk of monads and applicatives.
> What I want is a dispassionate discussion of how different language features impact code quality
This can be difficult because code quality, productivity, safety are hard to objectively define and measure, so we always fall back to differences in interpretation and experience.
I would be interested in serious attempts to argue for this, even if they can't reasonably be backed up by data.
For example, I think there's a pretty strong argument that immutability makes it easier to write multithreaded code (perhaps at some performance cost), because it entirely prevents common types of bugs.
Similarly there's a good argument that making methods open to extension (like Kotlin or Julia) makes it easier for an ecosystem to adopt unified APIs without explicit coordination.
There's obviously a very strong argument that Garbage Collection prevents a lot of memory safety bugs, at costs to interoperability and performance.
> dispassionate discussion of how different language features impact code quality
I think we can start disagreeing here.
The metrics shouldn't be solely code quality, but also simplicity, readability, and how fast you can express yourself in it.
Code quality will go up the more language friction you add: types, "one way" of doing things, and function-oriented programming. Same code in a language with heavy types and strict functions will be of course "more solid". However, it will take 10x the time to write, be less flexible, and harder to understand.
> However, it will take 10x the time to write, be less flexible, and harder to understand.
Not in my experience: only in the usual ramp-up period in the first few months.
Do you know of any articles/papers that try to do in-depth analyses of which features are helpful for building big systems?
Most posts I can think of basically say "X language is good" or "Y language is bad", but I'd really be interested in arguments like "feature A is better at accomplishing goal Z than feature B"
That's a very good point. My experience is that for large project the architecture also becomes important.
Large project have much code but if you can split out responsibility because your architecture allows this, then you keep your code concise.
One feature Ruby has that helps here is creating Domain Specific Language without yacc or lex. This allows for concise code where its needed.
Not quite the same, but I find "data-oriented programming" to be a very strong method for managing large codebases. By that I mean having data structures that designate the end state that you want, having another set of code that gets you to those end states, and maintaining a pretty clear boundary between the two.
(If you like with "Functional Core, Imperative Shell", this is a way to further divide the Functional Core.)
It works well because it narrows the surface area of a lot of possible bugs: either your configuration is wrong, or your code doing the transformations is wrong.
You kind of describe flow based programming (FBP) whereby data is passed to stateless functionality.
Things like Unix pipes, Node-Red and n8n are inspired by FBP.
I agree with what you describe, also reuse is simpler because code tends to be stateless.
There are languages much better suited for DSLs though.
There are some programming language journals that people like to dismiss as “academic”. But “academic” is what I value here.
There are a lot of programming language journals – are there ones you'd recommend specifically for discussions of tradeoffs between features?
You're looking for a copy of Eloquent Ruby: http://eloquentruby.com/
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.
I indeed really liked Ruby because of it's expresiveness, it being totally OO, the lovely readable and writeable syntax.
But yeah, that was 20 years ago. These days I find Kotlin to be the perfect fit for my projects, because of the static typing and its ergonomic syntax. I just don't feel confident about Ruby projects when they start growing. But, I still love the language, although mostly for small things.
Yeah. I was pretty neutral on ruby, until somewhere I worked some coworker put an @ on a variable relating to sessions and suddenly people started seeing each other's accounts.
Now some people won't fault the language for that, but it feels like a footgun and I've noticed a trend that often the worst (I.e. most dangerous) gravitate toward languages with the fewest safeties in them (less type safety, no compile checks, no memory safety, little concurrency safety, less safety around shared state)
Why do you think this is worse than someone saying about Java: "some coworker put `this.` on a variable relating to sessions and suddenly people started seeing each other's accounts"? Because it's less obvious what "@" means rather than "this."?
Edit: I forgot that Java has implicit `this`! That's so, so much worse!
This can happen it every language. I have seen the same thing happen in a project written in Java when someone has wrongly set the bean scope.
I'm pretty sure you mean @@ on a variable and are not common in a Ruby project. @@ is a class variable and I can see that causing all sorts of problems with data across sessions.
I have been using Ruby for 13 years and only once have I seen anybody use an @ on a variable…and it was part of a distributed caching strategy for an ad randomizer.
How about the fact that Ruby makes immutability difficult, and Hash does not copy keys on write and read? Almost every program uses a hash table, and Ruby makes them especially dangerous.
At least we have new features for immutability as part of Ractors.
e.g. Ractor.make_shareable(data)
Not totally though. Try `if.class` in IRB for example.
But the closest we have in any popular programming language, certainly.
As a Python enthusiast for 20 years, just ignore and enjoy.
Ruby is a joy to program in. I started exploring it after using Haskell and Smalltalk and was pleasantly surprised when the language would do things like both of them.
fwiw As someone without Ruby programming skills, my experience was that it does unpredictable "magic" things, which I did not find helpful when writing mundane code. fwiw
Was it in a Rails app? I'm not sure what magical things standard lib Ruby would do but Rails does a lot.
If people want to know the main reasons why Ruby or by extension RoR, is popular, please check this excellent article by the author of a non-popular programming language Stanza [1].
From the cited article [1]:
"Casual website designers can safely completely ignore the concepts of types and memory deallocation because Ruby is dynamically-typed and garbage-collected. These features are simply not available in all other languages. Java's meta-programming features, for example, are just not powerful enough to implement a system like ActiveRecords. Rails is only possible because of Ruby."
But I'd argue that you can still have types and still have a very powerful meta-programming features and abilities of compiled language for example D to implement a system like ActiveRecords [2].
[1] Stop Designing Languages. Write Libraries Instead:
https://lbstanza.org/purpose_of_programming_languages.html
[2] D Language: Features Overview:
https://dlang.org/comparison.html
So glad someone already spoke up about this -- I love Wired, and I think that piece is really poor (not because I love Ruby or think it's without fault, but because the argument it makes is essentially "it's not Ruby or Python, which have static typing tools.")
That Wired article might as well have been a GPT summary of the shit people have been saying about Ruby for two decades.
It is beyond stupid to continue to act like "it doesn't scale" is a real argument. Not every application is or will ever be Twitter.
Author has a history of bad-mouthing programming languages, that seems to be his meme: https://www.wired.com/author/sheon-han/
I enjoyed ruby as a language for a while, but the one truly maddening aspect of it is that (as of 10 years ago anyway) nobody actually wrote threadsafe gems (because everyone was writing for Rails, which was single-threaded). That and the rampant monkeypatching that made the standard library hard to count on. These are the things that make it feel really "unserious" to me. I have no idea if these complaints are still current, though. I assume thread safety has been tackled at the very least.
> rampant monkeypatching that made the standard library hard to count on
That was very frustrating when doing regular development after using Rails, all the "built-ins" were actually patched into the stdlib by Rails and not available without it.
> one truly maddening aspect of it is that (as of 10 years ago anyway)
Not really true anymore.
> for Rails, which was single-threaded
Also not true anymore.
Turns out things can change in 10 years, I guess?
Ruby is one of the most fun programming languages out of the 6+ languages I've worked with, and I was very productive with it. Unfortunately, due to my experience working at a Ruby shop where Rails misuse and abuse crippled the company, I don't enjoy using Ruby anymore, and will never recommend using Rails for production-grade software. Hopefully you've had a better experience with Ruby and still enjoy writing beautiful software with it - hopefully not with Rails.
It's one thing for J.K. Rowling to write Harry Potter outlines on cocktail napkins. A pen and a cocktail napkin can be quite the foundation for expression, indeed. But the same flexibility lets other people doodle, and still others blow their nose.
The capacity to enable greatness is neither the same as the encouragement to enable greatness, nor the guarantee to enable greatness, and there's a lot of survivor's bias at the top of the Ruby and Rails communities.
I had a similar experience.
I love Ruby but too many companies assume I said Rails. I would also never recommend Rails for anything.
Instead I’d use Sinatra and Ruby any day.
This is exactly what I've done. I don't enjoy Rails very much but I love working with Ruby and Sinatra. The community has done a great job to keep Rails separated from Ruby when they release tools, so that they don't depend on or require Rails.
A lot of the aversion towards ruby I've gotten from people that have worked with it before mainly stems from complaints I share with the philosophy of Rails (making big changes to it when needed is like driving a freight ship instead of a small boat) and the complexity that can go with that, or with horror stories around poorly implemented metaprogramming, which are both valid points to me because I honestly share them. But Rails is not Ruby, and the community in general has been a lot more responsible with using metaprogramming carefully than it was in the early days.
Ruby becoming successful through Rails was a boon for it in the short term but I think also detracted from it's future growth at the same time as it became hard to untether developers' bad experiences with huge Rails apps with their experience using Ruby itself.
Personally, I love using Ruby so much for my own needs that if it ever was to fall into obscurity to the point of being unusable for modern tasks, I have decided that will be the point that I probably retire from programming and move on to other things in my life. It's not that I can't learn a new language for my daily driving, it's that I... don't really want to at this point.
If you want to keep the syntax of Ruby but try a new language, then I would suggest having a look at Elixir.
It’s a completely different paradigm having been built on the ideas of Erlang with the syntax of Ruby.
The language I thought was pretty cool and similar was Crystal, but I've never run into the use case to try it, because I've never had something I couldn't handle with Ruby itself. Performance in my world is rarely a bottleneck, and I would not want to build a very large web app with a lot of complex business logic with it.
Ruby’s biggest flaw is that it insists humans matter. Some people hate that.
This take is almost as condescending as saying that Ruby isn't a serious language.
Ruby arose and became popular because it caters to a niche that was underserved by the competitors of the time (and while I'm no historian, I think Rails had a big role to play in Ruby's popularity).
Ruby is very ergonomic, and so is Rails. Frankly, almost 10 years after moving on from it, ActiveRecord is the yardstick by which I measure the ergonomics of all other ORMs in other languages, but what ergonomic means will vary from domain to domain.
With languages like Ruby and Python, it's very easy to get from nothing to an app that will work generally well enough almost straight away. A lightweight syntax, a lot of implicit functionality, and a flexible type system are all great for that, but in my current niche, I couldn't use it (I currently work with Rust, and the explicit control is a huge selling point, despite the much heavier syntax and more complicated semantics). That doesn't mean Rust was built without the human experience of using it in mind, though, and arguably the opposite's true.
If by that you mean prioritising the coder's experience (ergonomics) I usually feel better as a human when I’m not bitten by some magical effect.
It is a joy to write Ruby, I’ll give you that, but it is a pain to live around other people’s Ruby at scale.
As opposed to what?
At the time, Java. J2EE (entity beans and session beans), Java Server Pages, Apache Struts. I think it's hard for people who didn't live through it to appreciate just how painful it was to work in that stack circa 1999-2003, like it just doesn't seem plausible that the whole industry would go along with a stack with that much boilerplate for that little added value.
Back then, Ruby and Rails opened a lot of people's minds to the idea that we were allowed to make "delightful" a consideration in API design, not just S.O.L.I.D. or whatever. These days, there are way more mainstream languages, frameworks, and communities that take humane APIs seriously.
Putting aside the fact that this is about ruby vs other languages, not rails vs other frameworks, I cannot help but feel like ruby optimizes for fitting code onto slide decks rather than other human concerns (like, unambiguous communication of semantics at a glance).
I certainly have written a great deal of ruby and have no strong opinions about the language aside from "I will shoot the next person who uses method_missing", but I find the people who do have strong attraction to the language endlessly fascinating. By far, the most human aspect of the language is the community built around it.
A.I. obviously.
[dead]
As someone who doesn't know ruby i have literally no idea what you mean by this
Ruby tries to make things close to natural language.
> it insists humans matter.
Uh how?
Programmers are humans, while the end users whose resource the former are wasting are not. Obviously.
Uh read this and try using it. https://www.ruby-lang.org/en/about/
The Semantics and Philosophy section of the Ruby page on Wikipedia gives a good overview:
https://en.wikipedia.org/wiki/Ruby_(programming_language)#Se...
This really resonated with the way I feel about Ruby. I haven't had the opportunity to seriously write Ruby in years, but I measure every development environment against the classic ruby/rails/rake/gem/bundler experience and I always find myself missing how productive Ruby was to work with, inside and outside of Rails. I think Ruby particularly excels in its ability to mold itself structurally to match its problem domain. Rspec and ActiveRecord and to a lesser extent Bundler and Rake are still the most ergonomic versions of tools in their class that I have used to date, and they all expose some sort of powerful DSL that feels magical in just the right way.
These days I mostly use more "serious" languages (python, Java, C#, C++), but it's because I want to work on a domain within those languages and I don't have the time to commit to bringing the domain to Ruby. I should call her...
From the article OP is responding to:
> Critically, Ruby’s performance profile consistently ranks near the bottom (read: slowest) among major languages.
Without a cite, perhaps because it's not really true. Ruby's performance is similar to python's. Granted, neither one is going to win any competitions, although I'm not sure what the field of "major languages" is.
> Ruby's performance is similar to python's. Granted, neither one is going to win any competitions...
It's not just that they won't win any speed competitions, but that Ruby and Python are bound to come in last place. The only question is, which one comes in last and which 2nd to last. Runners up include Perl, PHP, and sometimes non-JIT Lua. Choose any benchmark, the results are consistent: https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
Choose any benchmark and line-by-line transliterate the programs to really make that point:
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
The point is that if anyone could submit a faster implementation by now they would have. The posted numbers are as good as it gets.
That's purely speculation.
There are many good comments here about why the "Ruby is not a serious programming language" article is trash, and it is. What bothers me is that this article is on wired.com. I would expect more from Wired, and unfortunately, the article will get many views.
> I’ve never seen a team fail because they chose Ruby. I have seen them fail because they chose complexity. Because they chose indecision. Because they chose “seriousness” over momentum. Ruby just needed to stay out of the way so people could focus on the real work.
I am entirely indifferent to the topic of Ruby, but this sentence really resonated with me. I'll take momentum over premature optimization for scale any day of the week.
My response is a lot more terse: none of the complaints in the article actually impact usability, if it was actually less useful than other languages people wouldn't be using it. I wish Shopify was the primary example, because its the exact kind of high scale, data-rich kind of apps that Wired alleges to be near impossible.
As someone that is slowly being dragged into agents, and AI powered tooling, I am start to see language wars even more worthless than they used to be.
Manual memory versus GC, JIT, AOT, interpreted, begin/end or curly brackets, unsafe or not, whatever.
We will be slowly moving into some kind specifications for autonomous systems (please not YAML based), up to a point, and language wars will become a moot point, only relevant to the selected few implementing the low level parts of how everything comes together.
My only complaints about Ruby, as someone that never really did much with it, would be a more Smalltalk like dev experience (not sure how RubyMine fares), given its influences, and a proper JIT in the box (which is happening).
Seriously, I think it is a petty mistake to characterize Ruby as unserious. I am not drawn to the language myself, and my previous interest in it waned after debugging dependency rot in a cloud deployed Rails app more than 10 years ago. However, to label it as unserious would be nearly as unserious as labelling python unserious.
A nicely done article by Robby, given that arguing definitions is too often a thankless waste of time. Some selections from [1] ...
> Arguing about definitions is a garden path; people wouldn’t go down the path if they saw at the outset where it led.
See [1] for some tips on moving past the fruitless arguments:
> Personally I’d say that if the issue arises, both sides should switch to describing the event in unambiguous lower-level constituents ...
> ... Or each side could designate a new word, like ‘alberzle’ and ‘bargulum,’
> ... and then both sides could use the new words consistently. That way neither side has to back down or lose face, but they can still communicate.
> And of course you should try to keep track, at all times, of some testable proposition that the argument is actually about.
> Does that sound right to you?
[1]: https://www.readthesequences.com/Disputing-Definitions
The Wired article was pure bait and it worked. At least we are talking about Ruby <3
If Ruby pays your bills, then I think calling it a not serious language is a bit of a stretch. Just look at Mike Perham's Sidekiq - he made a living out of selling a RubyGem.
Let's be honest, if it weren't for Rails Ruby would be forgotten nowadays.
Right now Ruby is a language used to maintain legacy Rails systems.
The majority of the world's Ruby programmers are in Japan, where it's used for a whole lot more than building Rails apps. So Ruby isn't going anywhere, although it may become a curiosity in the West over time.
I wish there would be a language like Ruby but strong type or statically typed.
I like its rich standard library style and encapsulation style (e.g. .map with lambda).
I've moved to Scala purely because Ruby is not typed. In a large codebase, it becomes really difficult to refactor. Even renaming stuff is convoluted.
wondering why https://crystal-lang.org/ hasn't been mentioned in the comments
Ruby is strongly typed
> Culture doesn’t reliably reward the serious. Neither does business. It rewards the resonant. The clear. The human. The work that connects.
Culture maybe, but business rewards what make business going on. Only that and Ruby proved that it can make businesses start and keep them going on. The few ones that exceed the capabilities of the runtime had to pivot to something else, in part or completely, but would we had a Twitter if they started coding in pick-your-favorite-serious-language? Maybe a competitor would have overrun them. We'll never know.
What I know for sure is that Ruby has been paying my bills for nearly 20 years. That's more than any other language I used, serious or not serious. It worked for me.
I'm certain the users of the ruby app don't care how "serious" your programming language is.
Do the user of _any_ language care how serious the language is?.. nowdays there are so many options to pick from, I love Ruby, I use it all the time, but I also like Python, Elixir and system languages like C++..
no they don't thats my point ;) use what works for you, everything else is just noise.
The original wired piece is effectively a lot of words that swirl around one poorly argued point: ruby is falling behind because of it's lack of static typing support. "Seriousness" is an ironically unserious way to evaluate, well, anything, but if you were trying to force a definition based on the rest of the poorly formed narrative, it must be "static typing". Performance doesn't work as serious critique, because...python, and it probably shouldn't anyway (within some semi-reasonable range).
Except for static typing and ruby's particular style of metaprogramming (one could argue python enables decorator-based "meta" programming, but whatever), ruby and python are basically the same language, with some obvious semantic differences. Of course there is much about ruby and python that is very different -- adoption, library support, community, vibe, whatever. And you could say that python is at it's core functional with OOP layered on top, while ruby is the opposite, it's all sort of irrelevant, they are basically the same, in the fundamental daily experience of using the two languages, in that ruby/python and go (or java, or elixir, whatever) are very much NOT the same. Minus static typing support.
I'm optimistic ruby will figure this out soon, because the sort of static typing support that has propelled javascript and python is the kind that ruby can and should support. By that I mean neither really have static types. Typescript is another language that compiles to javascript, and python's typing support remains and probably always will be optional, and like javascript, is enabled by external tools (mypy, pyright, etc). Neither python nor javascript have a type-centric/aware runtime, or even one in which types are considered at all. They are still both very much dynamic languages that basically have nice developer tooling to help developers write "type-safe" code, but really, in production, we're just pretending that the types we work with in development exist at all in the runtime.
This is not so much a critique of the approach, but the mass pretending we do when we critique a language like ruby for "not having types" and praising javascript or python for "having types" which they clearly do not. But the approach is good, at least if you agree that optional typing is better than java/go style static typing.
I don't know what's holding ruby back from better supporting optional typing, but i hope they fix it soon. My sense is, to over-simplify, sorbet got too popular, but it's fundamentally an approach you would take if you had to build a type system around the language rather than in the language.
Personally I can't wait for the "type hype" to die down. I see the utility of type hints for optimization, but I'm tired of people acting like you can't safely write code without types. Mostly they trot out examples of types guarding against the most trivial errors. You can do just as much within an object oriented message-passing paradigm. Objects ARE types, as far as I'm concerned, with the bonus of also defining operations on those types in a (for lack of a better term) type-specific way. Bolting types on to JavaScript isn't going to make all the warts go away, and forcing them into Ruby wouldn't be transformational (at least I hope not). There's crystal for that sort of thing.
Setting aside performance for the moment, the valid criticisms of languages like Ruby center around the amount of magic that can happen behind the scenes (and what can happen to programmers who use libraries without understanding said magic). Magic isn't intrinsically bad, though. Yes, it can make programming in the large more difficult, but its also a force multiplier that can make it much easier. We shouldn't make programming suck for everyone because there's a shortage of good programmers. We should be figuring out how to make more good programmers-- and that is one thing I think Ruby can definitely help with. It's accessible, and it has support of all kinds of programming paradigms despite being an OO language. You can explore all kinds of things with it. By the time someone has outgrown Ruby, they should be in a good position to understand why and evaluate the tradeoffs of changing horses.
> And you could say that python is at it's core functional with OOP layered on top
How would you argue that? I don't think a language can be considered core functional if it doesn't at least support pure functions.
Yea, you're probably right. I meant more stylistically, in that python lets you export functions from files, and it's style of OOP feels way more basic and bolted on than ruby, which gives you lots of different ways to do OOP and throw state around (classes, modules, etc).
Anyone else feeling like discussions like this feel archaic? due to Generative AI?
For all its problems, the presence of AI feels like it should solve some of these quibbles for the vast majority of people who program. I can't quite put my finger on why just yet, though.
No, because pairing with AI is not the same as how we've come to define coding/programming.
It's something different. To say that it'll be _better_ relative to some stated measurement is fine.
Let's use a driving analogy. You can say cars get you from point A to point B so self-driving and teleportation are better evolutions. But you wouldn't say if someone wanted drive a car, enjoyed driving a car, wanted to get better at driving a car, they should get in a Waymo. Or teleport.
Right, but lets keep that analogy going, it's a good one.
One can envision perhaps a future where, e.g. the majority of people (everywhere) don't drive cars because of public transport + Waymos.
In that world, issues surrounding "humans driving" take on a completely different flavor and relevance. Safety matters less, preferences of interfaces can matter more, etc. etc.
And I suppose it feels like the programming equivalent is around the corner, if not already here.
What do you mean? Programming languages all have different strengths and weaknesses that are completely orthogonal to LLMs.
Even if you vibe code an entire system, a human will eventually have to read and modify the vibe code. Most likely in order to refactor the whole thing, but even if by some miracle the overall quality is alright, somebody will have to review the code and fix bugs. The programming language and it's ecosystem will always be a factor in that case.
Yeah, but those perceived strengths and weaknesses I'd say more often than not end up being non-issues i.e. popular chatter about whether a language is good or not and how it is used in real life pretty much never line up.
And my guess is that this "disparity" only widens with AI.
I'm not saying discussions like this aren't theoretically interesting or that people who are into it shouldn't have them. But my guess is they overwhelmingly won't matter large-scale.
That is a naive view to have. Languages have massive differences which directly impact how software is developed, built, distributed, and executed at runtime. Not to mention how it is used and maintained.
And I've yet to see an LLMs have any impact on making any of these differences disappear. The one thing I've seen LLMs do is generate more work for senior developers who have to fix vibe coded spaghetti. There language matters a lot.
I don't understand what this comment means. It sounds like you think all programming has ended, which is not the case.
No, but as I said elsewhere -- it feels like a possible, perhaps likely, case that "personal preferences in programming and style" become significantly less relevant.
I feel the same. I think the reason is that GenAI has effectively abstracted away the tooling layer. Not perfectly, and not always efficiently, but in terms of going from requirements → workable outcome, it has removed much of the pain of choosing one developer experience over another.
these articles feel like they were WRITTEN by gen AI, I'll say that!
> if a tool feels good to use… that must mean it isn’t “serious.”
Good structure. Always put the strawman up front.
Stay tuned for my article about soda pop which starts: "I missed the memo that said that just because something tastes great it's 'unhealthy.'"
I read this whoel article and I still do not understand what criteria make a programming language serious. Obviously it's very different from Python but I don't understand "serious" or "non-serious" as a way to describe this.
RoR was a breath of fresh air when it was released, things could be done quicker and with much fewer lines of code but nowadays I don't think I would choose to use it again. Other languages has caught up.
RoR isn’t Ruby.
The mistake that most folks make. They start out using RoR and think that’s Ruby.
That’s probably why Ruby will always remain a “web” language and won’t be taken _seriously_ in other areas.
I haven't seen it being used for anything else with the exception of some devops tools like chef.
A couple of nice projects I can think of are DragonRuby [1] - a 2d engine that uses SDL under the hood and mruby for its game logic. I created this [2] game jam entry in under two weeks of part time effort (has a few bugs but works)
[3] Sonic Pi - Music creation tool that uses ruby for instruction
[1]: https://dragonruby.org/
[2]: https://itch.io/jam/linux-game-jam2023/rate/2101760
[3]: https://sonic-pi.net/
Homebrew would be another.
The article significantly misses the mark by treating Ruby as nothing more than Rails — a perspective that currently detracts from the language. The author clearly hasn't explored the strong features of Ruby 3. Not to mention, it's a very nice language to learn as an entry point into programming.
Ruby is incredibly versatile: NASA has used it for simulation, it's a popular choice for scripting, DevOps automation, and static site generation. It's a simple, dynamic language ideal for quickly prototyping solutions.
Elixir, however, is a separate conversation. Having used it in production for years, I can attest that the ecosystem is fantastic. Its lack of mainstream popularity doesn't matter; its true strength lies in the BEAM, an incredibly well-architected piece of software. Elixir is simply a great way to access that power. Beyond its Ruby-like syntax, it has become its own distinct entity. It used to exist mainly as a alternative to erlang but it's become its own thing in recent years.
I really hate language-based dogma, every virtually every programming language has place as a tool in in a programmer's tool belt. There is even value in learning and using deprecated languages because doing so gives you a perspective beyond whatever ecosystem that you're currently tied to. There is a reason that languages like fortran and lisp have persisted as meaningful choices in certain domains and I suspect that Ruby will stick around for a very long time.
Ruby is a tool, it’s fine. I don’t buy into all the emotional nonsense about it. Seems more like creative marketing.
> Culture doesn’t reliably reward the serious. Neither does business. > It rewards the resonant. The clear. The human. The work that connects.
Enshitification is a very rewarding strategy, depending on which side of it you're on, and I think you'd struggle to argue that's, 'The resonant. The clear. The human. The work that connects.'
The fact of that matter is that business and culture reward a vast range of different approaches in different contexts, and this holds over multiple levels of abstraction. From the sort of staff you want in particular jobs, all the way through to your position as a company relative to the market. Do you want your payroll admin to be playful? Really getting down, feeling that vibe - pay them whatever man - it's all in the vibe dude? Or do you want them to do their job to a standard? Do you want your impression as a company producing finance software to be that you're all about the resonant, the clear, the human, the work that connects? Or do you want it to be that you help the organisation meet its audit burden?
And just as business rewards different things in different contexts - so does programming. I'm not going to do low level systems programming in Ruby. I'm not going to go and do graphics programming in Rust. I'm not going to engage in banging out a CRUD app in C. You choose the best tool for the job given what's reasonably accessible to you at the time the problem occurs. Sometimes it's because a particular language gives you good access and support to a set of libraries - sometimes it's because the code you're working with was already written in that language. Sometimes the features of the language are well suited to particular tasks.
It's not a matter of the tool being serious or not. People are serious or not. Languages are just things and what makes the language serious when you pick it up is whether you're approaching your work seriously or not.
Ruby is a fine language that puts humans over machine.
however the success of rails was also its biggest albatross. Ruby though fine for system tasks (such as system automation etc, chef existed yeah - but we haven't seen new gen tools built after) - people forgot it could do those.
the other is failure of certain sjws to separate say dhh the programmer vs the person. & not being aware to how money (velocity & gravity) move the world e.g shopify involvement in the ruby ecosystem.
failure to understand that beginners are the lifeblood of an ecosystem - till this date don't know if ruby can be effectively used on windows. most people have windows machines not mac's or linux boxes.
it didn't fail cz it was too slow (its fast enough)
> failure to understand that beginners are the lifeblood of an ecosystem - till this date don't know if ruby can be effectively used on windows.
Nor does it include something like Python's IDLE out of the box in the standard install.
I agree with the author that in the era of AI generated code and dev burnout that languages like Ruby will maintain the joy of programming. But programming is increasingly going to become like picking seeds from cotton yourself, instead of using a gin.
Ruby is indeed a cotton pickin good time. I use C# every day and find it the balance between a fun and serious language. But I've always preferred Ruby over Python and all the others outside of my C# bubble. I do love working in C#, to be clear. It's a shame Ruby hasn't been on the rise.
Ruby is a little silly, but given its pedigree of generational internet projects, Rails is indisputably a serious framework.
This reads as if it was written with ChatGPT, find-replacing all the em-dashes with elllipses. Nearly every paragraph ends in a "That's not X, that's Y" -type statement.
If this isn't AI slop it's certainly badly written.
It’s as serious as you want/need it to be.
I have the strangest feeling that at some point this received a 's/—/...' pass.
That aside, while I'm "old" enough to remember this kind of cultural/vibe-based rivalry between programming language communities, and read enough to know it predates the greyest of living greybeards (TIMTOWTDI vs the Zen of Python, "Real Programmers Don't Write Pascal", "BASIC considered harmful"), I am not sure that this works any more as an argument.
It's a bit tone-deaf to suggest that the difference between Ruby and other communities is that Rubyists are the (only?) ones who care about "how code feels"; that's a pretty core part of the sales pitch for every PL I've ever seen promoted. I am actually nervously awaiting the first big PL that advertises on the basis of "you may not like it, but LLMs love it".
I suspect the real problem is that data science + ML/AI drove (roughly) a bajillion people to Python and LLM training corpus makeup will keep them there. Meanwhile all the Rubyists (ok, I'm being a little inflammatory) that cared about performance or correctness went to Rust (or had already left for Erlang or Haskell or Elm or... whatever). Who's left over there in the dynamic-types-or-bust Ruby world? DHH? (Not an uncontroversial figure these days.)
Back in the olden days, maybe about 20 years ago, two web frameworks were really starting to change the way a lot of people thought about web development. Not the people at the company I worked for, sadly, which is why I went to work for someone else, but there you go.
These were Django, and Ruby on Rails. I already knew Python, and Django was really well-written, and had great documentation, and I could get going with it really quickly. If the docs didn't explain it, I could read the source code. Super.
The place worked at hired a guy who was big into Ruby on Rails, and I really wanted to like it. I liked the stuff the guy was doing, he seemed like a decent sort, and all, and I'm not egotistical enough to go "No we will use my thing" if someone has a perfectly good alternative. Well, okay, I am that egotistical, but not in this case. The point is, I didn't really care which framework we used although I was already able to write Python, because anything was better than the hideous ball of unstructured PHP4 intermingled with HTML that the company's sites were written in at the time.
I really really wanted to like Ruby on Rails, but the documentation kind of assumed you already knew a lot about Ruby and indeed Rails. Okay, let's learn some Ruby.
The IRC channel pointed me at some video tutorials you had to pay for because "that's the future, everyone watches videos to learn stuff now", and why's (Poignant) Guide to Ruby.
I did not like w(P)GtR, at all. I didn't like the "I'm so wackywackywacky" humour on every page. I didn't particularly care about the dog story, which put me off the rest of the whole chapter. I've tried reading it again, maybe about five times since, and I just do not get on with that American Gibberish Poem style of writing.
(I don't much like Alan Ginsberg either, FWIW).
Then the whole Basecamp thing blew up, and DHH was widely known as a total shithead from the motor racing scene so it's not surprising that he turned out to basically be the sort of person my grandfather would have shot if he'd been around in the 1940s.
So, that's kind of why I've never got on with Ruby, much as I'd like to.
Frankly I don't think the article even deserves a response. One of the worst pieces of journalism I've read in a long time, which makes me think it's AI slop.
> Ruby attracts a particular kind of person. Not better. Not smarter. Just… different. People who care how code feels to write and read. People who see programming as a craft that can be expressive. People who understand that most of our careers are spent living inside someone else’s decisions, so joy isn’t a luxury… it’s the only way this work stays humane.
The idea that caring about how your programs feel to write or read is somehow “different” seems weird to me. I don’t write Ruby so maybe I just don’t appreciate this difference.
But I mean, I write fun-to-write, silly little experiments in Octave, Fortran, and Python… I don’t know if anyone would enjoy reading them, but I don’t really see how a language could prevent you from finding joy in programming (other than Java of course /s).
>I don’t really see how a language could prevent you from finding joy in programming
By saddling the writer with tons of syntax and gotchas that is hard to keep at the top of his mind when trying to create.
Languages like c++ and java might be powerful, but there are so many hurdles that are between start and end that unless you are proficient in the language or have a desire to learn the language, it's very tempting to just give up.
Languages like ruby and python are not fast, but their syntax is so straight forward, the effort to go from a to z is a fraction of other languages, leading to the developer to be able to deliver faster.
From the point of view of a developer that loves to learn, simpler languages inspire me to learn more complex languages, which in turn gives me more opportunity to enjoy my chosen craft.
C++ is not that complex, and honestly it's one of the best documented languages out there. The semantics are very clear and you can easily decide to stick to a smaller subset of C++ if you don't like the advanced features like concepts, template metaprogramming, and class hierarchies (I would in general advice against OOP in C++, just as I would in any other language).
Ruby does a lot of magic stuff to help beginners. That means the semantics are unclear. IMO this is similar to how Apple optimizes UI/UX for first impressions to drive sales. The journeyman user is neglected, simple things are easy to do, but the most powerful features are missing for journeyman and advanced users.
I'm not saying Ruby is a bad language. Just saying that I have the opposite view. I too love to learn, but Ruby did not help me learn, it actively got in my way.
You can make a simple language without confusing semantics, see Go, C, python.
> C++ is not that complex
C++ is so complex that you can take 10 C++ devs, put them in the same room, and none of them will be able to read any others' code because they've each written it in a mutually exclusive C++ feature set.
Have you written C++? There are no "mutually exclusive" feature sets. The only deprecated language features I can think of are auto pointers and trigraphs, and I have never seen them in the wild.
I was making a hyperbolic joke. But "mutually exclusive feature sets" means two feature sets without overlapping features.
It doesn't really work as a joke if there's no truth to it.
I understand what mutually exclusive means. There are no two people writing C++ with no overlapping language features. I struggle to understand what you might even mean.
Non-equal subsets of the full language feature set? Yes, that will happen with any nontrivial language.
Nevermind then, it's okay if you don't get the joke.
>C++ is not that complex
Relative to what, exactly?
It is very hard to take a statement like yours seriously when even veteran developers continue to ship software with memory bugs that exfiltrate data and crash systems to this day.
When I said it's not complex I did not mean it's perfect or that it is easy to write flawless code in C++. And obviously C++ is most relevant within its own niche: video games, scientific computing, and performance critical software. The issues you mentioned are tradeoffs that C++ suffers from the higher degree of control a developer has. They're real, and that's a valid point.
What I meant was that if you wish to fully understand how the language works, I bet you that C++ has a clearer path to get there than Ruby does. The documentation and surrounding ecosystem of conference talks, content creators, and longer texts on new features is excellent. Not to mention public online communities like the irc channels on libera.chat.
The original poster I answered to was saying that C++ requires a lot of dedication to understand, but I would say this is true of every language, and C++ is very good at getting you there.
> Relative to what, exactly?
Life
I love Ruby (… contextually, with the most important part of that context being “for small programs”) and its general culture (_why is/was amazing) but hate Rails.
In practice this means I don’t use Ruby professionally any more, because there aren’t a lot of non-Rails Ruby jobs. And since I write a lot of python at work, that’s my go-to for my own quick little personal scripts, too, just for simplicity’s sake as far as what I have to keep in “working memory”, if you will. Plus it’s already installed on most systems I touch, unlike Ruby.
Like I do care about how “joyful” a language is but I also care about how hard it is to work with if a codebase has been through a bunch of contractors’ and agencies’ hands and it’s kind of a mess and the test suite hasn’t been updated during two full years of active development. For my own “joy”’s sake, give me Go or c# or maybe even Java if you must, under those circumstances. It’s unlikely I’ll find much joy in Ruby when that’s happened, which is often.
Well said.
Well, robbyonrails mentioned that he is an atheist. From my own experience in general, I have found that most people are not atheists. They just replaced God with their ego. In software engineering I have seen so many egos and self-rightousness, I just think I made a mistake of following the craft.
There are major gaps in platforms slapped together in the VC Party / Ruby era that seem to have unresolvable tech debt. Or perhaps Ruby just attracts the types of people who would rather talk about F1 racecars on Twitter than instruct a few of their thousands of employees to fix the shipping calculator.
Ruby was not designed to be a serious language. It was designed to be fun like PHP but not ugly like PHP. Meanwhile PHP grew up and Ruby grew out.
It's okay to love a thing and realize that it has some unsolvable issues and some people around it destined to keep it that way. Most things are like that these days.
The reason people attack Ruby is because Ruby users are vocally conceited, claiming “their language” holds some set of special place, uniquely created for developer joy and developer happiness.
It’s this ridiculous conceit and arrogance that in some way (never quantified mind you), that makes people want to bring the Ruby conceit back to earth.
That’s why Ruby gets attacked - because it’s nothing special but the Ruby lovers club all claim it is.
Perspectives like this always tell more about you than whatever it is that you're talking about.
Thank you.