transitive performance benefits
I would have assumed the benchmark suite accounts for that, otherwise the results aren’t quite as meaningfull really. Which ties back you your 2nd senctence: I certainly trust the rust team more than myself on these things :)
only affect very select use cases
I did not read the whole conversation, but sorting seems a very common usecase (not mine, but seems to me a lot of people sort data), so this seems quite a broad improvement to me.
that is already perceived as a pain point
Note though, as is mentioned in the issue, that the survey showed people still prioritize runtime performance over compilation performance in general, so this tradeoff seems warranted.
the total regression is still minor
It’s not unheard of that regressions can be unmade later on, so here’s hoping :)
The post mentioned that the introduction of these new algorithms brings compile-time improvements too, so how should I see this?
I assume you mean the first post of the PR? I’d assume it’s simply outdated (or might not have been true to begin with). See https://github.com/rust-lang/rust/pull/124032#issuecomment-2181789935 for the perf run with this PR, it’s showing quite a bit of regression.
Alas, on the whole the compiler slowed down as a result of this. I think it’s a worthy tradeoff though.
No sarcasm, just an honest suggestion :)
From the Fine Readme:
This project allows you to create games for the Playdate handheld gaming system in Rust lang.
You really should preface every announcement with something like this :)
It’s surprisingly simple: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=f176852c61dcf0c3382f0ac97c26de03
As a side node, asking for a value, and then immediately calling to_string
on it seems kinda hiding the allocation. I’d suggest let the user call to_string
on it themselves.
(e) Changed it a bit to account for passing None
as the third argument.
Seems to be missing mlua at least: https://github.com/mlua-rs/mlua