8 ms·

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 reall

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

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