12 ms·

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

215 points by potomak 10y ago

DamnYuppie 10y ago
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.
- ehsanu1 10y ago
  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.
  - dakull 10y ago
    As they pointed out in the interview - it's not a free meal i.e. one could expect high memory usage and slow start-up times. For me the slow start-up and the JIT requiring ~50K/req for warm-up just ruin the whole experience in coding the app in Ruby I'd rather just use Elixir. Another interesting project is IBM's OMR [0] - compared to JRuby there are no slow start-ups and weirdly, being still a dev. preview it can run Rails and its deps. without issues, even better than Rubinius stable. [0] - https://github.com/rubyomr-preview/rubyomr-preview https://github.com/rubyomr-preview/rubyomr-preview
    - ehsanu1 10y ago
      50k requests seems excessive, are you sure about that? :) Of course it depends on the implementation particulars, and profile-guided optimization may help, but needing a couple thousand requests to warm up is not so bad for a web application server that will see 100x as many requests as that. If we're very lucky, Substrate VM will be released at some point, solving the startup time issues (and I believe many of the JIT issues, though less clear on that): http://lafo.ssw.uni-linz.ac.at/papers/2013_JVMLanguageSummit_OneVMToRuleThemAll.pdf http://lafo.ssw.uni-linz.ac.at/papers/2013_JVMLanguageSummit... The OMR project definitely looks interesting, but it doesn't seem to be actively developed (or perhaps the most recent commits are just not public yet). But if it works that well, then maybe there's no need, hah. Will have to try it out.
      - igravious 10y ago
        > but it doesn't seem to be actively developed The source code is here: https://github.com/rubyomr-preview/ruby https://github.com/rubyomr-preview/ruby Seems the code is being developed internally to IBM. First the docker images of the OMR tech preview were dropped about a year ago. The the source was dropped recently. Targets Ruby 2.2 so I'm going to open an issue asking about targeting 2.3 and folding this work into trunk. $ git clone https://github.com/rubyomr-preview/ruby.git --branch ruby_2_2_omr --recursive $ cd ruby $ autoconf $ ./configure SPEC=linux_x86-64 --with-omr-jit $ make $ make install This should build it for you to try out. I urge others to try it out and give feedback.
        magaudet 10y ago
        Hey! thanks for the shout out. I would totally love to see more feedback as well! We haven't turned on the issue tracker on that repo, but the glue has it's issues turned on: https://github.com/rubyomr-preview/rbjitglue https://github.com/rubyomr-preview/rbjitglue Working on smoothing this out a bit, and also currently working on upgrading the JIT to target 2.4
        igravious 10y ago
        Thank you for pushing Ruby performance forward! :)
      - magaudet 10y ago
        Hey, OMR developer here. Ruby+OMR is developed in three pieces: 1) the language independent core, then 2) The language dependent portions (i.e., the VM, and what we call the 'glue') The language independent core is here: https://github.com/eclipse/omr https://github.com/eclipse/omr. It's under active development, :) I'm actually working on Ruby 2.4 support right now (supremely not prime time, but if you're curious, the branch is here: https://github.com/mgaudet/ruby/tree/ruby_2_4_omr_preliminary https://github.com/mgaudet/ruby/tree/ruby_2_4_omr_preliminar...)
        10y ago
- sams99 10y ago
  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 10y ago
    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 10y ago
      I did hand tune stuff https://github.com/discourse/discourse_docker/blob/master/templates/web.template.yml#L8-L12 https://github.com/discourse/discourse_docker/blob/master/te... 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.
  - riffraff 10y ago
    > Additionally we don't even boot on JRuby today what is the blocking issue there?
  - ksec 10y ago
    Can you elaborate a little, given how memory is very cheap these days.
    - specialp 10y ago
      Memory is indeed cheap but the problem is when you run Ruby web services you have every worker taking a minimum of ~400mb. This doesn't sound like much but then with micro-services and other APIs also using that much RAM per worker it adds up fast as all of these servers also need to take this much RAM per concurrent connection you would like to support. For people starting out that is not so much a problem, but if you have moderate to large traffic you need a lot of machines just for the RAM. This is coupled with the fact that many Ruby libraries eschew streaming of files and connections and put things straight into memory despite Ruby having excellent block constructs that easily allow chunking/streaming. So apps also spike in memory and they need a large overhead as well.
- MrBra 10y ago
  I don't think everyone likes depending on Java.
andy_ppp 10y ago
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 10y ago
  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.
  - deleted 10y ago
    [deleted]
  - deleted 10y ago
    [deleted]
  - andy_ppp 10y ago
    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.md https://github.com/mroth/phoenix-showdown/blob/master/README...
