Why so Serious?

Haven’t read the Wired article Robby links to as it’s behind a paywall but the first two lines of the preview were enough to convince me the author seems to be missing the point:

Ruby Is Not a Serious Programming Language

Ruby survives on affection, not utility. Let’s move on.

There are reasons for the affection, and it’s those reasons why it survives, and imo, exactly what will help it (and others like it) continue to survive in an age of AI

Unless those reasons are given in more detail and they are proven to demonstrate technical superiority compared to most other popular PLs out there, then the original statement stands. “Loving” a language does not have much correlation of how well it solves most problems out there. Many people love language either because of syntax (superficial and unimportant and not a “reason” at all) or because it solved a particular set of problems they had at the time that were important to them which, needless to say, is not “most problems that are important to solve with technology out there”.

I view Ruby as a glorified shell scripting language nowadays. That’s what it really is and it’s not an accident that Homebrew chose it; it fits what they need to do very well because dealing with weird bash-isms can make you want to hang yourself. So they went one abstraction layer above to get rid of endless pointless complexity churn. Ruby absolutely is a very solid choice for their use-case.

We can all selectively and conveniently do the appeal-to-the-masses-fallacy when it suits our bias. We can and should do a better argumentation than that. It’s not intellectually honest. It’s a cop-out: “my favorite thing is popular, hence it’s good”.

At one point in the past burning “witches” was very popular. Was it a good thing to do?

Historically speaking, there is no evidence that popularity correlates with quality. At one point network effects kick in, and they are extremely difficult to nullify; like stopping a huge boulder rolling downhill.

If we want to be even more serious we can even say that Elixir is not a serious PL as well – no static type checking! However, having no static checking is a bliss in Elixir’s niche, as has been discussed to death on this forum (less code written and only enriching it if running in production proves that a certain previously-uncovered case arm must be now covered, being the chief example).

As much as I love Rust I don’t want to prototype with it; I reach for Elixir or Golang for that. Rust only gets summoned once the design has been more fleshed out… and if we really need Rust’s benefits (make most invalid states non-representable and needing ultra speed). Or I am tasked with doing the task in Rust to begin with.

So Elixir is a serious PL because it fills a niche. Ruby, I would argue, barely fills any niches nowadays. The fact that it’s still widely used is more of a testament to the stubbornness of humanity at large, huge organizational risk aversion, and fear of losing one’s career and cushy paycheck by its proponents. It’s definitely not a testament to its technical qualities which are highly unimpressive come 2026.

Ruby is the Perl that refuses to die even though PHP and Python exist for a long time and they ate its lunch ages ago. Which is fine. Use it if it pays your bills. We live in a world where quality always takes a backseat – I don’t judge [too much] the people who are cynical realists and are trying to survive and thrive in this terrible civilization we currently inhabit.

But I’ll not pretend it’s a serious language. It’s not. It’s a toy carried by metric tons of nostalgia.

Exactly, People likes to get validation and will invent all sort of arguments to justify their bias. Similar arguments can be made in many languages., like Perl5 is not a serious programming language! Perl5 survives on affection, not utility!

There is a wide spectrum between correctness and ergonomics and Elixir only covers a narrow space on the spectrum. However, I’d hate it if the space is narrowed down to a singular point.

Bias is an inescapable bug of the organic brain – it is forced to do very aggressive inference and approximation in order to conserve energy. I try hard not to judge but I do prefer pointing people at their bias (and I am grateful when mine are pointed out to me) so we can all collectively improve.

(I tried writing Perl ages ago. Never again, even if I am paid for it. Couldn’t let your remark without a response! The very little I know about it does tell me it survives on affection indeed – regardless if your remark was sarcastic or not – but I would not swear my life on that statement; I’ve seen the horrors that persist in some Linux packages that would be 100% dead if tomorrow Perl disappears.)

I would not mourn if 99% of all PLs get magically deleted from every computer on the planet tomorrow. Because that’s the approximate percentage of PLs that were mostly learning harnesses for their creators and not an objective improvement of the landscape.

Ultimately I believe every single PL / framework will fall in only one of the three camps:

1. Strongly but dynamically typed languages (like Elixir); you don’t want to have to add tests that assert a function does in fact only works with an integer and not with a float or a string etc. (And I’ve seen that done, more than once, in big Ruby on Rails projects, that make millions every month.) That’s just burning rubber. Languages in this group will be good for prototyping and orchestrating and partial or full self-healing. Very valid niche.

