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

Ruby 3.2’s YJIT is Production-Ready

shopify.engineering

Post reply on HN
Print view View original

71–80 of 304 posts

Re: Ruby 3.2’s YJIT is Production-Ready

#71

Post by stevebmark »

pdntspa wrote: post #54
asim wrote: post #2

It shows that Ruby still has life left in it yet. The language itself is wonderful, there's a great ecosystem of tooling but the performance was always lagging. Hopefully some of this makes it a choice for people once more over other more esoteric languages. My only concern here would be the time and sunk cost fallacy of someone like a Shopify working on a Ruby JIT. It reminds me of when Facebook was working on the H…

I am sooooooooooo sick of all this language churn. Ruby is a fantastic language, full stop.

  irb > def method
  irb >   'yes'
  irb >   def method
  irb >     'it is not'
  irb >   end
  irb > end
  irb > method
  => :method
  irb > method
  => "it is not"

Re: Ruby 3.2’s YJIT is Production-Ready

#72

Post by blacksmith_tb »

vlunkr wrote: post #59
Thaxll wrote: post #45

Earlier quoted context omitted.

The main issue I have with Ruby / Python is the fact that it's duck typed, it makes the maintenance and refactor pretty hazardous. You get objects you don't know what's in there, 6 month later someone changed it, no compile error but it will break when you run it. And so to overcome those major issues they added really ugly stuff that is not core to the language, linters, annotations etc ...

I still think it's a great choice for smaller projects. I can't imagine it at the scale of shopify.

Apparently they couldn't imagine it either[1].

1: https://sorbet.org/

Re: Ruby 3.2’s YJIT is Production-Ready

#73

Post by davidw »

Thaxll wrote: post #45
revskill wrote: post #38

For anyone thinking Ruby is dying or slow, it's not the reason people like me used it and sticked with it in first place! It's about the experience when you write the code itself. It's natural, like a flow of water, and you're suddenly in Zen mode, where your thought just naturally flow without even you're aware or not. I first time learn Ruby from zero to "hero" in production confidently is in just under a week. And…

The main issue I have with Ruby / Python is the fact that it's duck typed, it makes the maintenance and refactor pretty hazardous. You get objects you don't know what's in there, 6 month later someone changed it, no compile error but it will break when you run it. And so to overcome those major issues they added really ugly stuff that is not core to the language, linters, annotations etc ...

What are you using that's strongly typed and as quick to get stuff done with as Ruby?

Re: Ruby 3.2’s YJIT is Production-Ready

#74

Post by byroot »

gvalkov wrote: post #67
maxime_cb wrote: post #20

Earlier quoted context omitted.

If you believe the language benchmark game, Ruby is faster than Python on many of the microbenchmarks: https://benchmarksgame-team.pages.debian.net/benchmarksgame/... And the benchmark game is using Ruby 3.1, whereas 3.2 is significantly faster. YMMV though, it is going to depend on your use case, but we are always working on making Ruby faster, and if you run into a use case where Python is a lot faster, you can pin…

Python 3.11 also claims [1] to be 10-60% faster than 3.10, which is the version that the benchmarks game is using at this time. The difference in used RSS is also quite interesting in this comparison. [1]: https://docs.python.org/3/whatsnew/3.11.html#whatsnew311-faster-cpython

> The difference in used RSS is also quite interesting in this comparison.

YJIT 3.1 was eagerly allocating it's executable memory region regardless of whether it was needed or not. With the default settings that meant an extra 256M of RSS right at boot.

As mentioned in TFA that's no longer the case in 3.2, so expect this RSS number to go down by at least a good 200MB once they upgrade to 3.2.

Re: Ruby 3.2’s YJIT is Production-Ready

#76

Post by nirvdrum »

stevebmark wrote: post #70

Is there a name for this syndrome? The same thing happened at Github. Ruby and Rails are slow enough in production that they dedicate a specialized, long-running internal team to it. This team doesn't contribute directly to the product. They hire core Ruby and Rails maintainers, also not to contribute to the product, just to try to help improve their slow software. It's a dream job that shouldn't exist. If you tell m…

Don't most large products have teams working on performance? With a VM-based language like Ruby, speeding up the VM is a sound strategy because it works across all of your applications. There are teams embedded in corporations working on the JVM, the Python VM, the PHP VM, and so on (sometimes brand new VM implementations). There are teams working on improving performance of the standard library and compiler in C, C++, Rust, and Go. There are teams working improving performance of applications in all of those languages.

