Fearless SIMD reaches v1.0 with safe abstractions for Rust
Shnatsel, writing on the Linebender blog on September 22, 2026, announced the release of Fearless SIMD v1.0, a Rust crate that provides safe SIMD (single instruction, multiple data) abstractions, together with a new companion crate, fearless_simd_macros v0.1. The project traces back to a prototype built 8 years ago and has now reached a stable 1.0 release, with a commitment to 3 years of security updates for v1.0 and every version that follows.
The post frames the release around four goals. On performance, the author says Fearless SIMD offers both precise cross-platform variants and faster platform-dependent variants for operations like swizzles or floating-point maximum, lets code use the hardware's native vector width or fixed sizes, and allows dropping down to raw platform intrinsics with no overhead when portable abstractions fall short; the author states that thanks to safe access to intrinsics, there is no performance ceiling, though no benchmark figures are given.
On safety, the author contrasts Fearless SIMD with other SIMD abstraction crates, which typically contain several thousand unsafe blocks. Fearless SIMD avoids ad-hoc unsafe code through a kernel! macro that uses a compiler feature to invoke most SIMD intrinsics safely, plus a small safe-transmute module (inspired by crates like bytemuck and zerocopy) that handles raw-pointer load and store operations. The author argues that because only these two small, self-contained building blocks need to be audited for memory safety, the rest of the codebase is guaranteed to be memory-safe as well.
On ergonomics, the new fearless_simd_macros v0.1 crate introduces a #[simd] macro that handles function multiversioning without requiring developers to add inline annotations or think about overhead, addressing a problem the author calls a 'leaky abstraction' in prior approaches. The author notes ergonomics may still evolve, but says code written today, with or without the #[simd] macro, will continue working indefinitely, and boilerplate reduction is a future goal, potentially via the Struct Target Features RFC.
On Rust's own unstable std::simd, the author says Fearless SIMD will not become obsolete once std::simd stabilizes: the standard library only implements a subset of what's needed, and Fearless SIMD would be ported to build on top of it while cutting custom code and gaining support for more platforms.
On adoption, the post states that Fearless SIMD is already used by 30 other crates as a direct dependency and is relied on indirectly by over a thousand crates, calling it a foundation for a nontrivial fraction of the Rust ecosystem. The author closes by pointing readers to the project's documentation, examples, and its Zulip channel for questions.
Key facts
- Fearless SIMD v1.0 and a companion crate, fearless_simd_macros v0.1, were released on the Linebender blog by author Shnatsel on September 22, 2026, 8 years after the original prototype.
- The project promises 3 years of security updates for v1.0 and all later versions.
- Unlike other SIMD abstraction crates, which the author says typically contain several thousand unsafe blocks, Fearless SIMD avoids ad-hoc unsafe code via a kernel! macro and a small safe-transmute module.
- The new fearless_simd_macros v0.1 crate adds a #[simd] macro to simplify function multiversioning without manual inline annotations.
- Fearless SIMD is already a direct dependency of 30 crates and is indirectly relied on by over a thousand crates in the Rust ecosystem.
Why it matters
SIMD code (instructions that process multiple data elements at once for speed) is usually written with heavy use of Rust's unsafe keyword, since it involves raw platform intrinsics and pointer operations. Fearless SIMD's pitch is that it removes that burden almost entirely: the author says the crate is engineered so that only two small, self-contained building blocks need to be audited for memory safety, with the rest of the codebase guaranteed safe as a consequence. Reaching a stable 1.0 after 8 years of development, with a 3-year security-update commitment, signals the project is positioning itself as a long-term foundation rather than an experiment.
Who it affects
Rust developers writing performance-critical code that uses SIMD, including the maintainers of the 30 crates that depend on Fearless SIMD directly and the more than a thousand crates that rely on it indirectly through the dependency chain. It also matters to anyone weighing Rust's still-unstable built-in std::simd against ecosystem alternatives.
How to use it
Fearless SIMD v1.0 is available as a Rust crate, alongside the new fearless_simd_macros v0.1 crate that adds a #[simd] macro for simplified function multiversioning; developers who prefer not to use procedural macros can still use the crate's original approach. It works on stable Rust, supports both hardware-native and fixed vector sizes, and allows dropping to raw platform intrinsics for operations not covered by its portable abstractions. The author points readers to the project's documentation and examples, and to its Zulip channel for questions.
How solid is it
The account comes directly from the project's own author, Shnatsel, in a blog post on the Linebender blog, so the performance and safety claims are the project's self-description rather than independently verified benchmarks; no specific performance numbers or percentages are given, and the post does not name which crates make up the 30 direct or 1,000-plus indirect dependents. The 8-year development history and the crate's existing adoption by 30 other crates are stated as fact in the post.
Risks and caveats
The author flags ergonomics as the area most likely to still change, and the #[simd] macro approach still involves some boilerplate that the project hopes to reduce further, potentially pending a compiler RFC. The post gives no timeline for when Rust's std::simd might stabilize or when Fearless SIMD would be ported onto it, and provides no detail on funding, sponsorship, or team size behind the project.
“The crate is carefully engineered not to require ad-hoc unsafe code.”
— Shnatsel, Linebender blog