byroot

The difference is that Ruby follow the BDFL model, and Ruby's BDFL was willing to allow people to experiment with in-tree development of JITs.

If the Python steering committee isn't willing to do the same, they'll probably won't get a working JIT any time soon. Developing a JIT externally, or even from a branch, is just too hard.

> Uses 1.5GB of RAM on my laptop atm.

That's crazy, I just checked on mine (macOS), it's only ~300MiB, about as much as Apple Mail which is native.

Still a bit much for what I need it for, but tolerable.

Nope. It’s been the default MRI parser for a couple years now.

TruffleRuby is pretty close too, if anything it’s even a bit more compatible because it’s able to run native extensions.

Also keeping compatible with MRI have been made significantly easier by Prism, the new parser that is shared by all implementations.

> lost 3 of 3 members of the Open Source Committee (Gabi, Mike, Ufuk)

This is rich given they left in big part because of how much abuse they have received by "supporters" of André & co...

It was just one of many.

Alone it wouldn't have been very noticeable, but I did many small optimizations like that, which ultimately shaved about 20 seconds of setup time.

Looking from another angle, the app boot time on CI (not eager loading) was a bit more than 10 seconds, this saved over half a second, so a ~5% gain for an afternoon of work.

Nothing ground breaking we simply deploy Buildkite agents on EC2 nodes.

As mentioned in the post, the only thing really limiting CI parallelism is the ratio of "setup time" vs "test time". If your setup time is too long, you hit diminishing returns fast.

Aside from the oddness of making this cache git aware, with the new implementation I suspect querying git to revalidate the cache would take longer than just rebuilding it.

Nitpick, but France never left NATO proper, only the integrated command, and reintegrated it in 2008 under Sarkozy.