Sure, if you're a startup and you can't afford it, you probably shouldn't be spending time speeding up your language. But, you're also unlikely to experience performance issues under your lighter load that can't be attributed to your application.

Re: Ruby 3.2’s YJIT is Production-Ready

#77

Post by JW_00000 »

pantulis wrote: post #55
Thaxll wrote: post #45

Earlier quoted context omitted.

The main issue I have with Ruby / Python is the fact that it's duck typed, it makes the maintenance and refactor pretty hazardous. You get objects you don't know what's in there, 6 month later someone changed it, no compile error but it will break when you run it. And so to overcome those major issues they added really ugly stuff that is not core to the language, linters, annotations etc ...

It's not like strong typing came after Ruby. In fact, duck typing was a _feature_ of Ruby on its days. At the end of the day, you choose your battles, it's not a black-or-white decision.

No, but gradual/optional typing did come after Ruby. Back in 2005, you could choose between static typing with type checking but lots of verbosity (e.g. Java "Point point = new Point();" or C++ "for (std::map::iterator it = myMap.begin(); it != myMap.end(); it++)") or dynamic typing without type checking but also without the verbosity. Since optional typing, dynamically typed languages got the guarantees of type checking, and JavaScript/TypeScript and Python have embraced this. With type inferencing, statically typed languages lose their verbosity, and Java and C++ have embraced that (as have newer languages like Rust, Go, and Swift). It feels like Ruby hasn't progressed on this front...

Re: Ruby 3.2’s YJIT is Production-Ready

#78

Post by lakomen »

> Multiple large clusters of servers distributed across the world, capable of serving over 75 million requests per minute

That doesn't say anything at all sadly.

Ruby people seem to be sensitive when someone asks them about performance, my last question about that was downvoted heavily here.

I don't know any Ruby, I know how much Go can handle with the stdlib, a single non-parameterized route, returning "hello world". On my machine xeon e3-1275v5 with 8 threads 1000 concurrent wrk about 220k/ rps. Errors start appearing (aka non-200 results) between 5000 and 6000 concurrent. Don't forget to ulimit -n 10000 or more before you start wrking.

Alternatively can you provide a simple single route hello world in Ruby so I can bench it myself with this Ruby 3.2 YJIT? Maybe also how to build and run?

Yes, I'm being serious. I'm also guessing that Ruby with Rails has a large overhead compared to Go and just the stdlib. So that comparison wouldn't be fair, but I guess it is what it is, since we're talking semi real world scenarios (yeah don't get your ocd panties in a bunch) and Rails AFAIK is the standard for Ruby web development while the stdlib in Go is also used quite often.

Re: Ruby 3.2’s YJIT is Production-Ready

#79

Post by bastardoperator »

davidw wrote: post #73
Thaxll wrote: post #45

Earlier quoted context omitted.

The main issue I have with Ruby / Python is the fact that it's duck typed, it makes the maintenance and refactor pretty hazardous. You get objects you don't know what's in there, 6 month later someone changed it, no compile error but it will break when you run it. And so to overcome those major issues they added really ugly stuff that is not core to the language, linters, annotations etc ...

What are you using that's strongly typed and as quick to get stuff done with as Ruby?

Nothing, it was just an opportunity to use buzzwords and inject negativity.

Re: Ruby 3.2’s YJIT is Production-Ready

#80

Post by vidarh »

ajmurmann wrote: post #65
pantulis wrote: post #56

Earlier quoted context omitted.

Also, you need to be religious about testing and writing tests _anyway_.

As someone who spent a good chunk of their career teaching TDD, I agree and disagree. Yes, tests are crucial. However, which tests to write varies among other things by language. When I write Ruby, I benefit from testing even the simplest things. When I write Rust or even Type Script or Swift I'll focus much more on tests for complex logic and on integration and acceptance tests. Static typing eliminates an entire, l…

When I write Ruby, I test expected behaviours, and if there are type errors in there those tends to fall out from tests I needed anyway. If you need to test specifically for errors due types, then generally that suggests that either your application does not normally exercise those code paths at all and/or you fail to test behaviours of your application.
Post reply on HN