5 ms·

The author mentions Rust's portable SIMD library [0]. The only issue with portable SIMD is it's only available on nightly. I used it in my FFT crate, but we had

The author mentions Rust's portable SIMD library [0]. The only issue with portable SIMD is it's only available on nightly. I used it in my FFT crate, but we had to switch to the fearless_simd crate in order to get a portable SIMD solution that works on stable [1]. [0] https://doc.rust-lang.org/std/simd/index.html https://doc.rust-lang.org/std/simd/index.html [1] https://github.com/linebender/fearless_simd https://github.com/linebender/fearless_simd

jonkoops 2mo ago
Pretty common for Rust to cook things in nightly for a very long time; I wouldn't consider it a bad thing, tbh.
- LoganDark 2mo ago
  It's been annoying to me as an end user that so many basic things require nightly. I use nightly as my main toolchain, but enabling unstable features makes a project nightly-only, which is undesired for crates that don't already revolve around the unstable feature. I most often encounter unstable features when I reach for a basic common-sense utility method and discover that it's not stable. Like just earlier today I would have reached for bool::toggle which not only is unstable, but is also newly added as of like a month ago! but some unstable methods have been sitting around for years. And now that IntelliJ-Rust is proprietary, I can't even make a feature request anymore for the ability to exclude unstable features from the autocomplete. So they will taunt me forever, perfect little helpers just locked away.
  - nirvdrum 2mo ago
    [dead]
  - stymaar 2mo ago
    > It's been annoying to me as an end user that so many basic things require nightly It used to be the case a decade ago, but now I wouldn't agree that any "basic" things require nightly (I wouldn't call portable SIMD "basic" at all for instance). > Like just earlier today I would have reached for bool::toggle which not only is unstable, but is also newly added as of like a month ago! This is very likely not the kind of feature that will stay on nightly for a long time, but is instead one of the many convenience feature that land on stable every release. The 6-weeks release cadence with beta in between means there's always at least 6 weeks and up to 3 months between the time a feature land on nightly and the day it reaches stable, even if the feature is as consensual as this one. > And now that IntelliJ-Rust is proprietary, I can't even make a feature request anymore for the ability to exclude unstable features from the autocomplete. Can't you tell it to use stable as the default target, and use nightly manually in cargo?
    - LoganDark 2mo ago
      > This is very likely not the kind of feature that will stay on nightly for a long time, but is instead one of the many convenience feature that land on stable every release. Easy example of a basic method that has been unstable for a really long time: [T]::as_slice [0] since 2024 [1]. Apparently, stabilization was attempted earlier this year [2] but was then rolled back [3]. While clearly it was not yet ready for stabilization, it still took over a year before the first attempt. Another one: Option::zip_with [4] since 2020 because nobody's figured out if it's worth having over .zip(...).map(...). Option::zip was actually stabilized [5] later in 2020 but Option::zip_with has since been sitting in limbo for over five years. Another one: <*const [T]>::as_ptr also since 2020 [6]. I can't remember if there's an alternative now but dealing with slice pointers without relying on unstable methods has historically been very difficult/annoying. I ran into a bunch of this kinda stuff while working on a crate for iterating over rows/columns of image buffer subregions, because I wanted to use and support slice pointers. (Specifically I think getting the length of the slice pointer was nearly impossible without invoking UB, because constructing a reference (which was the only safe way to access a len method) could break aliasing rules. However I think the len method on slice pointers was stabilized a while ago so that particular problem is no more.) Speaking of which, <*mut [T]>::split_at_mut has been unstable since 2022 [7]... I'm not saying there's no reason for any of this, just that as a Rust developer it's been frustrating. There are enough of these all over the place that it feels like a real occurring problem, even if it's not reasonable to expect a volunteer open-source project to pay full attention to everything ever. [0]: https://doc.rust-lang.org/std/primitive.slice.html#method.as_slice https://doc.rust-lang.org/std/primitive.slice.html#method.as... [1]: https://github.com/rust-lang/rust/issues/130366 https://github.com/rust-lang/rust/issues/130366 [2]: https://github.com/rust-lang/rust/pull/151603 https://github.com/rust-lang/rust/pull/151603 [3]: https://github.com/rust-lang/rust/pull/152963 https://github.com/rust-lang/rust/pull/152963 [4]: https://github.com/rust-lang/rust/issues/70086 https://github.com/rust-lang/rust/issues/70086 [5]: https://github.com/rust-lang/rust/pull/72938 https://github.com/rust-lang/rust/pull/72938 [6]: https://github.com/rust-lang/rust/issues/74265 https://github.com/rust-lang/rust/issues/74265 [7]: https://github.com/rust-lang/rust/issues/95595 https://github.com/rust-lang/rust/issues/95595 > Can't you tell it to use stable as the default target, and use nightly manually in cargo? Are you saying it doesn't suggest unstable features when using a stable toolchain? That was not my experience before I started using nightly.
  - saidnooneever 2mo ago
    bool::toggle??
    - jodrellblank 2mo ago
      https://github.com/rust-lang/libs-team/issues/820 https://github.com/rust-lang/libs-team/issues/820 ?
    - LoganDark 2mo ago
      https://github.com/rust-lang/rust/issues/159298 https://github.com/rust-lang/rust/issues/159298 is the tracking issue for the unstable feature
- nextaccountic 2mo ago
  It's a bad thing when there are no breaking changes done and they stabilize the exact same thing a few years later
  - zbentley 2mo ago
    Eh, it's hard to prove absence, and time is a beneficial quantity here. The longer something sits on nightly, the greater the chance that bugs are identified before it reaches stable and its usage significantly increases. A lot of bugs with SIMD libraries are in the domain of interactions, not functionality--e.g. SIMD malfunctions on rare chips, chips with previously-unseen combinations of hardware/userspace firmware/microcode behavior, compilers run in weird harnesses that lie about hardware capabilities, and so on. I assume that's the case with Rust's portable SIMD as well. If your QA is unpredictable individual use-cases (as with most OSS projects), then there's no way to measure "testing complete" or "coverage"; letting it bake for awhile is the best approach available.
    - deleted 2mo ago
      [deleted]
- jmalicki 2mo ago
  For these sort of things, I wish they would have some semi-stable beta or prerelease tracks other than just nightly so you could use the new features on a somewhat stable branch. If something is in nightly that is too crazy for a lot of projects to really try and exercise it because so much is changing constantly. Like a monthly or quarterly stabilization would be amazing, that may still have experimental features not making it into stable, but has a period of bugfixing w/o intentionally breaking changes to settle down.

jonkoops 2mo ago

Pretty common for Rust to cook things in nightly for a very long time; I wouldn't consider it a bad thing, tbh.

LoganDark 2mo ago
It's been annoying to me as an end user that so many basic things require nightly. I use nightly as my main toolchain, but enabling unstable features makes a project nightly-only, which is undesired for crates that don't already revolve around the unstable feature. I most often encounter unstable features when I reach for a basic common-sense utility method and discover that it's not stable. Like just earlier today I would have reached for bool::toggle which not only is unstable, but is also newly added as of like a month ago! but some unstable methods have been sitting around for years. And now that IntelliJ-Rust is proprietary, I can't even make a feature request anymore for the ability to exclude unstable features from the autocomplete. So they will taunt me forever, perfect little helpers just locked away.
- nirvdrum 2mo ago
  [dead]
- stymaar 2mo ago
  > It's been annoying to me as an end user that so many basic things require nightly It used to be the case a decade ago, but now I wouldn't agree that any "basic" things require nightly (I wouldn't call portable SIMD "basic" at all for instance). > Like just earlier today I would have reached for bool::toggle which not only is unstable, but is also newly added as of like a month ago! This is very likely not the kind of feature that will stay on nightly for a long time, but is instead one of the many convenience feature that land on stable every release. The 6-weeks release cadence with beta in between means there's always at least 6 weeks and up to 3 months between the time a feature land on nightly and the day it reaches stable, even if the feature is as consensual as this one. > And now that IntelliJ-Rust is proprietary, I can't even make a feature request anymore for the ability to exclude unstable features from the autocomplete. Can't you tell it to use stable as the default target, and use nightly manually in cargo?
  - LoganDark 2mo ago
    > This is very likely not the kind of feature that will stay on nightly for a long time, but is instead one of the many convenience feature that land on stable every release. Easy example of a basic method that has been unstable for a really long time: [T]::as_slice [0] since 2024 [1]. Apparently, stabilization was attempted earlier this year [2] but was then rolled back [3]. While clearly it was not yet ready for stabilization, it still took over a year before the first attempt. Another one: Option::zip_with [4] since 2020 because nobody's figured out if it's worth having over .zip(...).map(...). Option::zip was actually stabilized [5] later in 2020 but Option::zip_with has since been sitting in limbo for over five years. Another one: <*const [T]>::as_ptr also since 2020 [6]. I can't remember if there's an alternative now but dealing with slice pointers without relying on unstable methods has historically been very difficult/annoying. I ran into a bunch of this kinda stuff while working on a crate for iterating over rows/columns of image buffer subregions, because I wanted to use and support slice pointers. (Specifically I think getting the length of the slice pointer was nearly impossible without invoking UB, because constructing a reference (which was the only safe way to access a len method) could break aliasing rules. However I think the len method on slice pointers was stabilized a while ago so that particular problem is no more.) Speaking of which, <*mut [T]>::split_at_mut has been unstable since 2022 [7]... I'm not saying there's no reason for any of this, just that as a Rust developer it's been frustrating. There are enough of these all over the place that it feels like a real occurring problem, even if it's not reasonable to expect a volunteer open-source project to pay full attention to everything ever. [0]: https://doc.rust-lang.org/std/primitive.slice.html#method.as_slice https://doc.rust-lang.org/std/primitive.slice.html#method.as... [1]: https://github.com/rust-lang/rust/issues/130366 https://github.com/rust-lang/rust/issues/130366 [2]: https://github.com/rust-lang/rust/pull/151603 https://github.com/rust-lang/rust/pull/151603 [3]: https://github.com/rust-lang/rust/pull/152963 https://github.com/rust-lang/rust/pull/152963 [4]: https://github.com/rust-lang/rust/issues/70086 https://github.com/rust-lang/rust/issues/70086 [5]: https://github.com/rust-lang/rust/pull/72938 https://github.com/rust-lang/rust/pull/72938 [6]: https://github.com/rust-lang/rust/issues/74265 https://github.com/rust-lang/rust/issues/74265 [7]: https://github.com/rust-lang/rust/issues/95595 https://github.com/rust-lang/rust/issues/95595 > Can't you tell it to use stable as the default target, and use nightly manually in cargo? Are you saying it doesn't suggest unstable features when using a stable toolchain? That was not my experience before I started using nightly.
- saidnooneever 2mo ago
  bool::toggle??
  - jodrellblank 2mo ago
    https://github.com/rust-lang/libs-team/issues/820 https://github.com/rust-lang/libs-team/issues/820 ?
  - LoganDark 2mo ago
    https://github.com/rust-lang/rust/issues/159298 https://github.com/rust-lang/rust/issues/159298 is the tracking issue for the unstable feature
nextaccountic 2mo ago
It's a bad thing when there are no breaking changes done and they stabilize the exact same thing a few years later
- zbentley 2mo ago
  Eh, it's hard to prove absence, and time is a beneficial quantity here. The longer something sits on nightly, the greater the chance that bugs are identified before it reaches stable and its usage significantly increases. A lot of bugs with SIMD libraries are in the domain of interactions, not functionality--e.g. SIMD malfunctions on rare chips, chips with previously-unseen combinations of hardware/userspace firmware/microcode behavior, compilers run in weird harnesses that lie about hardware capabilities, and so on. I assume that's the case with Rust's portable SIMD as well. If your QA is unpredictable individual use-cases (as with most OSS projects), then there's no way to measure "testing complete" or "coverage"; letting it bake for awhile is the best approach available.
  - deleted 2mo ago
    [deleted]
jmalicki 2mo ago
For these sort of things, I wish they would have some semi-stable beta or prerelease tracks other than just nightly so you could use the new features on a somewhat stable branch. If something is in nightly that is too crazy for a lot of projects to really try and exercise it because so much is changing constantly. Like a monthly or quarterly stabilization would be amazing, that may still have experimental features not making it into stable, but has a period of bugfixing w/o intentionally breaking changes to settle down.