This measurement is very focused on bit-related instructions. A few months ago we did some work on our (RemObjects) toolchain, and it showed very similar results, where our published benchmarks were for floating point.[0] I did some rough internal measurements showing the same for integer-related instructions too.
The same conclusion: v2 as baseline, v3 where possible.
I'm really surprised it's not standard in every toolchain to support arch levels like this today.
Some compilers like Clang allow multiple arch versions in one binary, runtime dispatched. I would love to implement this in our toolchain too.
Glad to see Liquid Glass getting some refinements. I was excited for it at Tahoe's announcement and deeply disappointed when it was released: partly because I think the current design language doesn't support it or let it shine; partly because I wanted a return to Aqua-inpired design, and glass as a Vista-style background is completely different to glass used for specific small control elements. Most fundamental legibility issues (IMO) with Liquid Glass come from this.
In my spare time I have been writing a library to render standard macOS controls with Liquid Glass.
It's shown me why they use it for the backgrounds: it's so heavily based on refraction (oddly, mostly on one axis, not sure if this is obvious visually!) that for something like a button, there's nothing to refract, therefore it looks very plain. You have to have a background for it to look good.[*] I can't help wondering at what happened internally: my personal pet theory, for which I have no evidence, is that someone missed Aqua, thought 'if we do it with shaders it will be new and shiny and we can release it', and that tech decision forced implementation aka glass backgrounds not foregrounds.
[*] My solution: add a background to buttons and other controls. I'm going for a look inspired by Lion. It doesn't have to be very prominent; it just has to be there for something to refract so your eyes see shape and recognise the glass.
I appreciate the ethos of unity, but in a sense it scares me were this ever to be political unity -- because I don't trust it would remain (or even ever be) democratic and free.
We see so many examples of power hurting citizens in existing nations. The risk if the entire world had one political unity, of losing freedom, is extreme.
With multiple nations and blocs, at least some remain showing an example of what can exist in the others.
The only way we'll going to achieve anything remotely akin to World Unity™ is as some form of dystopic Warhammer 40K future. You try putting even 5 people in a root have them reach consensus on anything.
I wish articles like this were posted on blogs, not on twitter. However, the summary at the end roughly aligns with my understanding: v2 or better, v3 is worthwhile.
A while ago I did a bunch of work for our compiler[0], one post of which got a decent amount of HN attention[1]. Same answers: use v2 and v3.
Our posts focused on floating point, but this one does not: it focuses on bit-related instructions. So I see an (expected) clear consistency: regardless of the kind of instruction area, use something more modern than x64 v1. Nice to see. I still hope to find the time for a followup post on integer instructions at some point.
The repo readme doesn't mention anything like that. It looks an ambitious project. I think the AI-style tone in the readme, or things like 'paradigm shift' and that it would be an online service (for a language? huh?) may be contributing to the downvotes you're getting.
> My fucking wife? That's me a) being really proud I married such a baddie
Good for you. I really mean that. I think people are winding you up in this thread, but keep your cool, and I admire publicly crediting and being proud of your wife. That’s a healthy relationship. Good for you.
Why not? Claude marks its commit messages. That there were none, and then there were, seems a signal.
Especially since if the earlier commits were so clearly AI authored yet without the Claude marker, surely you or anyone would be able to spot them. You could say, X commit does not have the Claude commit marker yet was AI written. But for all the speculation on this thread, I haven’t seen anyone actually doing that. What may be possible is that the rsync maintainers used AI to assist yet reviewed and edited themselves, as many devs do, and if so then the stats in this article are still notable: there are no poor quality outliers that can reliably be attributed to AI and if one specific release (3.4.0) was, the subsequent releases which presumably also had as much AI as this speculative hidden AI release only show improvement and thus act as a pro-AI argument.
The blog has many more datapoints than two. It compares many releases. You’re looking at 2-vs, not 2.
I looked at your paper[0] and was curious why it was named "drift" sort. Even searching for 'drift' didn't show me. I mainly ask because this is noted as a stable sort and the word 'drift' implies movement; I did not expect it, from the name, to be a stable sort.
It's called driftsort because it's derived from another sort I made, glidesort: https://github.com/orlp/glidesort. Glidesort is a bit faster still for large inputs, however it was too large and complex for inclusion in the standard library, and suffered from code size penalties on small inputs. So driftsort is a slimmed down version more appropriate for general purpose.
No, but it was also named in the 60s. If someone was three comments deep replying to people asking about it, at some point someone would say "it's quick and in place because it does a recursive partition".
The issue for me is how buggy the modern features are. Continuity with the clipboard: sometimes I copy text on my phone, and it just never pastes on my Mac. Why? No idea. It's not even like text is a complex format. It just... never pastes.
Or this morning I spent ages trying to connect to my phone's personal hotspot. It was a foot away on the table. It kept saying it could not connect. Turn things off, turn them on again, turn off, on again... I eventually moved to where I have wifi. It's a nice day today and I wanted to be outside. Annoying.
And repeated grinding failures like this form a slow, slow, growth of real frustration and annoyance with Apple. I know I don't hold the same attitude to them these days that I used to, and I think it's the whole set of changes since they dropped Aqua. It's not a good OS any more.
The same conclusion: v2 as baseline, v3 where possible.
I'm really surprised it's not standard in every toolchain to support arch levels like this today.
Some compilers like Clang allow multiple arch versions in one binary, runtime dispatched. I would love to implement this in our toolchain too.
[0] Please forgive the SEO-style title, it's, well, to get search engines to recognise what's in the article: https://blogs.remobjects.com/2026/01/26/fast-math-in-six-lan...
reply