AFAIK, you can still use Objective-C and create apps for macOS, iOS, and iPadOS? The APIs previously used may not be available anymore.

Typical. I may get absolutely destroyed for this, but being professionally proficient in a ton of languages, including Ruby and the ones I mention below, and the ones I'm about to mention:

This sounds like Microsoft when they moved from VB6 to VB.Net. At least they have a good thing going with C# though.

VB6 was quite an interesting beast. You could do basically everything that you could do in languages like C/C++, but in most cases, you could churn out code quicker. This even extended to DirectX/Direct3D! For Web pages? ASP Classic.

The tl;dr is that I really wish that ease of development were prioritized along with everything else. One of the reasons I like Ruby is the elegance of the language and ease of using it.

Note that I've been using it since the mid 2000s or so, but not exclusively (both it and VB6 defined my career, however). C# is my second most favorite.

If Ruby had the GUI design tools VB6 had, it would be interesting to look at the popularity stats

Anyway, I'm rambling, so there is that. ;)

What a lovely comment - thank you!

I used Ruby a lot from about 2002 to 2010. Haven't used it much since then, but this article really makes me want to get a copy of the upcoming version Ruby Under a Microscope.

That's the magic of YJIT, and what I'll describe in the rest of Chapter 4. YJIT uses a "wait-and-see" approach, and often defers compilation of the block/function until the actual types are provided by your program. And YJIT then keeps track of separate block versions based on the operand types, and can call the appropriate block version as needed.

This basic algorithm is called "Basic Block Versioning." Maxime Chevalier-Boisvert from Shopify has some great presentations online about this; for example [1].

I believe ZJIT, the newer JIT engine, uses a different approach. I'm exploring that now.

[1] https://www.youtube.com/watch?v=zO9_uTaELCw — RubyConf 2021 - YJIT - Building a new JIT Compiler inside CRuby by Maxime Chevalier Boisvert.

> Idiomatic Ruby uses blocks for loop bodies

Yes that's something I want to dig into and explore in this chapter... when exactly does Ruby's JIT compiler activate and optimize our code? And you're right: since Ruby will JIT blocks as if they were separate function many loops will be optimized using this simple heuristic.

I always found the steps to assembler harder. I'd wish we could have both a hardware interface that is resembled at the same level as the software - but super simple. With that I mean super-simple to understand and write; assembler is simple but not easy to understand. The complexity scales quickly. That's why C was successful - it was much easier to reason about the system in C than it was in assembler/assembly.

If you want to compare it against other languages you could look at The Computer Language Benchmarks Game [1], which is an ongoing comparison of various programs written in various popular languages. You should always take all these benchmarks with a pinch of salt though since they are never truly apples-to-apples. That said, Ruby seems to measure slightly faster than Python and Lua, slightly slower than PHP, and maybe 1 order of magnitude slower than Node.js, just to compare it with other similar languages.

Compared to itself from 10 years ago I think it's made great progress. Can't put a number to it but I wouldn't be surprised if it's 2x or 3x faster, especially with the "new" JIT (YJIT) enabled. The JIT comes with a memory usage penalty though. You can see some benchmarks over time (although not going back as far as 10 years) at https://speed.ruby-lang.org

1: https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

It's gotten faster, but so have other languages. The broad strokes rankings haven't changed so much that raw performance would change your mind today compared to 2015.

> How fast is Ruby, lately?

I did recent testing that showed it to be faster than Python but slower than Lua: Lua, Ruby and Python ran my benchmark in 12, 18 and 25 seconds respectively.

This was measured using the latest versions of each language (5.4, 3.4 and 3.13), using only the interpreters, no JITs.

> I haven't used it in about 10 years

It looks like the relative performance of the three languages hasn't changed much since I did a similar benchmark with Ruby 2.0, about that long ago.

I have a prototype ahead-of-time Ruby compiler. It's woefully incomplete - I've just recently picked it up again after years of inactivity, with heavy AI use to pursue rubyspec compliance (it's nowhere close). The point of mentioning that: MRI - the main Ruby interpreter - is fast enough that competing against it with an unoptimized compiler goes really badly unless you do a lot to optimise the garbage collector (I haven't yet).

So it's "fast". There's plenty more that can be done to make it much faster still, but even before yjit, MRI had gotten pretty decent.

Fast enough for most normal sites.