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

Ruby 3.4.0

ruby-lang.org

Post reply on HN
Print view View original

61–70 of 282 posts

Re: Ruby 3.4.0

#61

Post by masklinn »

Lio wrote: post #58
zarzavat wrote: post #31

Earlier quoted context omitted.

Google hired all the best JIT engineers and set them to work on v8. If you want better performance you'd have to choose an AOT compiled language.

That seems like a meme from 10 years ago. I don’t think that’s really true anymore is it? I mean Truffle Ruby is as fast as V8 already and MRI yJIT and jRuby are catching up fast. It could also be argued that JVM is the gold standard JIT. I think that shows that Google doesn’t have a monopoly on great JIT engineers.

> I mean Truffle Ruby is as fast as V8 already

v8 and node are 15 years old. That's when this actually mattered and js on the backend took off.

Re: Ruby 3.4.0

#62

Post by supriyo-biswas »

capitol_ wrote: post #26
pests wrote: post #6

Earlier quoted context omitted.

Agreed. Parser generators are a magic black box. Parsing is not too difficult, there is some actual computer science in some spots, but I think parsing should be a core complacency of a programming language to unlock full potential.

A very very long list of CVEs disagrees with that parsers are "not too difficult".

Binary format parsing != Programming language parsing.

Re: Ruby 3.4.0

#63

Post by neonsunset »

ksec wrote: post #43
pjmlp wrote: post #35

I am liking all the performance improvement goodies on JIT and GC level.

1. Wondering 3.4 JIT performance vs 3.3 JIT on production rails. 2. Also wondering what upside could Ruby / Rails gain on a hypothetical Java Generational ZGC like GC? Or if current GC is even a bottleneck anywhere in most Rails applications.

> Also wondering what upside could Ruby / Rails gain on a hypothetical Java Generational ZGC like GC? Or if current GC is even a bottleneck anywhere in most Rails applications.

Ruby's GC needs are likely to be very far from the needs of JVM and .NET languages, so I expect it to be both much simpler but also relatively sufficient for the time being. Default Ruby implementation uses GIL so the resulting allocation behavior is likely to be nowhere near the saturation of throughput of a competent GC design.

Also, if you pay attention to the notes discussing the optimizations implemented in Ruby 3.4, you'll see that such JIT design is effectively in its infancy - V8, RyuJIT (and its predecessors) and OpenJDK's HotSpot did all this as a bare minimum more than 10 years ago.

This is a welcome change for the Ruby ecosystem itself I guess but it's not going to change the performance ladder.

Re: Ruby 3.4.0

#64

Post by nix-zarathustra »

speleding wrote: post #11
shortrounddev2 wrote: post #7

What does ruby do well that other languages don't? What is the niche it's trying to fill?

It's the language with the highest ratio of (useful work / LOC), so it's the least verbose language. This makes it very suitable to write and understand complex scripts, because the reduced boilerplate means less cognitive overhead for the programmer. As a result, experienced programmers can be extremely productive with it. The well-known Rails framework uses this to great effect, however, some people argue that the…

>It's the language with the highest ratio of (useful work / LOC), so it's the least verbose language

Why doesn't clojure fit the bill here?

Re: Ruby 3.4.0

#65

Post by kstrauser »

neonsunset wrote: post #60
tuananh wrote: post #10

Shopify strategy aka the story of YJIT If I cannot refactor my services, I shall refactor Ruby instead.

During their black friday / cyber monday load peak, Shopify averaged between ~0.85 and ~1.94 back-to-back RPS per CPU core. Take from that what you will. Reference: https://x.com/ShopifyEng/status/1863953413559472291

Ouch. I had no idea it was that much of a resource hog.

Re: Ruby 3.4.0

#66

Post by Naru41 »

shortrounddev2 wrote: post #7

What does ruby do well that other languages don't? What is the niche it's trying to fill?

As the name suggests, it's just a Perl alt... everyday chores, data analysis, some automation tools.

Re: Ruby 3.4.0

#67

Post by viraptor »

omoikane wrote: post #2

I am most excited about the parser change, previously discussed here: https://news.ycombinator.com/item?id=36310130 - Rewriting the Ruby parser (2023-06-13, 176 comments) I remember being taught to use yacc in our compiler course because "writing it by hand is too hard". But looks like Ruby joins the growing list of languages that have hand-written parsers, apparently working with generated parsers turned out to be e…

It seems like you're ignoring the context/environment. Ruby has enough advanced developers, large enough test suite and enough people who care about performance, that it can tackle the parser as a longer project regardless of its complexity. The same thing will apply to other popular languages. But it won't apply to smaller projects with very localised parser use. In those cases writing anything custom would be a waste of time (and potential introduce bugs solved years ago in generators).

Re: Ruby 3.4.0

#68

Post by viraptor »

dudisubekti wrote: post #57
wiseowise wrote: post #48

Earlier quoted context omitted.

Because it uses same metrics. If you want to see real usage statistics you need to consult GitHub, JetBrains, RedMonk ratings.

Okay: https://octoverse.github.com/2022/top-programming-languages Ruby took a nosedive from 5th "top used" programming language in 2016 to 10th in 2022

Those are relative positions. We can't talk about a "nosedive" from that. It may be the case, but also maybe Ruby was just the slowest growing out of a number of languages growing in popularity. We don't have enough data from there.

Re: Ruby 3.4.0

#70

Post by vidarh »

ksec wrote: post #43
pjmlp wrote: post #35

I am liking all the performance improvement goodies on JIT and GC level.

1. Wondering 3.4 JIT performance vs 3.3 JIT on production rails. 2. Also wondering what upside could Ruby / Rails gain on a hypothetical Java Generational ZGC like GC? Or if current GC is even a bottleneck anywhere in most Rails applications.

There's TruffleRuby (built on Graal) and JRuby if you want to explore that. They're not viable for everything, but they can be much faster.
Post reply on HN