[fredrikholm]

> Python? Ruby with YJIT, JRuby or Truffle Ruby usually beats python code in benchmarks.

Isn't that moving the goal post a lot?

We wen't from 'faster than a lot of others' to 'competing for worst in class'.

I'm not trying to be facetious, I'm curious as I often read "X is really fast" where X is a functional/OOP language that nearly always ends up being some combination of slow and with huge memory overhead. Even then, most Schemes (or Lisps in general) are faster.

Being faster single threaded against runtimes that are built specifically for multithreaded, distributed workloads is also perhaps not a fair comparison, esp. when both runtimes are heavily used to write webservers. And again, Erlang (et al) come out faster even in those benchmarks.

Is TruffleRuby production (eg. Rails) ready? If so, is it that much faster?

I remember when the infamous "Truffle beats all Ruby implementations"-article came out that a lot of Rubyists were shooting it down, however this was several years ago by now.

[Lio]

Moving the goal posts? Perhaps I misunderstand what you are asking. Python is the not the worst in class scripting language. For example perl and TCL are both slower than python.

Originally you just asked, "such as" [which dynamic language ruby is faster than?] Implying ruby is slower than every other dynamic language, which is not the case.

JRuby is faster than MRI Ruby for some Rails workloads and very much production ready.

Truffle Ruby is said to be about 97% compatible with MRI on the rubyspec but IMHO isn't production ready for Rails yet. It does work well enough for many stand alone non-rails tasks though and could potentially be used for running Sidekiq jobs.

The reason to mention the alternative ruby runtimes is to show that there's nothing about the language that means it can't improve in performance (within limits).

Whilst it's true that ruby is slower than Common Lisp or Scheme, ruby is still improving and the gap is going to greatly reduce, which is good news for those of us that enjoy using it.

[fredrikholm]

Thank you for a great answer; I did not mean any ill will and apologize if that was how it came across.

Perl, Tcl, Smalltalk etc are basically non-existant from where I'm from, so they didn't occur to me.

Perhaps I'm projecting a lot here. I have worked a lot in high performance systems and am often triggered by claims of performance, eg. 'X is faster than C' when this is 99.9% of the times false by two orders of magnitude. This didn't happen here.

Thank you for taking the time to answer.

[pjmlp]

Java's Hotspot was originally designed for Smalltalk, and SELF.

Two very dynamic systems, designed for being a complete graphical workstation, Perl, Tcl, Python, Ruby were as originially implemented, not even close of the original Smalltalk JIT paper from Peter Deutsch's paper"Efficient Implementation of the Smalltalk-80 System." in 1984!

[Lio]

> I did not mean any ill will and apologize if that was how it came across.

Oh not at all, no I didn't think that. I'm enjoying the conversation.

It's interesting that you mention Smalltalk as I believe that some of the JIT ideas we're seeing in YJIT are borrowed from there.

As for all the "faster than C" talk here is very specific to ruby (or JIT'd) runtimes and overheads only in that context.

I think it gets mentioned because it seems so counter intuitive at first. It's not to imply C isn't orders of magnitude faster in general.

Along with the new out of the box features of Rails 8, the work on Ruby infrastructure is making it an exciting technology to work with again (IMHO).

[weaksauce]

the ruby is faster than c is because of the yjit. they are moving a lot of c ruby standard library and core language stuff into ruby code so the yjit can optimize it better. akin to java and their bytecode being able to optimize things on the fly instead of just once at compile time.