
Ruby 3x3: Matz, Koichi, and Tenderlove on the Future of Ruby Performance - potomak
https://blog.heroku.com/ruby-3-by-3/
======
technion
Half of the Ruby that I write is not web applications - it's scripts that
configure servers, import and export data, optimise a manual process, etc.
Ruby is perfectly performant in those scenarios.

It's become a horrible meme I can run a script that reformats a 30 line CSV
file the way I want it in 0.05s and someone will almost certainly lean over
and say "Ruby is too slow, you really need to upgrade to <x>". Or the intranet
application I wrote in Sinatra last year for a total of four users, where all
I got questions about how it could be usable without "asynchronous".

That said, I don't understand Ruby's performance position. IBM released a
preview of their JIT implementation over a year ago, with much fanfare. By
many accounts, it held major practical improvements. Since then, I haven't
heard a thing about it, and the Ruby team seem to be spending years talking
about implementing the same thing.

~~~
omgdlight
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)

~~~
jwdunne
Matches my use case completely. I haven't built a rails app but learned ruby
with a view of doing that but never did (I believe it's important to know the
language before the framework - in hindsight, a good decision with Rails
specifically).

I like the standard library and I love the gems that fill the gaps the stdlib
shouldn't really fill.

Many devs I know reach for the language they use day to day and their scripts
and productivity suffer. Ruby is almost like an openly secret weapon in that
sense.

------
iagooar
Too little, too late.

Disclaimer: I'm a Ruby developer.

Making Ruby 3 times faster is not going to save it. It's just way, way behind
the raw performance of other programming languages. 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.

I love Ruby, the programming language, but I kind of start seeing that others
haven't been idle and there are some growing ecosystems that can soon leave
Ruby behind. It kind of feels like Perl back in the day: it was still a good
programming language when it started losing ground.

We, Rubyists, have seen a lot of talented people leave both the Ruby and Rails
core teams. You see them go to other, younger communities, making them bloom.
In the meantime, the Ruby ecosystem seems stale and lacking fresh ideas.

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

~~~
RVuRnvbM2e
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.

~~~
duaneb
> Like Python? Ruby is comparable in performance.

Only on a cursory glance... python has pypy, cython, greenlets, twisted,
numpy/pandas/scipy, and dozens of game engines of varying quality. You can
write high quality, high performance python code that fits right in with the
rest of the community.

Ruby performance is a joke. It doesn't even ship with a useful memory or
performance profiler, hence New Relic's existence. You're correct, it's a
great DSL language, and performance shouldn't matter at that level.

------
banachtarski
The decision to avoid LLVM (for JIT) due to its lack of age/maturity strikes
me as extremely odd. I can't think of a piece of technology that has as much
universality, buy-in, functionality, and compatibility.

~~~
rurban
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.

~~~
dakull
This is a really nice read by RuJIT's creator - Masahiro Ide (his Doctoral
Thesis [0]).

[0] -
[http://kamome.lib.ynu.ac.jp/dspace/bitstream/10131/9368/1/id...](http://kamome.lib.ynu.ac.jp/dspace/bitstream/10131/9368/1/ide_masahiro-
thesis.pdf)

P.S. this is available via google results, I'm assuming it's public domain

