> what's the justification of not using a memory-safe language
Use Go, Java or Fil-C, and memory safety is achieved at the expense of runtime performance. Tracing garbage collectors make your programs run slower and use more RAM.
With Rust you pay with complexity. Rust has new, weird syntax (lifetimes, HRTB, etc) and invisible borrow checker state that you've gotta understand and keep track of while programming. Rust is a painful language to learn, because lots of seemingly valid programs won't pass the borrow checker. And it takes awhile to internalise those rules.
I personally think the headache of rust is worth it. But I can totally understand why people come to the opposite conclusion.
Rusts memory safety constructs do also impose a (much smaller) runtime performance penalty. Every Arc / Rc is a memory safe abstraction with runtime cost since rust has no way to prove cyclic reference graphs are safe at compile time.
How about they are pointing out a worrisome direction society might be taking, whereas work will infiltrate even more what used to be family or personal time, thus accelerating burnout?
This is my only public Rust repo — I have some ongoing private projects in Rust, so I'm familiar with the ecosystem (cargo, crates, the borrow checker experience, etc.).
That said, to be fully transparent: as I disclosed elsewhere in this thread, the Ferrite codebase is 100% AI-generated (Claude via Cursor). I direct the development, test, and iterate, but I haven't written the Rust by hand for this project.
So my Rust experience is more "ecosystem familiarity + reading AI-generated code" than "battle-hardened Rustacean." This project is partly a learning exercise — seeing how far AI-assisted development can go while picking up Rust patterns along the way.
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.
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.
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.
I assume you upgrade your Ruby VM? You also upgrade to use YJIT? And you will upgrade to ZJIT?
Not only do you get them for free, you get performance improvement for free. And YJIT is still supported and not depreciated. Not only is Ruby on Rails dont have churn anywhere near the order of magnitude of JS world. It is perhaps one of the stablest and non-moving framework and languages, to the point it is moving slowly and boring compared to even modern PHP and Python.
I dont even work on YJIT or ZJIT but I find this entitlement on OSS, even when you are getting newer upgrade and improvement for free, for all the benefits it provides while having so little downside being called "random tech debt busywork" frankly very rude.
I was in a similar situation to OP: my Carbon X1 Gen 8 keys, notably `/` and some arrows keys, stopped functioning. Sometimes they did, but it was very erratic.
Luckily, when I replaced the battery (got a lot from iFixit) and tightened all other screws, the keys magically started working again.
