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).
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.