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

231–240 of 277 posts

Re: Ruby 3.3

#231

Post by pdimitar »

ajmurmann wrote: post #161
pdimitar wrote: post #129

Earlier quoted context omitted.

That is true, yes, but still comparing e.g. Rust vs. Ruby I'd think Rust spends anywhere from 10ns to 100ns (outside of waiting on DB) and Ruby no less than 10 ms. Still pretty significant and can add up during times of big load. Also I remember Rails' ActiveRecord having some pretty egregious performance footprint (we're talking 10ms to 100ms on top of DB waiting) but I hear that was fixed a while ago.

My point was that if we look at Rails performance going up 10%, what does that mean for time spent in Ruby. I'd believe anything from a 15% to a 80% reduction of time spent in Ruby code

I haven't seen 80% anywhere in the linked article[0] so let's use facts and not beliefs.

It is possible Ruby itself got accelerated a lot, okay, I am just not sure that's relevant since almost all Ruby usage is Rails.

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

Re: Ruby 3.3

#232

Post by pdimitar »

Alifatisk wrote: post #60
resonious wrote: post #58

Earlier quoted context omitted.

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.

> But, saying that the frameworks using the language under the hood has almost no relevancy is wrong in my opinion!

I did not claim that in general sense, I said it with the context that even if Ruby got accelerated a lot then that's still kind of inconsequential because most Ruby usage is Rails.

Re: Ruby 3.3

#233

Post by Lio »

wredue wrote: post #126
the_gastropod wrote: post #108

Earlier quoted context omitted.

But, like, why do you need a 1MB json response? That’s probably either a bad design or a use-case Rails is not designed for.

The better question is “Why would I pointlessly accept this clear case of massive technical debt for literally no reason what-so-ever?” Rails does not present any sort of promise that go does not also present, so just saying “yeah, I’ll handcuff my app like this cause I feel like using Ruby” is, frankly, absurd. When you ask the right questions, you never land on Ruby, and that’s why Ruby continues to decline.

It depends on the metrics you care about.

Ruby is concise compared to Go though. I like Go and but when I use it I have to accept that I'll write (and debug) at twice as much code as I would do in Ruby.

If you're mostly just loading data into a large fast cache, lines of code may be a more critical dimension than execution speed.

That's how well designed Rails projects work and you get most of what you need straight out of the box.

Re: Ruby 3.3

#234

Post by pdimitar »

csjh wrote: post #107
cutler wrote: post #93

Earlier quoted context omitted.

Apples to oranges again. A more relevant comparison would be Ruby to Python and in recent years Ruby has edged ahead in performance if you factor-out Python's C-based libraries such as Numpy.

Isn’t factoring out C based libraries ignoring a large part of the Python ecosystem?

How is a C codebase a part of the Python ecosystem?

More accurate statement would be: Python is piggy-backing on hugely successful C libraries and claims big performance on their backs, IMO.

Re: Ruby 3.3

#235

Post by pdimitar »

wredue wrote: post #180
cutler wrote: post #140

Earlier quoted context omitted.

But you factored-out developer productivity. What you gain in reduced server costs is lost many times over in developer productivity. Companies who chose Rails for decades knew it was slower and more memory-hungry than rolling everything yourself in Rust or C++. They did the math and the business case for Rails was more compelling.

Rails is no more productive than go, and a developer taking 20 extra minutes (frankly, not likely, even if we’re talking rust) to write go rather than Ruby is not going to cost more than the $1000 a month the extra Ruby servers cost you just to run. “But but but developer productivity” is a myth.

It's not a complete myth. But I'd agree that it's overblown and overly touted.

Re: Ruby 3.3

#236

Post by pdimitar »

hello_moto wrote: post #174
wredue wrote: post #130

Earlier quoted context omitted.

Nah. One rust based server can power the same number of connections as 10-100 ruby based servers. This is not just “pretend database IO” problem. This is actual cost that no business should accept on the basis of “but but but database IO (that I’ve never actually measured, but it’s an easy cop out because I read it on medium once).

I'd choose Go and Java any given day before Rust. That language with C++ mindset is just... horrible.

They all have their niches. Rust is difficult but rewards you for your persistence.

I do appreciate Rust a lot but nowadays find myself reaching for Golang more often. I simply don't have the extra time and energy to learn the final more advanced Rust pieces in my own leisure time so I'll learn it whenever I can but yeah, in the meantime: Golang to the rescue.

Re: Ruby 3.3

#237

Post by pdimitar »

Alifatisk wrote: post #53
pdimitar wrote: post #49

Earlier quoted context omitted.

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

Not denying it, I just struggle to find any non-RoR usage of Ruby out there except maybe for Homebrew.

Re: Ruby 3.3

#238

Post by Lio »

csjh wrote: post #107
cutler wrote: post #93

Earlier quoted context omitted.

Apples to oranges again. A more relevant comparison would be Ruby to Python and in recent years Ruby has edged ahead in performance if you factor-out Python's C-based libraries such as Numpy.

Isn’t factoring out C based libraries ignoring a large part of the Python ecosystem?

It's not that you should factor them out but if C is actually doing the work you can call the same excellent libraries from Ruby too.

e.g. Numo for NumPy or Ruby-Polars for python polars.

Re: Ruby 3.3

#239

Post by cactusplant7374 »

ckolkey wrote: post #163
cactusplant7374 wrote: post #56

Earlier quoted context omitted.

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.

Sounds like Mike found a good feature that would encourage companies to purchase a license. I have a tremendous admiration for the business he's built.

You would think not losing jobs would be a required feature in any job queue software product.

Re: Ruby 3.3

#240

Post by resonious »

cutler wrote: post #93
resonious wrote: post #58

Earlier quoted context omitted.

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.

Apples to oranges again. A more relevant comparison would be Ruby to Python and in recent years Ruby has edged ahead in performance if you factor-out Python's C-based libraries such as Numpy.

If we're comparing "programming languages that can be used to make websites" then it's totally apples to apples. Ruby and Go (and Rust, Java, etc) are all valid options and so I think it's smart to compare them before starting a web project.
Post reply on HN