- sams99 10y ago
  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 http://www.joelonsoftware.com/articles/fog0000000069.html
  - pdimitar 10y ago
    I would still advocate migration even of 10-year old apps to new languages. You will learn the language and its frameworks better, you'll enrich your neural paths and many other things will suddenly become clearer, and you might even help your customer succeed even more. Worth the shot most of the time, I believe. I am currently tasked with maintaining and upgrading a Spree 2.2 (ancient version) and Rails 4.0.8 (very old) based e-commerce shop and even slight modernizations are extremely painful and have proven impossible. The test suite I inherired is sorely lacking in several areas so I can't even rely on that. Most of the problems in the project are related to payments and real cart / order / payment flows and the payment processors don't provide sandboxing environment. Cute, right? I tried once to upgrade it to the latest Rails 4.1.* and I drowned a weekend in fuzzy and frustrating tasks I can't even remember anymore, only to give up frustrated after what has practically been almost 3 work days fit in a weekend. My point is, if you want your app not to die by itself (while adding some features and chasing 2-year old bugs that cost your customer money even today) and if you want to modernize it, you _will_ suffer. Not a matter of "if", it's a matter of "how and when". One of my former customers used to say this about rewrites or maintenance: "Both approaches are gonna hurt a lot so we might as well suffer for the right cause". Granted that's not an universal rule but IMO it's quite on point for a good chunk of scenarios.
rrradical 10y ago
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 10y ago
technion 10y ago
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.
- treehau5 10y ago
  I really enjoyed Advi Grimm's "Ruby Tapas" videos because many of his examples did not involve web development at all.
- omgdlight 10y ago
  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 10y ago
    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.
banachtarski 10y ago
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.
- witty_username 10y ago
  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.
  - Ono-Sendai 10y ago
    LLVM has been able to JIT for years. Some fancy stuff might be WIP but the basic support has been there for ages.
    - witty_username 10y ago
      I'm not disputing that. But stuff like hot patching, profiling, etc is in beta or missing. Just compiling on demand is not enough for make dynamic languages fast.
- readittwice 10y ago
  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/ 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.
- rurban 10y ago
ksec 10y ago
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 10y ago
  > So why haven't Github, Shopify, Twitch, Groupon or others pour any resources in ? GitHub does; Tenderlove works on Ruby there!
- herbst 10y ago
  Shopify does too. Just look at their Github
dorianm 10y ago
For those who want ruby-like syntax and native performance, there is crystal: https://crystal-lang.org/ https://crystal-lang.org/
- eropple 10y ago
  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.
iagooar 10y ago
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.
- 59nadir 10y ago
  > 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.
kyledrake 10y ago
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 10y ago
  You must be fun at parties.
  - pwelch 10y ago
    Ha, I wish I could up vote you twice.
    - MrBra 10y ago
      You can: unvote and reupvote.
  - kyledrake 10y ago
    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.

215 points by potomak 10y ago

DamnYuppie 10y ago

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.

ehsanu1 10y ago
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.
- dakull 10y ago
  As they pointed out in the interview - it's not a free meal i.e. one could expect high memory usage and slow start-up times. For me the slow start-up and the JIT requiring ~50K/req for warm-up just ruin the whole experience in coding the app in Ruby I'd rather just use Elixir. Another interesting project is IBM's OMR [0] - compared to JRuby there are no slow start-ups and weirdly, being still a dev. preview it can run Rails and its deps. without issues, even better than Rubinius stable. [0] - https://github.com/rubyomr-preview/rubyomr-preview https://github.com/rubyomr-preview/rubyomr-preview
  - ehsanu1 10y ago
    50k requests seems excessive, are you sure about that? :) Of course it depends on the implementation particulars, and profile-guided optimization may help, but needing a couple thousand requests to warm up is not so bad for a web application server that will see 100x as many requests as that. If we're very lucky, Substrate VM will be released at some point, solving the startup time issues (and I believe many of the JIT issues, though less clear on that): http://lafo.ssw.uni-linz.ac.at/papers/2013_JVMLanguageSummit_OneVMToRuleThemAll.pdf http://lafo.ssw.uni-linz.ac.at/papers/2013_JVMLanguageSummit... The OMR project definitely looks interesting, but it doesn't seem to be actively developed (or perhaps the most recent commits are just not public yet). But if it works that well, then maybe there's no need, hah. Will have to try it out.
    - igravious 10y ago
      > but it doesn't seem to be actively developed The source code is here: https://github.com/rubyomr-preview/ruby https://github.com/rubyomr-preview/ruby Seems the code is being developed internally to IBM. First the docker images of the OMR tech preview were dropped about a year ago. The the source was dropped recently. Targets Ruby 2.2 so I'm going to open an issue asking about targeting 2.3 and folding this work into trunk. $ git clone https://github.com/rubyomr-preview/ruby.git --branch ruby_2_2_omr --recursive $ cd ruby $ autoconf $ ./configure SPEC=linux_x86-64 --with-omr-jit $ make $ make install This should build it for you to try out. I urge others to try it out and give feedback.
      - magaudet 10y ago
        Hey! thanks for the shout out. I would totally love to see more feedback as well! We haven't turned on the issue tracker on that repo, but the glue has it's issues turned on: https://github.com/rubyomr-preview/rbjitglue https://github.com/rubyomr-preview/rbjitglue Working on smoothing this out a bit, and also currently working on upgrading the JIT to target 2.4
        igravious 10y ago
        Thank you for pushing Ruby performance forward! :)
    - magaudet 10y ago
      Hey, OMR developer here. Ruby+OMR is developed in three pieces: 1) the language independent core, then 2) The language dependent portions (i.e., the VM, and what we call the 'glue') The language independent core is here: https://github.com/eclipse/omr https://github.com/eclipse/omr. It's under active development, :) I'm actually working on Ruby 2.4 support right now (supremely not prime time, but if you're curious, the branch is here: https://github.com/mgaudet/ruby/tree/ruby_2_4_omr_preliminary https://github.com/mgaudet/ruby/tree/ruby_2_4_omr_preliminar...)
      - 10y ago
