Nah, they replaced GitHub with some in-house videcoded stuff a few months ago, and from what I hear from the grapevine it's not going well.

But there's a number of other big private repos with a high rate of merge on GitHub, and indeed it's currently a bit painful, e.g. the subroutine that check whether a PR can be merged tend to take ages. So my read is that they want to better support these big customers out of concern that they might leave too.

This is just cringeworthy, even for Tobi.

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.

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.

Thanks for the clarification. I thought Prism is still in beta. Maybe I'm wrong

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

> 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...

There's a public survey: https://surveys.ecb.europa.eu/10b/neweuro/

Thank you. I wish they had used a pairwise comparison system like the one built by pil0u [1] for this. If I hadn't looked at all of them in advance, I would've had to go back to "normalize" my previous answers after seeing one that I especially like/hate.

[1]: https://news.ycombinator.com/item?id=49041625

That's why C23 introduce free_sized [0].

[0] https://en.cppreference.com/c/memory/free_sized

>> If you can convince the caller to keep track of that metadata themselves you obviously don’t need to. That can be important.

> That's why C23 introduce free_sized

Is it? C23 still has free, so there’s no guarantee callers wil use free_sized, so the allocator still has to be able to obtain a block’s size from a pointer.

Or do I overlook something?

I suppose by default it will just call free, but you can substitute different malloc implementations, maybe one with a malloc_no_header function

Because free still exists and there is no “allocate this number of bytes of memory; I promise to free it with a call to free_size” call, you can’t have a malloc implementation that doesn’t track block sizes.

I think the only thing free_size adds is robustness. Allocators can check the passed in size with what they know and abort the program if they do not match. That can thwart some security issues.

Similarly, when writing Facebook apps with Rails, when you'd hit that same bug you'd see Mark Zuckerbeg: https://www.facebook.com/profile.php?id=4

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.

that sounds nice, thanks for sharing The Numbers! :D