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

51–60 of 277 posts

Re: Ruby 3.3

#51

Post by viraptor »

Alifatisk wrote: post #47
byroot wrote: post #36

Earlier quoted context omitted.

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

Is there really no other way than creating a whole thread for this?

You can use a pure ruby resolver if you want. For example https://github.com/socketry/async-dns

But that way your sacrificing integration into your system's nsswitch which may want to do something completely different with your requests.

You could also query over dbus which can be async https://www.freedesktop.org/software/systemd/man/latest/org.... (if you can depend on systemd)

Re: Ruby 3.3

#52

Post by byroot »

Alifatisk wrote: post #47
byroot wrote: post #36

Earlier quoted context omitted.

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

Is there really no other way than creating a whole thread for this?

There is a few alternatives like getaddrinfo_a(3) but they have other downsides (fork safety concerns).

If you want more context, you can read: https://bugs.ruby-lang.org/issues/19430

Re: Ruby 3.3

#53

Post by Alifatisk »

pdimitar wrote: post #49
Alifatisk wrote: post #28

Earlier quoted context omitted.

I seriously don’t think it’s worth comparing Ruby to languages like C++ and the rest. One is scripting language, the other compiled, the difference is huge already there.

> I seriously don’t think it’s worth comparing Ruby to languages like C++ and the rest. It is worth comparing any two languages and ecosystems if they are used for the same things, in this case -- web backends. Anything and everything that has a web backend is a fair game for comparison.

> It is worth comparing any two languages and ecosystems if they are used for the same things, in this case -- web backends.

Right I see your point, but in this case it’s about Ruby, the language itself, not RoR.

Re: Ruby 3.3

#54

Post by Alifatisk »

pdimitar wrote: post #50
ciconia wrote: post #40

Earlier quoted context omitted.

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.

> Note this is for a Ruby on Rails application. The slowness is I believe more due to the framework than the language runtime. Hardly relevant, I'd think at least 80% of all Ruby usage everywhere is in Ruby on Rails applications.

It is relevant if the cause of the slowness is due to the framework rather than the language itself.

The performance can vary drastically depending on which Ruby framework you use, so it's not due to the language but the upper layer instead.

Note, even if Rails is the most popular framework, there is still other alternatives which makes it even more relevant to the performance impact.

Re: Ruby 3.3

#55

Post by f6v »

rjzzleep wrote: post #19
byroot wrote: post #14

Earlier quoted context omitted.

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 c…

Because people running sidekiq with their Ruby app on production don’t care about cross-language queue. If you pay for Pro or Enterprise you don’t want any major changes that are potentially breaking.

Re: Ruby 3.3

#56

Post by cactusplant7374 »

f6v wrote: post #55
rjzzleep wrote: post #19

Earlier quoted context omitted.

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 c…

Because people running sidekiq with their Ruby app on production don’t care about cross-language queue. If you pay for Pro or Enterprise you don’t want any major changes that are potentially breaking.

The only reason we pay is because the pro version doesn't lose jobs if a worker crashes. You would think that would be a core feature.

Re: Ruby 3.3

#58

Post by resonious »

Alifatisk wrote: post #54
pdimitar wrote: post #50

Earlier quoted context omitted.

> Note this is for a Ruby on Rails application. The slowness is I believe more due to the framework than the language runtime. Hardly relevant, I'd think at least 80% of all Ruby usage everywhere is in Ruby on Rails applications.

It is relevant if the cause of the slowness is due to the framework rather than the language itself. The performance can vary drastically depending on which Ruby framework you use, so it's not due to the language but the upper layer instead. Note, even if Rails is the most popular framework, there is still other alternatives which makes it even more relevant to the performance impact.

I suspect there's not just one cause of slowness here. Pure language benchmarks also tend to rank Ruby very low. So I'd wager that a fast Ruby framework would still lose to a fast Go framework.

Re: Ruby 3.3

#59

Post by jitl »

999900000999 wrote: post #57

Worth it to learn Ruby if you already know Python and NodeJS ? I find Ruby fascinating yet difficult.

I think Ruby is much better at shell script like tasks and interactive / exploratory programming for system tasks compared to Python or Node. Use it as “better bash” or “better Perl” and it’s worth it. I primarily work in a Typescript codebase, but regularly reach for it as a tool to wrangle log data, semi-structured text, or do regex rewrites of a bunch of files.

Ruby is also very fun, probably the most fun language I’ve used regularly. That makes it its own reward.

Re: Ruby 3.3

#60

Post by Alifatisk »

resonious wrote: post #58
Alifatisk wrote: post #54

Earlier quoted context omitted.

It is relevant if the cause of the slowness is due to the framework rather than the language itself. The performance can vary drastically depending on which Ruby framework you use, so it's not due to the language but the upper layer instead. Note, even if Rails is the most popular framework, there is still other alternatives which makes it even more relevant to the performance impact.

I suspect there's not just one cause of slowness here. Pure language benchmarks also tend to rank Ruby very low. So I'd wager that a fast Ruby framework would still lose to a fast Go framework.

Absolutely, I should maybe clarify that I did not mean to say that we can fully rule out the language itself as a cause of the poor performance, Ruby always perform worse than Go in this example for obvious reasons.

But, saying that the frameworks using the language under the hood has almost no relevancy is wrong in my opinion! And that is what I was trying to point out.

Post reply on HN