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

151–160 of 277 posts

Re: Ruby 3.3

#151

Post by nsajko »

byroot wrote: post #147
ksec wrote: post #122

Earlier quoted context omitted.

If you compare pure Ruby without Rails to fast language like Rust, Go and Java. It is probably closer to 10-20x. The 100x to 200x mainly comes from Rails.

Can we stop with these useless comparisons? 10x-20x, 100x, 200x out of context means absolutely nothing. All these micro-benchmarks shootouts means nothing either. Is anyone running a mandelbrot or pi-digits SaaS company? I'd think not. Similarly saying Rails is slow out of context, means nothing, Rails is "slower" than Ruby micro-frameworks X because it does useful things the other doesn't like CSRF protection etc.…

Perhaps it's misleading to throw around specific numbers like 100x, but Ruby is certainly orders of magnitude slower than languages like Go or Java. Both of which are not exactly known for their speed (compared to C++ or Julia, for example).

Re: Ruby 3.3

#152

Post by seabrookmx »

the_gastropod wrote: post #113
tomlin wrote: post #78

Earlier quoted context omitted.

I'm so glad that you said this and weren't downvoted into the ground. Honestly, Ruby needs to die. It performs like a go cart in a Formula 1 race. I'm actually just exhausted watching smart people tell me this is a language and toolchain worth dedicating brain cells to.

What a bizarre take. Ruby is primarily used in web applications, where round-trip http requests, database queries, and other 10s-of-ms things are commonplace. Ruby is very rarely the bottleneck in these applications. Choosing to make your job significantly more challenging in order to maximize the performance of a small portion of the total response time of a web application is not, in my estimation, a smart decision…

There's always this rift between the "language is slow" crowd and the "but it's not the bottleneck" crowd. I think this comes from the types of applications you work on and their scale.

I work at what a company that's not particularly large. Our original API is a Django monolith that serves about 1000req/s.

While you could argue Python isn't the bottleneck, Django often is. I hear the same feedback from colleagues that work in Rails. Not only do we run into issues with latency per request but we have to run a significant number of Kubernetes pods to serve this workload. With c#, golang, java or a similar language we would only require a handful of pods and drastically cut our compute costs.

Even for web workloads, these slow interpreted languages and their developer experience optimized frameworks absolutely do become a bottleneck and claiming they don't (or that you need to be at Google/Facebook scale before they do) is false.

Everything is a tradeoff but the way I think of it: speed is a feature.

Re: Ruby 3.3

#153

Post by cdcarter »

riffraff wrote: post #109
pmontra wrote: post #43

Earlier quoted context omitted.

My customers are using Celery for Python and Sidekiq for Ruby. Those are parts of Django and Rails web apps. Those customers don't mix languages so they don't need workers able to run code in multiple languages. One of them is also using SQS though so we could receive a JSON in a server written in any language, do some processing and return the result. However the database of that app has been "destroyed by design" b…

What's wrong with Django's orm? Does it have something particularly bad compared to others?

I think the poster is specifically referring to using inheritance in Django ORM, where if you had e.g. a model Book and then a model Novel that inherits from it. In python these are modeled as a class inheritance hierarchy, and Django (at least, by default) creates a database table per class in the hierarchy. If you have 3-4 levels of inheritance, that's 3-4 extra joins per query.

Re: Ruby 3.3

#154

Post by [deleted] »

pmontra wrote: post #43
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…

My customers are using Celery for Python and Sidekiq for Ruby. Those are parts of Django and Rails web apps. Those customers don't mix languages so they don't need workers able to run code in multiple languages. One of them is also using SQS though so we could receive a JSON in a server written in any language, do some processing and return the result. However the database of that app has been "destroyed by design" b…

[deleted]

Re: Ruby 3.3

#155

Post by nixpulvis »

Anyone have a link to some good examples of using Prism? I was disappointed to not really see anything other than the “Notable API” from this release page.

Re: Ruby 3.3

#156

Post by mixmastamyk »

cdcarter wrote: post #153
riffraff wrote: post #109

Earlier quoted context omitted.

What's wrong with Django's orm? Does it have something particularly bad compared to others?

I think the poster is specifically referring to using inheritance in Django ORM, where if you had e.g. a model Book and then a model Novel that inherits from it. In python these are modeled as a class inheritance hierarchy, and Django (at least, by default) creates a database table per class in the hierarchy. If you have 3-4 levels of inheritance, that's 3-4 extra joins per query.

