4 ms·

> mediocre performance, no type definitions, and no evented I/O baked into the language Ruby 3 addresses each of those issues. https://www.ruby-lang.org/en/ne

• tinco 6y ago
  Definitely interesting new features, and Ruby is putting up a good fight. But if it was really a ruby feature, and not just something tacked on to stay relevant, that code example would've looked like this: require 'async' require 'net/http' require 'uri' ["ruby", "rails", "async"].each.parallel do |topic| Net::HTTP.get(URI "https://www.google.com/search?q=#{topic}") end I can't tell someone Ruby is beautiful, and then in the next sentence explain how you need to type Async twice just to get something to run asynchronously. Same of course for Ruby types, we're just not yet on the point for a truly new way of writing Ruby for Ruby 3. Maybe we'll finally get something like this could be in Ruby 4, but I fear the spectre of backwards incompatibility is going to stand in the way of something that's both truly Ruby and truly in the 2020's.
  • d3nj4l 6y ago
    Amen. As a massive ruby fan, I couldn’t put a finger on why I disliked ruby async, but you’ve got it exactly right.
• jokethrowaway 6y ago
  I think the main problem with ruby is that JS has Google v8's performance behind it. Good luck matching that. Then, if we're talking rails (which is a significant part of the ruby projects out there), there is way too much magic going on. Magic you have to manually un-peel when something goes wrong.