sams99 10y ago
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 10y ago
  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 10y ago
    I did hand tune stuff https://github.com/discourse/discourse_docker/blob/master/templates/web.template.yml#L8-L12 https://github.com/discourse/discourse_docker/blob/master/te... 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.
- riffraff 10y ago
  > Additionally we don't even boot on JRuby today what is the blocking issue there?
- ksec 10y ago
  Can you elaborate a little, given how memory is very cheap these days.
  - specialp 10y ago
    Memory is indeed cheap but the problem is when you run Ruby web services you have every worker taking a minimum of ~400mb. This doesn't sound like much but then with micro-services and other APIs also using that much RAM per worker it adds up fast as all of these servers also need to take this much RAM per concurrent connection you would like to support. For people starting out that is not so much a problem, but if you have moderate to large traffic you need a lot of machines just for the RAM. This is coupled with the fact that many Ruby libraries eschew streaming of files and connections and put things straight into memory despite Ruby having excellent block constructs that easily allow chunking/streaming. So apps also spike in memory and they need a large overhead as well.
MrBra 10y ago
I don't think everyone likes depending on Java.

andy_ppp 10y ago

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 10y ago
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.
- deleted 10y ago
  [deleted]
- deleted 10y ago
  [deleted]
- andy_ppp 10y ago
  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.md https://github.com/mroth/phoenix-showdown/blob/master/README...
sams99 10y ago
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 http://www.joelonsoftware.com/articles/fog0000000069.html
- pdimitar 10y ago
  I would still advocate migration even of 10-year old apps to new languages. You will learn the language and its frameworks better, you'll enrich your neural paths and many other things will suddenly become clearer, and you might even help your customer succeed even more. Worth the shot most of the time, I believe. I am currently tasked with maintaining and upgrading a Spree 2.2 (ancient version) and Rails 4.0.8 (very old) based e-commerce shop and even slight modernizations are extremely painful and have proven impossible. The test suite I inherired is sorely lacking in several areas so I can't even rely on that. Most of the problems in the project are related to payments and real cart / order / payment flows and the payment processors don't provide sandboxing environment. Cute, right? I tried once to upgrade it to the latest Rails 4.1.* and I drowned a weekend in fuzzy and frustrating tasks I can't even remember anymore, only to give up frustrated after what has practically been almost 3 work days fit in a weekend. My point is, if you want your app not to die by itself (while adding some features and chasing 2-year old bugs that cost your customer money even today) and if you want to modernize it, you _will_ suffer. Not a matter of "if", it's a matter of "how and when". One of my former customers used to say this about rewrites or maintenance: "Both approaches are gonna hurt a lot so we might as well suffer for the right cause". Granted that's not an universal rule but IMO it's quite on point for a good chunk of scenarios.

rrradical 10y ago

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 10y ago

technion 10y ago

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.

treehau5 10y ago
I really enjoyed Advi Grimm's "Ruby Tapas" videos because many of his examples did not involve web development at all.
omgdlight 10y ago
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 10y ago
  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.

banachtarski 10y ago

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.

witty_username 10y ago
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.
- Ono-Sendai 10y ago
  LLVM has been able to JIT for years. Some fancy stuff might be WIP but the basic support has been there for ages.
  - witty_username 10y ago
    I'm not disputing that. But stuff like hot patching, profiling, etc is in beta or missing. Just compiling on demand is not enough for make dynamic languages fast.
readittwice 10y ago
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/ 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.
rurban 10y ago

ksec 10y ago

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 10y ago
> So why haven't Github, Shopify, Twitch, Groupon or others pour any resources in ? GitHub does; Tenderlove works on Ruby there!
herbst 10y ago
Shopify does too. Just look at their Github

dorianm 10y ago

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

eropple 10y ago
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.

iagooar 10y ago

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.

59nadir 10y ago
> 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.

kyledrake 10y ago

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 10y ago
You must be fun at parties.
- pwelch 10y ago
  Ha, I wish I could up vote you twice.
  - MrBra 10y ago
    You can: unvote and reupvote.
- kyledrake 10y ago
  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.