It would be useful to explain why ZJIT exists given that there's already YJIT.

Also, what's the long-term plan for YJIT.

riffraff 7 hours ago | parent | next [-]

ZJIT exists because it's a more traditional design and there's hope more people will have a easier time contributing[0]. Given that, it seems YJIT will become unnecessary if ZJIT succeeds.

0: https://railsatscale.com/2025-05-14-merge-zjit/

▲

baggy_trough 7 hours ago | parent | prev | next [-]

The explanation is in the second paragraph of the article.

▲

fourseventy 7 hours ago | parent | prev [-]

I just upgraded my prod apps to run on YJIT so I'm annoyed at this announcement. Feels like javascript-esque runtime churn

▲

tekknolagi 7 hours ago | parent [-]

Earnestly: why are you annoyed? I tried to make it clear that you don't have to make any changes. If you want, you can try ZJIT (which should not be anything other than a one character change), but you don't have to.

▲

fourseventy 7 hours ago | parent [-]

Because now YJIT is deprecated and at some point in a year or two I will have to have my team go through and switch everything from YJIT to ZJIT. So it's creating random tech debt busywork that will suck up dev resources that could better be used building features.

In isolation, having to switch from YJIT to ZJIT isn't that bad, but this same type of churn happens across so much of the frameworks and technologies that my company uses that in aggregate it becomes quite an annoyance.

	▲	tekknolagi 6 hours ago \| parent \| next [-]
		YJIT is not deprecated. That word has a specific meaning in Ruby. You can continue to use YJIT. With any luck, this performance in the next year or two will be enough to make it a happy change. "Damn, free money" etc
	▲	pjmlp 6 hours ago \| parent \| prev [-]
		Most JIT compiled languages have multiple implications, each pushing each other forward.