You’re still working with types, you just don’t have anything checking your work (except the tests you write). Controversial opinion, but I think many of the folks who don’t like types really just don’t want to be bothered about the bugs they’ve introduced off the happy path. This is based on my experience in a Python shop.
it doesn’t really matter what you enjoy if we are talking about what is needed to make a given language faster. That being said, nodejs on v8 is a lot faster than ruby and dynamically typed, so I do agree with your conclusion that static typing is not necessarily the answer.
One of the goals of Ruby 3 is to have a 3x improvement in performance. If you're interested in how Ruby is planning to improve performance, this is a good read: https://blog.heroku.com/ruby-3-by-3
Getting a bit off topic here, but you sound knowledgeable about Ruby. Ruby is a language I've always admired from afar, but never spent much time trying out. I've read the poignant guide, which was amusing but didn't teach me too much. What's the SICP of Ruby? As in, a high quality book that will teach me the ins and outs of the language.
Ruby is a heavily idiomatic language. It's strongly advised to use rubocop or a similar style guide -- and to temper that with good judgment, at least when it recommends avoiding `!!`.
In addition to the Pickaxe book, I recommend Metaprogramming Ruby by Paolo Perrotta, and potentially the sequel to that book (which I have yet to read).
Ruby lends itself to a very fluid style. One of the things that you may find less common is explicit variable assignment within a method: most of the time your assignment will be in method signatures and block declarations. The following code is illustrative of technique, but not recommended practice:
This generates "non-words", which are guaranteed not to exist in the (Unix) system dictionary, without using explicit assignment. First it creates a (lazy) generator object which yields random "words" of varying length. In Ruby, if you are calling a method with only one argument in an inner loop, you can avoid writing the loop explicitly, which is nice here because it also avoids the performance hit of reading the dictionary file repeatedly. The `method` method lets us pass an object-method pair, to be evaluated later, and the '&' there is a sort of cast-to-block, and you'll see that used in other contexts. So, at that point, we have a lazily-evaluated collection of lazily-filtered strings, and we can take an arbitrary number of these out and print them.
The nice thing about Ruby is that you can probably express what you want in one statement. This does come at the cost of a fair amount of idiom. Some of it is functionally important, some of it is convenient (like using the `*` operator to destructure ranges), and some is pure window dressing, but enforced by convention just the same. The Pickaxe book is better than anything else that I am aware of for describing Ruby idioms. I'm not sure how well it has aged. It's probably recommended to do a lot of pair programming and code review. At times I have mentored others on the website Exercism, and I would recommend that or a similar site.
I had decided against a somewhat stronger statement; I didn't want to bash Pickaxe unnecessarily, particularly as I don't have a lot of better suggestions. I'm fairly inclined to write a book myself to address the situation, but not any time soon.
The V8 team also has the budget to make these kinds of improvements. Browsers are a massive platform, not to mention Node. I don’t expect these changes to come to Python or Ruby soon.
Crystal suffers from other problems. They diverged too much from type annotations and use macros / metaprogramming too much which immensely increases the compile times.
I don't know about Crystal's preformance problems specifically, but I would be surprised if macros would take up much compile time. I would have guessed it was more to do with the fiendishly tricky type inference problem that they set for themselves (ie. global inference + subtyping + union types + inheritance + overloaded methods).
