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

11–20 of 277 posts

Re: Ruby 3.3

#11

Post by Calavar »

t-writescode wrote: post #7
revskill wrote: post #5

I hope Ruby 4.0 could allow explicit import and avoid implicit, global namespace gem import mechanism like nowsdays.

I'm feeling a bit ignorant, but isn't this a Rails thing and not a Ruby thing? I know that for most projects that's a distinction without a difference; but, that may be a decision from the Rails devs and unrelated to what Ruby's devs do? Or I'm speaking out of my ear and completely wrong (and I don't know which :D)

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.

Re: Ruby 3.3

#12

Post by hetman »

Calavar wrote: post #11
t-writescode wrote: post #7

Earlier quoted context omitted.

I'm feeling a bit ignorant, but isn't this a Rails thing and not a Ruby thing? I know that for most projects that's a distinction without a difference; but, that may be a decision from the Rails devs and unrelated to what Ruby's devs do? Or I'm speaking out of my ear and completely wrong (and I don't know which :D)

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.

Re: Ruby 3.3

#13

Post by rjzzleep »

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…

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 rabbitmq or redis based private company solutions out there.

Re: Ruby 3.3

#14

Post by byroot »

rjzzleep wrote: post #13
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…

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

Re: Ruby 3.3

#15

Post by oleg_antonyan »

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.

It's a matter of personal preference and/or which one you've learnt to live with first.

I like how Ruby's imports work - just load a file, similar to C. On the other hand, modules in Python always felt like something to overcome rather than "just works as you expect".

Re: Ruby 3.3

#16

Post by ckolkey »

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.

To each their own, I guess. After working with python/lua, I really appreciate not needing to do manual imports all over. I'm glad ruby makes this so easy :)

Oh, and not needing __init__.py files in order to import something. Goodness, what an absolute pain.

Re: Ruby 3.3

#18

Post by ciconia »

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 performance improvements.

Personally I'm really excited about Ruby and its future. I can't wait to start working with Ruby 3.3 and using it on my client's production sites...

[1] https://railsatscale.com/2023-09-18-ruby-3-3-s-yjit-runs-sho...

Edit: add percentage to performance improvements.

Re: Ruby 3.3

#19

Post by rjzzleep »

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

That's awesome. Any idea why he doesn't just supersede Sidekiq with that? I spent quite some time hacking my own solution.

I just looked at the source, I guess Mike has been mostly working on both projects on his own for the last 4 years, so Faktory has a lot of features that require the enterprise license.

I wonder if he could change the situation it he markets a bit more to the python and more specifically Django community.

Re: Ruby 3.3

#20

Post by nextaccountic »

> RUBY_MAX_CPU=n environment variable sets maximum number of N (maximum number of native threads). The default value is 8.

Shouldn't the default be the number of logical cores? Like Rust's Tokio and countless other M:N runtimes

Post reply on HN