9 ms·

A first naïve look at Truffle Ruby

news_to_me 9y ago
I hadn't heard of Truffle Ruby before now — it looks pretty awesome. My experience with ruby has so far been limited, but as much as I've used it, I don't really see any downsides to the language except speed (for web applications, anyway).
- thibaut_barrere 9y ago
  I think it's on a right track to be quite something, which is why I wanted to try it out & mention that on HN. It's interesting to note that on the "classic" Ruby, there is work ongoing in 2.6 to accelerate it quite a bit (MJIT). The current PR for this is there: https://github.com/ruby/ruby/pull/1782 https://github.com/ruby/ruby/pull/1782 Even before that, Ruby is getting faster, you'll get running times from 2.0.0 to 2.5.0 for a little benchmark I made here: https://github.com/thbar/kiba-ruby-benchmarks https://github.com/thbar/kiba-ruby-benchmarks
  - octonion 9y ago
    Have you tried Crystal? I've been very impressed by it.
    - thibaut_barrere 9y ago
      Yes - I've tried & I like it. I used it for some specific bits. That said so far, I've been unable to properly port the gem I mention in the post (Kiba) to it, despite a couple of attempts.
- iagooar 9y ago
  Things I dislike the most about Ruby: - Raw performance - Runtime metaprogramming from hell - Monkey patching - No real concurrency support, tons of non-threadsafe code and gems - Too Rails-centric - Little presence outside web development - Little to no real innovation in the last years - Mutability - No optional / progressive types or type annotations === Things I love about Ruby: - Clean syntax - Although it's object oriented, it allows using a functional style - Functional collection operations - Productivity - Flexibility - Maturity - Availability of high-quality libraries - Availability of hosting solutions - Friendly community - Nice stack traces
  - thibaut_barrere 9y ago
    As usual, it's all about tradeoffs. I use other languages too (Elixir, a bit of Rust, Go, Javascript etc). When the tradeoffs match your needs, Ruby is excellent. But then addressing your points: - Raw performance is improving (see my other post) - Monkey patching is less and less frequent (I'm maintaining pure Ruby, but also Rails app since 2005), is generally considered a bad practice - Rails-centrism is gradually becoming a thing of the past (see gems like Hanami, Roda, Sequel, Kiba, dry-rb etc) - Runtime metaprogramming brings a lot of benefits when properly used! - Threadsafety (I'm the first to mention that) has gradually gotten much better So well - we're getting somewhere!
    - RangerScience 9y ago
      "Refinements" are the "cleaner" version of monkey-patching. These are (AFAIK) a big part of the magic in Ruby testing frameworks.
      - semiquaver 9y ago
        Apologies if I'm wrong here, but I don't believe any of the major ruby test frameworks use refinements at all. Since they are lexically scoped they end up being too verbose to be useful for this purpose. In other words, you would need to have a series of `using MyRefiningModule` statements in every single test file. Perhaps you were thinking of rspec's changes in the last few years. They have been moving away from monkeypatching with some changes to their syntax. Previously they defined `Object#should` and handled assertions using syntax like `my_var.should eq(1)`. The new approach, which does not use refinements, is to handle assertions using a wrapper method that works like `expect(my_var).to eq(1)`. No refinements necessary for that though.
    - eropple 9y ago
      As I often note when this comes up, I've never actually written a Rails app. I've been writing Ruby for about five years now. A huge chunk of the devops world is written in Ruby (probably about the same in Go, much less in Python). It's still the "Perl of the future" and you'll find it all over the place. Rails is still big, especially in America--but there's a lot of other very influential stuff to it. If you're doing web there are other (I would say better, unless you're making Basecamp) libraries that do very well, too. Hanami is cool, Grape is good, and I'm in the process of building a Rack framework called `Modern` that's intended to be a turn-key, OpenAPI3-compatible framework to make the creation of API clients on the other hand a trivial experience.
- TomK32 9y ago
  What kind of speed are you looking for? Speed of the application in production, or the speed at which a developer can implement it? What will cost you more, a few more servers or a few more programmers?
  - rrdharan 9y ago
    You can't always add a few more servers. For example, let's say you have a per-request processing budget of 100ms. The efficiency of the generated code for your language of choice effectively limits the amount of (non-concurrent, single threaded) code you can run while processing said request. It's exactly this limit that eventually leads engineering teams at your Dropboxes, Facebooks, Twitters, Tumblrs, etc. to start investigating alternatives or alternative implementations of their favorite dynamic languages (PHP/Python/Ruby -> HHVM/Pyston/?).
    - NoPiece 9y ago
      It's exactly this limit that eventually leads engineering teams at your Dropboxes, Facebooks, Twitters, Tumblrs True, but those are such extreme edge cases. 99.9999% of projects will never see that kind of demand for scale and speed. Facebook shouldn't switch to Ruby, but that doesn't inform whether Ruby would be viable for many (most) projects.
      - nirvdrum 9y ago
        I don't think it's that much of an edge case. If Rails and its ecosystem lead to 300ms render times without load, but your objective is 100ms, you're going to have a problem. I don't think either number here is extreme and I've encountered that sort of situation on previous projects. It's not easily solvable by throwing more machines at it, unfortunately.
        tomc1985 9y ago
        If Rails and your ecosystem are pushing 300ms renders you have bigger problems on your plate
pelasaco 9y ago
The best "Ruby" at the time is Crystal..no doubt
grover_hartmann 9y ago
It always bothered me that Ruby isn't used as much as Python is used outside of web development. I think Ruby is a nicer language than Python is in many ways.
- busterarm 9y ago
  Lots of operations code was written in Ruby. Just look at Chef, Capistrano and Puppet. That whole field wants to be Google though and thinks they have Google's problems, so now it's mostly all Python and Go. HashiCorp has written some great stuff at least.
  - dictum 9y ago
    > That whole field wants to be Google though and thinks they have Google's problems It's becoming a recurring phenonemon, isn't it? I feel the same with frontend web development: everyone wants to be Facebook.
    - busterarm 9y ago
      preaching to the f'ing choir here mate. The volume of material out there written to help people improve the performance of their React applications makes it pretty clear to me that folks aren't looking before they leap. I've seen more than a couple dozen projects with ~20-40 lines of simple, performant, vanilla JS turn into multi-hundred line behemoths + _an entire React framework_ for exactly zero benefit to end users because of "best practices".
  - Twirrim 9y ago
    > That whole field wants to be Google though and thinks they have Google's problems, so now it's mostly all Python and Go Python has been more relevant in operations work for quite a while, and for a lot longer Google has been talking about their use of it. (speaking as someone with approaching 2 decades experience on the sysadmin/operations side of work) Readability and ease of learning were big bonuses, particularly given sysadmin types were historically more likely to fall in to the work, and as likely to not have formal compsci backgrounds. That it also made life a heck of a lot easier to interact with APIs was also invaluable. Perl used to be an incredible pain for API work (I learnt python and wrote automation around APIs in less time than it took me as an experienced perl programmer to write similar tooling in perl.) You also have to remember that python has perl's advantage, it's everywhere. Every major Linux distro has shipped with it for a long time. I'm rusty on that specific aspect historically, I would guess it's probably due to Redhat and all their automation being historically python based.
vertis 9y ago
It's a bit sad that my first reaction is to go, "oh it's Oracle" and then look at the license. It's GPL LGPL and Eclipse, which is convoluted but otherwise uninteresting.
- chrisseaton 9y ago
  It's GPL or LGPL or Eclipse. You can pick whichever you want - it's not a convolution of all three. The licence comes from JRuby, which we forked from.

I hadn't heard of Truffle Ruby before now — it looks pretty awesome. My experience with ruby has so far been limited, but as much as I've used it, I don't really see any downsides to the language except speed (for web applications, anyway).

thibaut_barrere 9y ago
I think it's on a right track to be quite something, which is why I wanted to try it out & mention that on HN. It's interesting to note that on the "classic" Ruby, there is work ongoing in 2.6 to accelerate it quite a bit (MJIT). The current PR for this is there: https://github.com/ruby/ruby/pull/1782 https://github.com/ruby/ruby/pull/1782 Even before that, Ruby is getting faster, you'll get running times from 2.0.0 to 2.5.0 for a little benchmark I made here: https://github.com/thbar/kiba-ruby-benchmarks https://github.com/thbar/kiba-ruby-benchmarks
- octonion 9y ago
  Have you tried Crystal? I've been very impressed by it.
  - thibaut_barrere 9y ago
    Yes - I've tried & I like it. I used it for some specific bits. That said so far, I've been unable to properly port the gem I mention in the post (Kiba) to it, despite a couple of attempts.
iagooar 9y ago
Things I dislike the most about Ruby: - Raw performance - Runtime metaprogramming from hell - Monkey patching - No real concurrency support, tons of non-threadsafe code and gems - Too Rails-centric - Little presence outside web development - Little to no real innovation in the last years - Mutability - No optional / progressive types or type annotations === Things I love about Ruby: - Clean syntax - Although it's object oriented, it allows using a functional style - Functional collection operations - Productivity - Flexibility - Maturity - Availability of high-quality libraries - Availability of hosting solutions - Friendly community - Nice stack traces
- thibaut_barrere 9y ago
  As usual, it's all about tradeoffs. I use other languages too (Elixir, a bit of Rust, Go, Javascript etc). When the tradeoffs match your needs, Ruby is excellent. But then addressing your points: - Raw performance is improving (see my other post) - Monkey patching is less and less frequent (I'm maintaining pure Ruby, but also Rails app since 2005), is generally considered a bad practice - Rails-centrism is gradually becoming a thing of the past (see gems like Hanami, Roda, Sequel, Kiba, dry-rb etc) - Runtime metaprogramming brings a lot of benefits when properly used! - Threadsafety (I'm the first to mention that) has gradually gotten much better So well - we're getting somewhere!
  - RangerScience 9y ago
    "Refinements" are the "cleaner" version of monkey-patching. These are (AFAIK) a big part of the magic in Ruby testing frameworks.
    - semiquaver 9y ago
      Apologies if I'm wrong here, but I don't believe any of the major ruby test frameworks use refinements at all. Since they are lexically scoped they end up being too verbose to be useful for this purpose. In other words, you would need to have a series of `using MyRefiningModule` statements in every single test file. Perhaps you were thinking of rspec's changes in the last few years. They have been moving away from monkeypatching with some changes to their syntax. Previously they defined `Object#should` and handled assertions using syntax like `my_var.should eq(1)`. The new approach, which does not use refinements, is to handle assertions using a wrapper method that works like `expect(my_var).to eq(1)`. No refinements necessary for that though.
  - eropple 9y ago
    As I often note when this comes up, I've never actually written a Rails app. I've been writing Ruby for about five years now. A huge chunk of the devops world is written in Ruby (probably about the same in Go, much less in Python). It's still the "Perl of the future" and you'll find it all over the place. Rails is still big, especially in America--but there's a lot of other very influential stuff to it. If you're doing web there are other (I would say better, unless you're making Basecamp) libraries that do very well, too. Hanami is cool, Grape is good, and I'm in the process of building a Rack framework called `Modern` that's intended to be a turn-key, OpenAPI3-compatible framework to make the creation of API clients on the other hand a trivial experience.
TomK32 9y ago
What kind of speed are you looking for? Speed of the application in production, or the speed at which a developer can implement it? What will cost you more, a few more servers or a few more programmers?
- rrdharan 9y ago
  You can't always add a few more servers. For example, let's say you have a per-request processing budget of 100ms. The efficiency of the generated code for your language of choice effectively limits the amount of (non-concurrent, single threaded) code you can run while processing said request. It's exactly this limit that eventually leads engineering teams at your Dropboxes, Facebooks, Twitters, Tumblrs, etc. to start investigating alternatives or alternative implementations of their favorite dynamic languages (PHP/Python/Ruby -> HHVM/Pyston/?).
  - NoPiece 9y ago
    It's exactly this limit that eventually leads engineering teams at your Dropboxes, Facebooks, Twitters, Tumblrs True, but those are such extreme edge cases. 99.9999% of projects will never see that kind of demand for scale and speed. Facebook shouldn't switch to Ruby, but that doesn't inform whether Ruby would be viable for many (most) projects.
    - nirvdrum 9y ago
      I don't think it's that much of an edge case. If Rails and its ecosystem lead to 300ms render times without load, but your objective is 100ms, you're going to have a problem. I don't think either number here is extreme and I've encountered that sort of situation on previous projects. It's not easily solvable by throwing more machines at it, unfortunately.
      - tomc1985 9y ago
        If Rails and your ecosystem are pushing 300ms renders you have bigger problems on your plate

pelasaco 9y ago

The best "Ruby" at the time is Crystal..no doubt

grover_hartmann 9y ago

It always bothered me that Ruby isn't used as much as Python is used outside of web development. I think Ruby is a nicer language than Python is in many ways.

busterarm 9y ago
Lots of operations code was written in Ruby. Just look at Chef, Capistrano and Puppet. That whole field wants to be Google though and thinks they have Google's problems, so now it's mostly all Python and Go. HashiCorp has written some great stuff at least.
- dictum 9y ago
  > That whole field wants to be Google though and thinks they have Google's problems It's becoming a recurring phenonemon, isn't it? I feel the same with frontend web development: everyone wants to be Facebook.
  - busterarm 9y ago
    preaching to the f'ing choir here mate. The volume of material out there written to help people improve the performance of their React applications makes it pretty clear to me that folks aren't looking before they leap. I've seen more than a couple dozen projects with ~20-40 lines of simple, performant, vanilla JS turn into multi-hundred line behemoths + _an entire React framework_ for exactly zero benefit to end users because of "best practices".
- Twirrim 9y ago
  > That whole field wants to be Google though and thinks they have Google's problems, so now it's mostly all Python and Go Python has been more relevant in operations work for quite a while, and for a lot longer Google has been talking about their use of it. (speaking as someone with approaching 2 decades experience on the sysadmin/operations side of work) Readability and ease of learning were big bonuses, particularly given sysadmin types were historically more likely to fall in to the work, and as likely to not have formal compsci backgrounds. That it also made life a heck of a lot easier to interact with APIs was also invaluable. Perl used to be an incredible pain for API work (I learnt python and wrote automation around APIs in less time than it took me as an experienced perl programmer to write similar tooling in perl.) You also have to remember that python has perl's advantage, it's everywhere. Every major Linux distro has shipped with it for a long time. I'm rusty on that specific aspect historically, I would guess it's probably due to Redhat and all their automation being historically python based.

vertis 9y ago

It's a bit sad that my first reaction is to go, "oh it's Oracle" and then look at the license. It's GPL LGPL and Eclipse, which is convoluted but otherwise uninteresting.

chrisseaton 9y ago
It's GPL or LGPL or Eclipse. You can pick whichever you want - it's not a convolution of all three. The licence comes from JRuby, which we forked from.