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

261–270 of 304 posts

Re: Ruby 3.2’s YJIT is Production-Ready

#261

Post by pantulis »

int_19h wrote: post #214
pantulis wrote: post #154

Earlier quoted context omitted.

It's good practice to use irb to quickly check stuff or inspect the programmatic surface of a new library. But that's a Ruby feature that you don't have in other languages! In no way its mandatory to code inside irb. Most of my time was spent in Textmate or Emacs.

A REPL such as irb is by no means unique to Ruby. Even many statically typed compiled languages have them these days.

Didn't mean it was unique (guess most interpreted languages have REPL loops) but my point was that it is a plus, not a fault.

Re: Ruby 3.2’s YJIT is Production-Ready

#262

Post by vidarh »

pak9rabid wrote: post #97
vidarh wrote: post #92

Earlier quoted context omitted.

I used to have that attitude. Then I wrote my first Ruby project as an experiment. That was 17 years ago, and the majority of the code I've written since has been Ruby. What clinched it was that the first Ruby project I wrote involved trying to reimplement a piece of C code we had. It ended up 10% the size with more functionality, and it took me a tiny fraction of the time to write. If you write code the way you writ…

Have you looked into Crystal? It's supposed to be a statically-typed language, with the syntax of Ruby. https://en.wikipedia.org/wiki/Crystal_(programming_language)

I have, and last time I looked it deviated from Ruby in entirely pointless ways that makes it fairly uninteresting to me. I get they want it to be its own language, but it'd have been far more interesting to me if it stayed as close as possible wherever it could.

Re: Ruby 3.2’s YJIT is Production-Ready

#263

Post by claudiug »

daviding wrote: post #225

I've set this up in a staging environment of one of our apps to take a look. The staging environment we use for one-offs is on Heroku (can stand one up/down quickly), and the first issue is that a lot of the 'easy to deploy is a feature' PAAS platforms is that they bill by web/worker size restricted by memory rather than just pure virtual CPU power. Render etc all does this as well, and the memory headrooms are low.…