------
dorianm
For those who want ruby-like syntax and native performance, there is crystal:
[https://crystal-lang.org/](https://crystal-lang.org/)

~~~
eropple
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.

------
rrradical
I could be reading the tone of the interview wrong, but it seems like there's
a weird sort of anti-intellectualism bent to the Ruby community.

In the middle, there's this exchange:

    
    
      Jonan: So you would just use pointers to point to those immutable objects?
      Koichi: Yes. Also, I want to note that immutable doesn't mean frozen object.
      Frozen objects can contain mutable objects. So I mean those immutable objects which only contain children
      that point to immutable objects.
      Jonan: So if we had a nested hash, some large data structure, we would need to
      freeze every object in that in order to reference it this way. Is there a facility in Ruby right now to do that?
      I think I would have to iterate over that structure freezing objects manually today.
      Matz: Not yet.
      Jonan: So there might be?
      Matz: We need to provide something to freeze these objects.
      Aaron: A deep freeze.
      Matz: Yes, deep freeze.
      Jonan: Deep Freeze is the name of this feature maybe? I think that would be an excellent name for it.
    

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

But then at the end...

    
    
      Jonan: OK. So then, a friend asked me when I described guilds, he writes a lot of Haskell,
      he asked me when we are we going to have "real immutable objects", and I don't quite know what he means.
      Is there some distinction between an immutable object in Ruby and an
      immutable object in a different language that’s important?
      Matz: For example in Haskell, everything is immutable, it’s that kind of language, everything is immutable from day one.
      Jonan: Yes.
      Matz: But in Ruby we have mutable objects, so under that kind of situation we need a whole new construct.
      Aaron: Frozen objects should really be immutable. It's really immutable.
      Jonan: OK.
      Aaron: I don't...
      Jonan: You don't know what this person who air-quoted me "real immutable" was saying?
      Aaron: Yeah I don't know why they would say "real immutable".
      Jonan: Should I unfriend him on Facebook? I think I'm going to after this.
      Matz: At least tell him if you want "real immutable" go ahead and use Haskell.
      Jonan: I think that's an excellent option, yeah.
      Aaron: You just to need to say to them quit "Haskelling" me.
      Jonan: I should, I’ll just tell them to quit "Haskelling" me about immutable objects. 
    

I get that they are joking a bit, but do they really not understand that the
Haskeller is referring to the lack of deeply immutable objects? The hostility
seems a bit weird to me, given that languages like Haskell push forward our
understanding of the usefulness of things like immutability, which then get
absorbed into other languages (like Ruby, clearly).

~~~
mmahemoff
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](https://twitter.com/dhh/status/216238003817938944)

People looking for conceptual purity should look elsewhere.

~~~
tinco
Please don't look elsewhere for conceptual purity. Ruby is absolutely ideal
for exploring any concept that can be expressed in object oriented
programming, and even many that are expressed in algebra.

Ruby has been designed fundamentally as an Alan Kay style object oriented
programming language. In that light in my opinion it is more suitable for
conceptual purity than most other scripting languages.

DHH's criticism of SRP has to do with legitimate drawbacks. I think all of us
have experienced the over-engineering SRP can invoke when applied naievely.
Also note that DHH's framework Rails has made significant steps in enabling
SRP for modern Rails applications, so this is not a flat out rejection of the
idea.

~~~
mmahemoff
I'm not sure Ruby is ideal for exploring OO concepts, as fine a language as it
is. Missing, for example, are: inheritance of class attributes/methods,
constraints on overriding methods (e.g. declaring as abstract or un-
overridable/final), dynamic attributes.

Thankfully it's a very flexible and forgiving language, so there are third-
party libraries (e.g. Hashie, ActiveSupport's Concern) to accomplish these
kinds of things, but the core language doesn't offer them.

------
kyledrake
TLDR: There isn't an actual plan to make Ruby 3x faster, it's just a bullshit
number Matz made up to be cute. Instead there will be some marginal
improvements here and there, as per usual.

Some vague references to the idea of building a JIT are discussed. Rubinius
already does this, but they apparently long ago decided that Rubinius doesn't
exist, so I guess that's off the table.

~~~
juandazapata
You must be fun at parties.

~~~
kyledrake
You better believe it.

I was at the Rubyconf in Denver sitting behind Matz, and watched him fiddle
with his computer and tweet instead of paying attention to Brian Ford's well-
informed talk on the deep structural problems within the Ruby development
community, which included their indifference to concurrency issues
[https://www.youtube.com/watch?v=BagNfTbXn3w](https://www.youtube.com/watch?v=BagNfTbXn3w)

I then went one of the talks at the same conference on improving Ruby
concurrency for IO that was largely unattended because it was scheduled to run
at the same time as an Aaron Patterson talk on literally making sausage.

It's clear to me through observation that the Ruby core devs don't take this
topic seriously. And while current performance isn't presently a huge problem
for my work, it's clear to me that a lot of people are walking away as a
consequence of this.

I'm sorry if bringing this up makes me uncool at your parties or whatever, but
if we're going to have a real conversation about this, let's have that instead
of just singing kumbaya around a dumpster fire. Matz is out there selling
people on the idea that there's going to be a 3x performance increase when
there obviously isn't going to be one.

And FWIW, I had drinks with Brian, the other concurrency speaker, and I do
recall getting tacos and singing some karaoke with Tony Arcieri. You'll have
to ask them if I'm good for parties or not.

~~~
posterboy
A typical answer to this would be to ask about your contributions to the
issue. I don't mean to allege responsibility, but a strong investment would
explain your frustration and choice of language much better.

>[talk on concurrency] that was largely unattended because it was scheduled to
run at the same time as an Aaron Patterson talk on literally making sausage

I literally laughed. Such is the live of compiler architects, I guess, they
are far and few between.

~~~
kyledrake
I absolutely made contributions to this issue when I had the chance
[http://www.slideshare.net/KyleDrake/hybrid-concurrency-
patte...](http://www.slideshare.net/KyleDrake/hybrid-concurrency-patterns)

------
ksec
We keep seeing discussion like this and yet we haven't seen much improvement.
They used to joke about only those company making money are Rails. So why
haven't Github, Shopify, Twitch, Groupon or others pour any resources in ?

Ruby is slow, at least from a Web Development perspective, Rails is VERY slow.
So both together combined makes things a little bit bad.

Look at the boring stack from StackExchnage

[https://news.ycombinator.com/item?id=12790650](https://news.ycombinator.com/item?id=12790650)

[https://twitter.com/Nick_Craver/status/790527231600787456](https://twitter.com/Nick_Craver/status/790527231600787456)

Any Rails Shop would be happy if they could hit 3x those numbers even with
caching.

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

GitHub does; Tenderlove works on Ruby there!

------
DamnYuppie
I am not sure it doesn't make sense for them to just move over to JRuby and
have them all focus their efforts their.

~~~
sams99
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.

~~~
dakull
Did this help in any way? [https://tunemygc.com](https://tunemygc.com)

Just by playing around with ​ RUBY_GC_HEAP_OLDOBJECT_LIMIT_FACTOR you can
reduce memory consumption quite a bit.

~~~
sams99
I did hand tune stuff

[https://github.com/discourse/discourse_docker/blob/master/te...](https://github.com/discourse/discourse_docker/blob/master/templates/web.template.yml#L8-L12)

RUBY_GC_HEAP_GROWTH_MAX_SLOTS is critical without it you get way too much
bloat. The default is very problematic I discussed this with ko1 but not sure
if we can get a better default in for 2.4.

------
andy_ppp
I see no reason to not just move to Elixir at this point for 10-20x
performance increase and the tools to build distributed systems at your
fingertips.

~~~
kondro
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.

~~~
andy_ppp
I've been wrong on here before but I've never just invented stuff without
facts...

[https://github.com/mroth/phoenix-
showdown/blob/master/README...](https://github.com/mroth/phoenix-
showdown/blob/master/README.md)