2. Strongly and statically typed languages (Ocaml, Rust, Haskell, Golang, Zig). When you really want to tighten the bolts and make invalid states non-presentable in code… and maybe also have ultra performance (Rust, Haskell, Zig). We might fit Idris and Coq here for their contribution to an even stronger typing. Ideally at one point we’ll get linear typing and others in the more mainstream languages like Rust and Golang, but it’s highly doubtful. They’ll likely fade at one point and others, even more refined languages, will take their place.

3. Declarative programming languages that get transpiled by SAT / SMT / other solvers to many other languages in groups 1 and 2. I am thinking stuff like Kubernetes YAML files here: you describe your desired end state and the runtime reconciles what it can currently see versus what you need. IMO declarative programming will one day be the only programming that remains… but it’ll use a few lower-level PLs below (due to my bias I’d think those would be Rust + Elixir but they could be any pair that belongs to groups 1 and 2 respectively).

Any context I’ve seen the term “serious” used, it’s a pure expression of contempt. It never has any significance beyond that. One never describes something positive as “serious”–no one would know what that means. But it’s always quite clear that “not serious” simply means “beneath consideration”, which is fine to have as a private judgment but is hardly constructive as an argument in a public forum. It certainly wouldn’t fly in a professional context, where it would add nothing to the actual arguments for and against. But perfect for language wars I guess where there is no actual problem at hand to be solved.

As someone who used PHP, Python and other comparable languages before encountering Ruby, the appeal of Ruby’s ergonomics was clear and immediate. For various reasons, I was able to be more productive with it and that allowed me to achieve a certain amount of success. Evidently that was also true for a significant number of other developers. If it has been a poor fit in various applications, well, it can hardly be blamed for that. Is a bike not a “serious” mode of transportation because someone failed to ride one to the moon?

Ok, this seems to be turning into an interesting discussion and I was expecting people to have a lot of strong opinions… But let me clarify before this turns into some kinda of flame war :

The reason why I posted is that I’ve worked many many years with other languages (enterprise ones) that are considered more “serious” in contrast to Ruby, and it pretty much shapes how you work with it and how the community interacts with each other (as a set of expectations if you will).

Because of this I have this belief that programming languages (like human languages) also help shape culture and communication. Hence, you are always going to have people that value “correctness” over “ergonomics” and vice versa, so I was wondering where do people think our community gravitate towards.

I think the author’s main point also reminds me a bit of the agile manifesto: “Individuals and interactions over processes and tools” (which I think has been more influential in the past and I’m not quite sure still resonates as deeply with younger developers theses days).

Culture doesn’t reliably reward the serious. Neither does business. It rewards the resonant. The clear. The human. The work that connects. Ruby has always leaned toward that side of the craft. Toward the part of programming that remembers people are involved. Toward the part that says maybe the code should serve the team… not the other way around.

That’s true for human language but not necessarily true for programing languages. In programming, we can pick the best languages to suit the team/culture we have. From my experience, an “enterprise” team is one that has 1~2 guru level leaders and a large member of fungible junior engineers. I guess neither Ruby nor Elixir would be a good fit there.

Very romantic… until the servers fall over again (17th time this week) because Puma took years to get stable enough.

IMO Elixir attracts the ergonomics camp but they get pleasantly surprised that they get a lot of the rest of the package as well. Win-win.

And history has shown that unless you work on medical appliances / aircraft / financials then barely anyone cares about correctness.

Elixir has a very long and prosperous life yet ahead of it.

I stand by what I said. I think every piece of work carries an imprint of its author, and I think it’s undeniable that communities form around shared interests/ convictions. Some even argue that everything is political (but I’m not getting into that). What I see in practice, anecdotal as it may be, is that you can swim against the stream, but the community that forms around a technology, which is ultimately made of people, can have a strong influence on how you end up conducting business.

And history has shown that unless you work on medical appliances / aircraft / financials then barely anyone cares about correctness.

I guess there’s also a beautiful duality in the people vs tech debate, and I tend to agree with you, I think that unless you are working on some mission-critical stuff, people rarely care about correctness, or technology for what matters - and I think there’s an underlying lesson related to tech enshitification as well, but I digress.

I do appreciate Ruby for its impact on tech culture, though, and I like to think that there’s some sort of balance in between where you can make the appropriate tradeoffs. I think we (tech people) tend to think we make decisions purely based on logic, but experience has shown me that’s mostly not true haha .

There is no disagreement here, and we have a prime example in Elixir. However, as compare to other language/frameworks in similar domain, Elixir gives you more leeway to deviate from the “one true way”, so you can “swim against the stream” here and there. For example, I have a strong aversion against scaffolding so I don’t use any of the code generators, and it is perfectly fine in Elixir/Phoenix.

Am I influenced by Elixir? Of course. Do I want to research into the “one true way” as intended by the authors, and treat it as the gospel? No.