you can use dokku + hetzner. cheap prices(https://www.hetzner.com/cloud)

Re: Ruby 3.2’s YJIT is Production-Ready

#264

Post by vidarh »

Yoric wrote: post #151
vidarh wrote: post #80

Earlier quoted context omitted.

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.

Does this include writing libraries for use by third-parties?

To an extent. In libraries for third parties you do need to test contracts specified by your docs, but a well written Ruby library should intentionally avoid over-testing typing (both in separate tests and in code) and focus on testing behaviours.

Sure, test for sane failure modes in line with the documented contract, and that may include the occasional test that is de facto a type test, but often testing for types, especially in languages with poor type systems, but also in Ruby where we have alternatives, ends up with tests for classes which is frequently the wrong thing.

E.g. in Ruby never, ever check for somearg.kind_of?(IO) if all you ever do is somearg.read - if you absolutely must typecheck somearg, the Ruby way is to check for presence of "#read", e.g. somearg.respond_to?(:read), or try and fail responsibly (and often just allowing the NoMethodError to bubble up is the right way to fail).

Also think it's just fine for people to add and ship Sorbet type declarations for gems etc. to then signal those contracts so people can verify them if they choose. There's no reason not to offer that when it's reasonable to do so.

Re: Ruby 3.2’s YJIT is Production-Ready

#265

Post by vidarh »

lmm wrote: post #187
vidarh wrote: post #92

Earlier quoted context omitted.

I used to have that attitude. Then I wrote my first Ruby project as an experiment. That was 17 years ago, and the majority of the code I've written since has been Ruby. What clinched it was that the first Ruby project I wrote involved trying to reimplement a piece of C code we had. It ended up 10% the size with more functionality, and it took me a tiny fraction of the time to write. If you write code the way you writ…

C is barely statically typed. In an ML-family languge you can write pretty much the same code you'd write in Ruby, just it'll be typesafe.

If there's an ML-family language that reads similar to Ruby I'd love to use it. I'm not being facetious - I still love the notion of as much static testing as I can, but I'm not willing to give up the pleasantness of Ruby for it, so if there's something that can get me there I'd love to see, even if it's not "good enough" to replace Ruby for everything.

But keep in mind this includes run-time dynamic meta-programming. E.g. one of my projects bootstrapped a large proportion of the web frontend by having the backend introspect the database schema and dynamically generate models, routes, access control and metadata endpoints that the frontend then used to instantiate the UI.

The typing in that case was controlled by the database migrations.

Re: Ruby 3.2’s YJIT is Production-Ready

#266

Post by vidarh »

hbrn wrote: post #217
int_19h wrote: post #213

Earlier quoted context omitted.

Oh, it does. It just happened back when Python and Ruby were new and hot. These days, Rust is new and hot, and so ...

I do remember dumping on Java back in those days, not so much on static typing itself. Seems like those were mostly language wars: Python vs PHP, Python vs Java, Ruby vs PHP, etc. It might be just anecdotal, but I noticed people often say that writing in Ruby makes them feel happy . Static typing (or functional programming, or TDD) doesn't seem to make people happy. It makes them feel superior . Whether it truly make…

As someone who was gung ho about static typing, what made me happy about Ruby was losing the aggressive type annotations, and the pain of having to change it all around, and C++ and Java were among the worst offenders. I spent a lot of time looking for statically typed alternatives that'd make me happy back then before I finally was convinced to try Ruby.

These days more inferred typing in many of the static languages has lessened the gap, so the reason to hate on them has been reduced.

I still would love better static analysis tools, including for Ruby, but at the same time the way I write code has changed drastically in ways that makes that harder (e.g. leveraging the dynamic features of Ruby more)

Re: Ruby 3.2’s YJIT is Production-Ready

#267

Post by hamandcheese »

idk1 wrote: post #256

Can someone 'explain it like I'm 5' why someone would just JIT instead of compiled Ruby, or even what the difference is please.

JIT VMs often rely on runtime tracing to form assumptions about a program, and then JIT native code that fits those assumptions. If/when those assumptions break, the VM can fall back to interpreting the original code.

That means there is no need to write a fully-featured Ruby compiler, instead you only have to emit native code in places/situations where it will have the maximum benefit.

Re: Ruby 3.2’s YJIT is Production-Ready

#268

Post by vidarh »

treis wrote: post #144
mostlysimilar wrote: post #113

Earlier quoted context omitted.

I don't know if I'm just a bad programmer and everyone knows something I don't, but it seems to be the benefits of a strongly typed language are wildly overblown. It's a different way of thinking about building software and it saves you from a few mistakes you could otherwise make, but you'd think I was writing code with a hammer and chisel the way people on HN talk about languages like Ruby. It feels a lot like the…

It comes down to project size. Small projects with a small team tend to be fine. Bigger ones tend to break down a bit and the application becomes ossified because there's no safety when changing things. You can power through it but productivity takes a nose dive. The big ones that stay on Ruby tend to invent typing like things to solve the issue.

If there's no safety when changing things, then you've failed to define and verify adherence to contracts along component boundaries, and the lack of a proper test suite.

I've certainly seen that happen in Ruby, but I've also seen that happen in every other language - most of them statically typed - I've worked with, as very few languages have type systems expressive enough to prevent it (and it tends to massively destroy productivity to try check everything strictly enough anyway).

Re: Ruby 3.2’s YJIT is Production-Ready

#269

Post by tomstuart »

idk1 wrote: post #256

Can someone 'explain it like I'm 5' why someone would just JIT instead of compiled Ruby, or even what the difference is please.

It’s hard to generate efficient code ahead-of-time because the compiler doesn’t know what the types of values will be, so it has to emit very general code that can cope with all possibilities at the expense of performance. A just-in-time compiler has access to this type information because it’s executing at runtime, so it’s able to generate more efficient code which only works in the more specific situation that is actually happening right then.

See Natalie [0] for a work-in-progress Ruby compiler which works ahead of time. It’s a super cool project but it’s just for fun [1] so I don’t believe it’s trying to compete on performance.

[0] https://natalie-lang.org/

[1] https://justforfunnoreally.dev/

Re: Ruby 3.2’s YJIT is Production-Ready

#270

Post by JohnBooty »

mirekrusin wrote: post #206
JohnBooty wrote: post #135

Earlier quoted context omitted.

Tragically, one of the principals behind TruffleRuby (and researcher at Shopify) was Chris Eaton and he passed away a few months ago. I'm not sure where this leaves TruffleRuby itself, or plans to implement it at Shopify. (Rest in peace, Chris, and may your memory be a blessing to those who knew you)

Chris Seaton

Thank you.
Post reply on HN