RubyGems.org backfilled older releases with `created_at` fields, so theoretically you could still do the cooldown with very old gems (though I don't know why you would). It's only private / alternative gem servers that may not provide `created_at` fields.
This absolutely happened and is not speculation. I can't find the emails from the individuals that emailed me, but I did find my email to the board of directors asking that the website language be changed because people had pinged me thinking I would be getting money, or that the money would go to fund rubygems.org.
At the time I'd sent the email I was unaware Ruby Together was on HN front page (and that's why people were pinging me)
As I said in my blog post, it imports both and combines them in the UI. Also as I said in my blog post, I switched to shooting only in raw, and it still exhibited file corruption.
I ran both files through xxd then diffed them. I've literally changed every piece of hardware (at no small cost). "premature to immediately blame Apple" seems a bit off.
> Yes, but if it ends up creating any ephemeral objects in the process of determining those returned objects, then the allocation sequence is still not homogeneous.
Yes! People might do `map` transformations, but it's very common to do other stuff at the same time. Any other allocations during that transformation would ruin cache hit rate.
> At the same time, the callsite for any given `.new()` invocation will almost always be creating an instance of the exact same class. The target expression is nearly always just a constant name. That makes it a prime candidate for good inline caching at those callsites.
One reason is that we think we can make better use of registers. Since LBBV doesn't "see" all blocks in a particular method all at once, it's much more challenging to optimize register use across basic blocks. We've added type profiling, so ZJIT can "learn" types from the runtime.
It's not being abandoned, we're just shifting focus to evaluate a new style of compiler. YJIT will still get bug fixes and performance improvements.
ZJIT is a method based JIT (the type of compiler traditionally taught in schools) where YJIT is a lazy basic block versioning (LBBV) compiler. We're using what we learned developing and deploying YJIT to build an even better JIT compiler. IOW we're going to fold some of YJIT's techniques in to ZJIT.
> And if so, will these YJIT features likes Fast Allocations be brought to ZJIT?
It may not have been clear from the post, but this fast allocation strategy is actually implemented in the byte code interpreter. You will get a speedup without using any JIT compiler. We've already ported this fast-path to YJIT and are in the midst of implementing it in ZJIT.
libffi can't know how to unwrap Ruby types (since it doesn't know what Ruby is). The advantage presented in this post is that the code for type unboxing is basically "cached" in the generated machine code based on the information the user passes when calling `attach_function`.
Ya, I really enjoy pattern matching. I think new language features just take a long time to percolate through the community. I remember when `->` was controversial, but that's the only way I write lambdas today. :D
While RUM is out of date, I still think it's an excellent resource. Some of the information in the book may be out of date, but I think it's an excellent place to start when you want to jump in to Ruby's source. Basically, after reading RUM the best place to go is to start reading the source.
That said, it would be really great if Pat (or someone besides me) published an update version of RUM
This guide is interesting but extremely out of date. I recommend Ruby Under a Microscope[1] though it is also out of date as well (but less out of date than the Ruby Hacking Guide)
I hope that you'll watch the recording of the talk when it's released. The context of the "cliche" is with regard to the community, the framework, and why Eileen continues to remain on the core team. It's nothing to do with the design or functionality of the framework itself. :)