We use that, a base model and some mixins, but we use Meta.abstract=True (or similar, not at my desk) on the parents and have not noticed any issues, though have not looked for them either! Should I be concerned?

Re: Ruby 3.3

#157

Post by byroot »

alberth wrote: post #150
byroot wrote: post #149

Earlier quoted context omitted.

This number is from a production workload with a significant chunk of IOs. If you look at CPU bound micro-benchmarks like most similar announcements uses, you easily get into the 3x territory: https://railsatscale.com/2023-12-04-ruby-3-3-s-yjit-faster-w...

> “get into the 3x territory” Where are you seeing 3x improvement? Because even this graph from your article doesn’t show that, unless you’re comparing JIT vs non-JIT. But JIT has existed for awhile now (not new in 3.3). https://railsatscale.com/2023-12-04-ruby-3-3-s-yjit-faster-w...

In the yjit-bench suite, there are a number of micro benchmarks that had a 2-3x gain between 3.2 and 3.3: https://speed.yjit.org/stats-timeline.html

But my point is that the YJIT team never really communicate numbers from synthetic benchmarks, it's very focused on real world workloads.

Synthetic benchmarks are used internally, but mostly to optimize a specific pattern that was identified as a common hotspot.

All this to say this figure you quote is not to be directly compared to many similar announcements from other projects or benchmark suites.

Now if you still think it's not good enough, I encourage you to try your hand at it to see how much of an accomplishment that really is.

Re: Ruby 3.3

#158

Post by cdcarter »

mixmastamyk wrote: post #156
cdcarter wrote: post #153

Earlier quoted context omitted.

I think the poster is specifically referring to using inheritance in Django ORM, where if you had e.g. a model Book and then a model Novel that inherits from it. In python these are modeled as a class inheritance hierarchy, and Django (at least, by default) creates a database table per class in the hierarchy. If you have 3-4 levels of inheritance, that's 3-4 extra joins per query.

We use that, a base model and some mixins, but we use Meta.abstract=True (or similar, not at my desk) on the parents and have not noticed any issues, though have not looked for them either! Should I be concerned?

That works fine. It's when you inherit from a non-abstract model that you end up with the trickier data model.

Re: Ruby 3.3

#159

Post by byroot »

nsajko wrote: post #151
byroot wrote: post #147

Earlier quoted context omitted.

Can we stop with these useless comparisons? 10x-20x, 100x, 200x out of context means absolutely nothing. All these micro-benchmarks shootouts means nothing either. Is anyone running a mandelbrot or pi-digits SaaS company? I'd think not. Similarly saying Rails is slow out of context, means nothing, Rails is "slower" than Ruby micro-frameworks X because it does useful things the other doesn't like CSRF protection etc.…

Perhaps it's misleading to throw around specific numbers like 100x, but Ruby is certainly orders of magnitude slower than languages like Go or Java. Both of which are not exactly known for their speed (compared to C++ or Julia, for example).

"speed" thrown without context is meaningless. It's one property of a tool among many others you generally have to trade for.

Some use cases with small margins call for the utmost efficiency to be viable business. Some use cases just need decent efficiency and are happy to trade some efficiency for some other properties.

Many successful people and companies are happy with Ruby, can we just give them a break? Or is there somehow some moral duty to use the "fastest" language available regardless of whether it makes any kind of business sense that nobody told me about?

Re: Ruby 3.3

#160

Post by ochoseis »

seabrookmx wrote: post #152
the_gastropod wrote: post #113

Earlier quoted context omitted.

What a bizarre take. Ruby is primarily used in web applications, where round-trip http requests, database queries, and other 10s-of-ms things are commonplace. Ruby is very rarely the bottleneck in these applications. Choosing to make your job significantly more challenging in order to maximize the performance of a small portion of the total response time of a web application is not, in my estimation, a smart decision…

There's always this rift between the "language is slow" crowd and the "but it's not the bottleneck" crowd. I think this comes from the types of applications you work on and their scale. I work at what a company that's not particularly large. Our original API is a Django monolith that serves about 1000req/s. While you could argue Python isn't the bottleneck, Django often is. I hear the same feedback from colleagues th…

Further, with a lot of the batteries-included web frameworks you end up with a ton of suboptimal database queries (e.g. unintentional query-in-loop). Some would argue that you can just profile your code and optimize the hot spots, but I would tend to think it still slows you down quite a bit overall.
Post reply on HN