Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ruby 3.3

ruby-lang.org

Post reply on HN
Print view View original

31–40 of 277 posts

Re: Ruby 3.3

#31

Post by xpressvideoz »

> Name resolution such as `Socket.getaddrinfo` can now be interrupted. Whenever it needs name resolution, it creates a worker pthread, and executes `getaddrinfo(3)` in it.

Do other language runtimes do similar things? Creating a thread sounds too heavy, though it might not matter in practice. As per their own benchmark, the overhead is minimal but still not zero.

  10000.times { 
  Addrinfo.getaddrinfo("www.ruby- 
  lang.org", 80) }
  # Before patch: 2.3 sec.
  # After ptach: 3.0 sec.

  100.times { 
  URI.open("https://www.ruby-lang.org").read }
  # Before patch: 3.36 sec.
  # After ptach: 3.40 sec.

Re: Ruby 3.3

#32

Post by Alifatisk »

ksec wrote: post #2

I think Ruby 3.3 is perhaps one of the most important and feature rich Ruby release in the past 10 years. I never thought Ruby would have a shipping and production ready JIT before Python. And Prism, Lrama, IRB. A lot of these were discussed in previous HN submissions. But one thing that is not mentioned or discussed enough, is Ractor, M:N thread scheduler, Fibre and Async. Especially in the context of Rails. I am wo…

> I think Ruby 3.3 is perhaps one of the most important and feature rich Ruby release in the past 10 years.

Really? What’s so significant with this release?

> But one thing that is not mentioned or discussed enough, is Ractor, M:N thread scheduler, Fibre and Async.

Yes! Ractors deserve more highlighting! It’s a huge feature.

Re: Ruby 3.3

#33

Post by keithalewis »

byroot wrote: post #14
rjzzleep wrote: post #13

Earlier quoted context omitted.

The one thing I genuinely don't understand is why there is no single task queue that works across ruby and python. I get that at some point people just started making http based microservices to pass information around, but at the end of the day a simple task queue that has a unified storage format across both is a better way to connect ruby(rails) based with the ml stack. There are probably thousands of custom rabbi…

Mike Perham (the sidekiq maintainer) also maintains the less well known faktory[0] which is language agnostic and has runners for both Ruby and Python [0] https://github.com/contribsys/faktory

This relies on the Go runtime scheduler. Sometimes that is not good enough.

Re: Ruby 3.3

#34

Post by mypalmike »

hetman wrote: post #12
Calavar wrote: post #11

Earlier quoted context omitted.

You're right, implicit import (autoload) is an opt-in feature. Rails used to use autoload by default as of 3.x/4.x. It's been quite a while since I used Rails, so I'm not sure if this is still the case. Ruby imports have always used a single global namespace. I'm not convinced that this is an issue in practice - it's worked just fine for several other languages.

I mean, only because it's possible to learn to live with doesn't make it pleasant. Especially for managing large projects it can get unwieldy. Most high level languages I can think of have moved away from this approach. I used to be a huge Ruby fan but having exposure to Python where this isn't an issue, life is just easier.

I agree, but Ruby folks seem to consider C style transitive inclusion to be a feature. I found it and several other aspects of Ruby to be maddening (and productivity-sapping) for the 1.5 years I spent with an otherwise pretty nice language.

Re: Ruby 3.3

#35

Post by Alifatisk »

xpressvideoz wrote: post #31

> Name resolution such as `Socket.getaddrinfo` can now be interrupted. Whenever it needs name resolution, it creates a worker pthread, and executes `getaddrinfo(3)` in it. Do other language runtimes do similar things? Creating a thread sounds too heavy, though it might not matter in practice. As per their own benchmark, the overhead is minimal but still not zero. 10000.times { Addrinfo.getaddrinfo("www.ruby- lang.org…

Wouldn’t a fiber be more lightweight than having to create a new thread?

Re: Ruby 3.3

#36

Post by byroot »

Alifatisk wrote: post #35
xpressvideoz wrote: post #31

> Name resolution such as `Socket.getaddrinfo` can now be interrupted. Whenever it needs name resolution, it creates a worker pthread, and executes `getaddrinfo(3)` in it. Do other language runtimes do similar things? Creating a thread sounds too heavy, though it might not matter in practice. As per their own benchmark, the overhead is minimal but still not zero. 10000.times { Addrinfo.getaddrinfo("www.ruby- lang.org…

Wouldn’t a fiber be more lightweight than having to create a new thread?

A fiber doesn't have a dedicated execution context, so it would be just as blocking.

Re: Ruby 3.3

#37

Post by rfoo »

ksec wrote: post #2

I think Ruby 3.3 is perhaps one of the most important and feature rich Ruby release in the past 10 years. I never thought Ruby would have a shipping and production ready JIT before Python. And Prism, Lrama, IRB. A lot of these were discussed in previous HN submissions. But one thing that is not mentioned or discussed enough, is Ractor, M:N thread scheduler, Fibre and Async. Especially in the context of Rails. I am wo…

> I never thought Ruby would have a shipping and production ready JIT before Python.

This is entirely predictable - Ruby does not have a big scientific computing community which happened to depend on every implementation detail of the hosting interpreter.

Re: Ruby 3.3

#38

Post by Lio »

Alifatisk wrote: post #32
ksec wrote: post #2

I think Ruby 3.3 is perhaps one of the most important and feature rich Ruby release in the past 10 years. I never thought Ruby would have a shipping and production ready JIT before Python. And Prism, Lrama, IRB. A lot of these were discussed in previous HN submissions. But one thing that is not mentioned or discussed enough, is Ractor, M:N thread scheduler, Fibre and Async. Especially in the context of Rails. I am wo…

> I think Ruby 3.3 is perhaps one of the most important and feature rich Ruby release in the past 10 years. Really? What’s so significant with this release? > But one thing that is not mentioned or discussed enough, is Ractor, M:N thread scheduler, Fibre and Async. Yes! Ractors deserve more highlighting! It’s a huge feature.

> Really? What’s so significant with this release?

I think the Prism parser update is a standout highlight for me. This is the start of many new static analysis tools for ruby.

It's also significant that RBS type information is starting to be used in IRB autocompletion. Previously RBS has been an interesting experiment but hasn't had much practical use compared to Sorbet.

Ruby seems to now have good answers to non-blocking IO (async fibers) and tooling questions (ruby-lsp). We're starting to see YJIT performance improvements starting to compound with more to come too.

That all seems significant to me. Thanks to everyone involved.

Re: Ruby 3.3

#39

Post by byroot »

rfoo wrote: post #37
ksec wrote: post #2

I think Ruby 3.3 is perhaps one of the most important and feature rich Ruby release in the past 10 years. I never thought Ruby would have a shipping and production ready JIT before Python. And Prism, Lrama, IRB. A lot of these were discussed in previous HN submissions. But one thing that is not mentioned or discussed enough, is Ractor, M:N thread scheduler, Fibre and Async. Especially in the context of Rails. I am wo…

> I never thought Ruby would have a shipping and production ready JIT before Python. This is entirely predictable - Ruby does not have a big scientific computing community which happened to depend on every implementation detail of the hosting interpreter.

I don't see how it's relevant given that YJIT didn't cause any compatibility issue whatsoever.

Re: Ruby 3.3

#40

Post by ciconia »

IshKebab wrote: post #25
ciconia wrote: post #18

I believe with version 3.3 Ruby is back in a big way! The language focused on developer happiness and derided for its slowness is slow no more. YJIT is an amazing technology, and together with other innovations like object shapes and various GC optimizations, Ruby is becoming seriously fast! Big Ruby shops such as Shopify [1] have been running 3.3 pre-release with YJIT and reporting double digit percentage performanc…

> double digit performance improvements You mean like 10% faster, or 10x faster? Edit: clicked the link; it's 10%. I don't think that's going to make any difference to the perception of Ruby's slowness given that it's on the order of 50-200x slower than "fast" languages like Rust, Java, Go and C++.

Note this is for a Ruby on Rails application. The slowness is I believe more due to the framework than the language runtime. In any case, it's still early to determine the impact on performance from upgrading to Ruby 3.3. I guess we'll be able to tell more in the coming months.
Post reply on HN