It’s limited to JS runtimes, but this discussion might be of use: https://github.com/biomejs/biome/discussions/2467 I think you may find Boa fits your criteria, except for the JIT part.

Yeah, sorting is definitely a common use case, but note it also didn’t improve every sorting use case. Anyway, even if I’m a bit skeptical I trust the Rust team that they don’t take these decisions lightly.

But the thing that lead to my original question was: if the compiler itself uses the std sorting internally, there’s also additional reason to hope that it might have transitive performance benefits. So even if compiling the Rust compiler with this PR was actually slower, compiling again with the resulting compiler could be faster since the resulting compiler benefits from faster sorting. So yeah, fingers crossed 🤞

Yeah, it was the first line of the linked PR:

This PR replaces the sort implementations with tailor-made ones that strike a balance of run-time, compile-time and binary-size, yielding run-time and compile-time improvements.

It was also repeated a few paragraphs later that the motivation for the changes was both runtime and compile time improvements. So a little bit bumped to hear the compile time impact wasn’t as good as the authors hoped apparently. I’m not even sure I fully endorse the tradeoff, because it seems the gains, while major, only affect very select use cases, while the regressions seem to affect everyone and hurt in an area that is already perceived as a pain point. But oh well, the total regression is still minor so I guess we’ll live with it.

The post mentioned that the introduction of these new algorithms brings compile-time improvements too, so how should I see this? I assumed it meant that compiling applications that use sorting would speed up, but that seems like a meaningless improvement if overall compilation times have regressed. Or do you mean compiling the compiler has become slower?

Does the Rust compiler use their std sort algorithms, or does it already use specialized ones? If the former, it would be a great side-effect if the compiler itself receives additional speed ups because of this.

From what I understand as I skimmed over the stable sort analysis (https://github.com/Voultapher/sort-research-rs/blob/main/writeup/driftsort_introduction/text.md), it lost out against driftsort.

For a little bit I thought this library might be a subtle joke, seeing the #define _SHITPRESS_H at the start. That combined with the compress() and decompress() not taking any arguments and not having a return value, I thought we were being played. Not to mention the library appears to be plain C rather than C++… surely the author should know the difference?

Then I saw how the interface actually works:

// interface for the library user, implement these in your program:
unsigned int SPR_in(); // Return next byte from input or value > 255 on EOF.
void SPR_out(unsigned char); // Output byte.

This seems extremely poorly thought out. Calling into global functions for input and output means that your library will be a pain to use in any program that has to (de)compress anything more than a single input.

The System76 scheduler helps to tune for better desktop responsiveness under high load: https://github.com/pop-os/system76-scheduler I think if you use Pop!OS this may be set up out-of-the-box.

Essentially, but it doesn’t roll off the tongue as nicely 😅

I can’t say for sure we won’t need to revisit this again as we learn more about the nature of what data is missing and whether with more context we can automatically triage and notify the right people, but for now it feels like the cost / benefit ratio of “talking versus doing” is about right.

This was a nice post, and I agree people should think a bit about how to name things, because getting it wrong can lead to others making wrong assumptions, which ends up wasting a lot of time.

That said, I would get pretty annoyed if a PR I’m involved with ended up with this level of bike-shedding over a function name. If the end goal is to avoid wasting people’s time, bringing out the big guns and making three attempts, with three rounds of review, to get the name of such a trivial function right is surely throwing out the cost / benefit ratio right upfront.

❤️

It’s a fair concern, but if there’s any consolation, we’re experiencing quite the influx of new contributors lately and the maintainer team is growing every month for the last couple of months. There’s a lot of steam coming our way, so I don’t think we’ll run out just yet :)

Surely it would be easier to leave that to the TypeeScript devs and just focus on linting and formatting, no?

Almost nobody uses the TypeScript compiler for transpilation. I think most people nowadays use either Esbuild or SWC for that. The advantage that Biome has is that we already have the parsing and the serialization infrastructure and can add features like that with relative ease. For users that means fewer dependencies, less configuration, and less room for error.

Couple of weeks ago there was a post here calling for more content to be posted in this sub, so I figured you might appreciate the content. As a project, Biome is also helping a lot of web developers become interested in Rust, since many of our contributors make their first-time Rust contributions there.

Please, please make a blog and spew your tirades there 😂

It’s a bit arguing about semantics really. But Rust and Haskell are merely the first ones with patches out. The issue affects other languages as well, including Java, Node.js, Python and seemingly every language with Windows support. I think it’s fair to call it a Windows problem, since it affects everyone there.

But languages like Rust and Haskell are promising their users that they are protected from this kind of behavior, which is why they want to patch it quickly. Some of the others merely updated the documentation, effectively saying yeah it’s a risk. Java went as far as saying they won’t fix the issue.

It also seems harsh to say iterators aren’t a zero-cost abstraction if they miss an optimisation that falls outside what the API promises. It’s natural to expect collect to allocate, no?

You’re right, I wouldn’t say iterators aren’t a zero-cost abstraction. But most abstractions are also leaky – it’s just the extent in which the leakiness is exposed that makes them more or less effective. As such, saying to just use retain_mut instead of the iterator approach highlights the shortcoming of the abstraction. But if the same results could be achieved while still using the same iterator, that would make that abstraction more useful and consistent. And that’s great, because that means we need to worry less when using iterators :)

The composability doesn’t have much to do with whether it’s a reference or a move, it’s because it bypasses usage of the Iterator methods. Iterators chains can consist of filter, map and other operations, which allows various functions and/or closures to be composed together. Whereas with retain_mut() there isn’t really a chain and functions you may otherwise use in an iterator chain become harder to (re)use.

Thanks! That’s very much what I was looking for!

That was a super interesting and informative read! Exactly what I was hoping to find when I posted this, thanks!