Ruby 3x3: Matz, Koichi, and Tenderlove on the Future of Ruby Performance

I really enjoyed Advi Grimm's "Ruby Tapas" videos because many of his examples did not involve web development at all.

ruby is really good for solving small problems quickly. Don't get me wrong, proficiency in your shell will go a long way. But when something starts to get complicated I can bang it out in ruby and it's just done.

Web apps do drive ruby's adoption, though. Now that I know ruby I use it for many things, but I learned it initially for rails. Many other languages (like python) can fulfill ruby's scripting usages (I would argue javascript can't - despite its many strengths it's just a little too awkward)

I wish Ruby wasn't run by Matz and his team. The number of improvements they can offer is just too little. And they don't do well to get and include feedback from others. It's true that they've been working on Ruby for a long time, and they deserve credit. But it's time for Ruby to grow past Matz and his team.

If Ruby can offer: - real threads - great performance

Then the conversation about Ruby would be about the right things - do you like the syntax, the feel, would it work for your team, etc. We wouldn't be bickering about "performance" all the time.

> The other problem is that there is not a single company that will throw as much money as it takes to improve the language, as happens with JavaScript, Python or PHP.

I don't know if this is really the reason I believe Ruby hasn't evolved as much as other languages. There are no big entities pushing big on Haskell, for example (Facebook uses it, but you don't see them driving development), but GHC evolves like crazy to support more language features, be better optimized, etc..

Isn't it fair to say that a community that loves to say "X isn't <good attribute> but it doesn't need to be!" is just showing disinterest in evolving? There will always be a point if you pat yourself on the back too much about your one big advantage, where you find yourself with increasingly less of an advantage. Your disinterest in improving caused you to stagnate and suddenly there is no advantage anymore.

At some point relative properties like "It has a very broad ecosystem" and "It's the most concise language" don't turn out to be very big advantages or no longer be true, in the case of the latter. There are other examples of this in the clique formerly known as "scripting languages". Most of them can be beaten by implementing new languages on platforms that started with less ideal languages.

>Making Ruby 3 times faster is not going to save it

Adding something akin to Guilds it could give it a nice advantage if implemented nicely.

>the Ruby ecosystem seems stale and lacking fresh ideas

I think that's mostly because it's not the new shiny toy what it's missing is some sort of cohesion to push it forward.

Maybe, I'm just biased but even with languages like Elixir - I keep coming back to Ruby.

Is your experience mostly web dev? Because not all areas of software are so mercurial.

> Making Ruby 3 times faster is not going to save it. It's just way, way behind the raw performance of other programming languages.

Like Python? Ruby is comparable in performance.

> Also, with the arrival of new, modern programming languages, there isn't that many productivity reasons anymore to justify the poor performance and lack of sane concurrency.

There is no other language that makes it as easy to write a DSL. And there are plenty of places to look for concurrency in Ruby, built right into the language. ruby-concurrency provides even more abstractions.

> The other problem is that there is not a single company that will throw as much money as it takes to improve the language, as happens with JavaScript, Python or PHP.

Isn't that company Salesforce/Heroku?

> I am not trying to say that Ruby or Rails are a thing of the past and shouldn't be used. They are still great tools and put in the right hands can give your company / project huge productivity and more-than-acceptable performance. But there is a time for everything, and I think that the golden years of Ruby are gone.

I disagree. There are plenty of projects written in Ruby that are still going strong. The language is just maturing and web dev is not the only thing people do with it anymore.

I'm curious to hear your opinion on which ecosystems are likely to replace ruby. I think nodejs and some of the newer jvm langs are well positioned to do well in the web app market, but I can't see what's going to replace it for one off scripts. But then, perl is still being used by some folks for that, so maybe that's where ruby is going.

IIRC LLVM's functionality for JIT is new and/or experimental (patchpoints).

Sure, LLVM can literally compile just in time, but JITs need much more than that.

There are some JITs that used (tried to use) LLVM but eventually stopped using it, see HHVM or Apples JavaScriptCore (despite that Apple is heavily involved in LLVM). LLVM is great as a AOT-compiler, but JITs seem to need faster compilation-times for some benchmarks. See this blog for some numbers from Apple: https://webkit.org/blog/5852/introducing-the-b3-jit-compiler...

But yeah, their reasoning for avoiding it was a bit strange. Although I understand them when they say that LLVM as a dependency may be to huge for Ruby. LLVM is huge and the bigger project compared to Ruby with major backers (Apple, Google, etc.). What is important for Ruby may not be what has high-priority for the LLVM project. IMHO Ruby is big enough to warrant its own JIT.

LLVM is too big and not good enough.

The only viable options are dynasm, a simple selfmade jit as in potion/tinyrb or rpython. perl6 went with dynasm.

rujit looked good to me, but the tracing overhead was too much. They should really analyze why it was so big, even as tracing jit.

And the datastructures need to be slimmed down, as in potion/tinyrb or php7 or lua/lisps. Only tagging schemes lead to performance. This has nothing to do with the jit. size matters.

We tried to implement an LLVM based JIT compiler for PHP. There's basically two problems: First, LLVM is excruciatingly slow. If I remember correctly, it took more than a minute to compile all the WP functions for a front-page access (this is something like 100k VM instructions translated to LLVM bitcode). Second, LLVM is not great at optimizing the kind of IR that a JIT compiler for a dynamic language emits. It is much more important to perform language-specific optimizations prior to lowering. HHVM basically came to the same conclusion [1]. They lowered vasm to LLVM IR and let LLVM perform additional optimizations and native codegen. The difference was basically noise.

On the other hand, there are projects that do successfully use LLVM for JIT. We now experiment with dynasm, which doesn't optimize, but is fast and much more pleasant to use. libjit looks like another popular option. [1]: http://hhvm.com/blog/10205/llvm-code-generation-in-hhvm

Ruby isn't about the syntax, though. Ruby is about the metaprogramming and what the language allows you to do.

Crystal is neat, but it isn't interesting.

I do think this is the culture of Ruby, appealing to some and not to others.

Ruby is a practical language by design and it's common to see good-natured poking fun at academic concepts that sound good in theory, but fall apart on corner cases (and real projects are full of corner cases).

Case in point: https://twitter.com/dhh/status/216238003817938944

People looking for conceptual purity should look elsewhere.

What about this seems anti-intellectual? Anti-intellectualism is not the same as having a decent sense of humor. They're obviously joking around and being a bit irreverent here.

I think that's mostly Aaron being Aaron, it's not necessarily some form of anti-intellectualism but more like just his personality at work.

I don't really have a problem with the tone of the interview but more with how vague the proposed objectives are.

Also, there seem to be some rather misleading facts in it - like the AOT and the 30% speed-up - in practice, after testing it - it helped to load Rails faster but other than that the benchmarks were virtually identical (don't get me wrong, booting Rails faster is great but they imply something completely different in the interview)

The wordsmanship and joking about "real" immutability are in no way unfamiliar stuff to people in other languages, Ruby aside. In Java, it's the same deal, where maybe you can't change an object's fields, but it's fields' fields might be mutable. One layer deep, shallow freeze, shallow copy are actually pretty well understood concepts by "non-Haskellers", as well as the drawbacks and the need oftentimes for 100% deep guaranteed immutability--and the advantages and safety that brings. I think that the joke is that the label "immutability" in languages that don't support it from the ground up--unlike like Haskell--isn't really worthy of the name. But since we already dubbed them as immutable objects (even though they weren't really) you need some extra emphasis for true immutability...super immutable, seriously immutabile, really-really-immutabile, etc.

I suspect you don't know many of the Ruby core committers. They're an incredibly jovial bunch. Aaron loves puns and word play, just check out his twitter feed: https://twitter.com/@tenderlove. After rereading it, I can see why their sense of humor may have been lost in transcription.

> So yes, they all agree that Ruby's current 'frozen' feature doesn't grant real immutability guarantees.

It grants immutability for the object itself. What they are pointing out is that other than fundamental objects like String, Fixnum etc., those objects will usually contain references to other objects (EDIT: any member variables etc., as well as the class, which means the ojbects observable behaviour can also change even if instance variables don't), and those will still be mutable unless they too are frozen.

So we can do immutability in Ruby currently, it's just a pain to do and requires knowledge about the objects - you could implement a generic "deep_freeze" that iterates over instance variables etc., but it would have uninented consequences because it would know nothing about which object references are shared where it's ok to break that by "dup"'ing the object to freeze it (and without dup'ing it, you risk other code that isn't prepared to work with a frozen object breaking)

This is mostly a "problem" because writing Ruby to work on immutable objects would often result in code that's not idiomatic Ruby, and so you won't get many Ruby developers to agree it's a real concern, though the trend is towards freezing more objects.

They're being ironic. This is part of the Ruby culture in general, and Jonan and Aaron in particular tend to double-down on it. I don't think there's any hostility to Haskell or anti-intellectualism here.

You must be fun at parties.

> So why haven't Github, Shopify, Twitch, Groupon or others pour any resources in ?

GitHub does; Tenderlove works on Ruby there!

Shopify does too. Just look at their Github

Yeah, jruby+truffle could be pretty amazing for ruby performance.

However, having multiple ruby implementations is great too, and they probably would rather keep working on an independent implementation that they have full control over, and whose goals may not align perfectly with that of other implementations.

At Discourse our biggest constraint we are fighting now is memory, not performance (don't get me wrong, I wish MRI was faster). JRuby is usually more memory hungry than MRI and getting reasonable boot time is not easy on JRuby.

Additionally we don't even boot on JRuby today, I wish we did but it is hard to justify effort here.

I don't think everyone likes depending on Java.

I dunno, maybe cause re-writing a 10 year old working app in another platform is not something that is easily achievable or even desirable.

http://www.joelonsoftware.com/articles/fog0000000069.html

Elixir is not a faster Ruby, it's a completely different beast which only shares some syntactical constructs and keywords.

Please don't make us Elixir fans look bad.

Because some of us might enjoy the ruby stack and are willing to pay the few extra bucks for better servers?

Why does everything have to be black and white anyway.

I'm not sure why the hostility but you are entitled to your opinion; it's really not the performance that makes Elixir better for me (it's everything else - I come from a Python background and I'm just so so tired of the GIL) and I haven't suggested rewriting any working apps in it!

I am well aware that Elixir is different than Ruby, even though it borrows some great syntax ideas!

Because if you put a framework as complete as Rails on Elixir it would probably only be marginally faster anyway.

People always seem to compare extremely simple microservices to Rails apps and exclaim how much faster it is in comparison.