yjit VS Opal

> I’m curious how the impact affects development, deployment, etc.

YJIT is pretty much transparent in production, if not it's likely a bug.

When we tried MJIT in production to compare it against YJIT, it causes lots of request timeouts on deploy, because the JIT warmup would take 10 to 20 minutes and it's much slower during that phase.

But YJIT warms ups extremely fast and with a much lower overhead, it's seemless on deploy.

The only thing you may need to tweak is `--yjit-exec-mem-size`, it defaults to `--yjit-exec-mem-size=256` (MB) which is not quite enough for larger apps.

As for development, it would work, but with code reloading enabled, you'd likely exhaust the executable memory allocation pretty fast, because for now YJIT doesn't GC generated code [0]. It will come soon, hopefully before the 3.1.0 release, but that's one of the reason why it's not enabled by default.

[0] https://github.com/Shopify/yjit/issues/87

Just want to temper expectations because YJIT is still new. But if you run into crashes or bugs, please open an issue with as much detail as you can: https://github.com/Shopify/yjit

You raised a point that the compiler only does a subset. That's actually what I would expect from a new project. I don't expect a full implementation to start. It takes time for a compiler to be mature enough to be general purpose. Here is another Ruby compiler in its infancy: https://github.com/Shopify/yjit.

We allocate our own chunk of executable memory and append/rewrite the end of it as we compile new blocks. We have our own in-memory assembler that's implemented here. It's x86 only right now, totally not portable, but over the course of the summer we're going to work on a backend that can open up the possibility of ARM64 support and some lower-level optimizations.

Yes. I put some suggestions here. I realize that not all of them are practical, but refactoring specific hot methods could make a difference.

Yes we are in touch with the Ruby core devs. They seem open to collaborating. k0kubun (working on MJIT) has contributed to the project: https://github.com/Shopify/yjit/pull/60

Not the OP, but from what I remember they would seek out every possible opportunity in every single possible open source community they could find and propose the CoC that they wrote. 0 contributions to the projects, with the exception of demanding that people implement incredibly verbose CoC's in their projects under the guise of "protecting the minorities contributing to the projects".

Most infamous instance is probably this one, in the Opal repo: https://github.com/opal/opal/issues/941

As well as this thread in the Ruby issue tracker that devolves into pure chaos with Ada refusing to actually participate in any of the valid points others bring up: https://bugs.ruby-lang.org/issues/12004

And I'm sure there's many other instances if you look around a bit.

My experience with ruby for front end web dev is via https://opalrb.com/

Here's an example of the creator of the most adopted CoC (the Contributor Covenant) trying to get an open source contributor removed from a project due to his political opinions expressed on Twitter which she didn't like and found offensive.

So ruby has a JS transpiler - opal - https://opalrb.com/

I tried using it a little bit but the reality is if you need JS to make your app more interactable it's really worth it to just learn some JS. As soon as you need something complex the extra layer of abstraction just gets in the way and becomes more of a headache, and if you don't need anything complex then you don't need JS in the first place.

Advocating for removing a contributor for a statement on a different site, unrelated to the project, for example?

https://github.com/opal/opal/issues/941

Ruby can be transpiled to JavaScript :P Same as TypeScript is used a lot

There is already this project that I found which interprets ruby in JavaScript: https://github.com/opal/opal