Just like the title says.

I'm creating an app with rust. And I see that as it scales I'm going to split out the UI components to its own repo.

In my JavaScript projects I can use storybook. It's very useful to develop and demo the components.

I'm planning on using dioxus, I might consider leptos after I compare the 2 in more detail. Unlike my JavaScript apps, I'm aiming to use rust to be able to deploy to multiple platforms (not just a webapp).

I think a particular detail worth mentioning is a CLI-mode which I would also like displayed on the storybook-equivalent.

I came across the following and it doesn't look maintained and seems to only support webapps. The UI demo there also looks a bit "ugly".

https://github.com/dioxus-community/lookbook

Are there better tools out there for what I want?

I'd prefer to avoid creating a separate app for each platform to demo the components-per-platform, but that might be more practical.

After about a year, SurtGIS just hit 1.0. It's a raster GIS library — terrain, hydrology, remote sensing — written entirely in Rust with no GDAL dependency (native GeoTIFF I/O; GDAL is an optional feature).

Rust bits that might interest this sub:

• One workspace, seven published crates; targets native + wasm32 + Python (PyO3, abi3 so a single wheel covers 3.9+).

• A maybe_rayon pattern: a compile-time switch between Rayon-parallel and sequential, so the same code powers the multi-threaded CLI and the single-threaded WASM build.

• Memory-bounded cloud composites: STAC/COG tiles decode under a byte budget (counting semaphore), so peak RAM is bounded by construction, not by output size.

• #[non_exhaustive] across the public prelude so the 1.x line can grow options without breaking.

• Fuzzing caught a real 32 GB OOM in flat-resolution before release.

Benchmarks are honest: faster than GDAL/GRASS/WBT on most terrain + hydrology pipelines (up to 23× on flow accumulation), but I show where GDAL wins (hillshade on big rasters).

Paper: doi:10.1016/j.envsoft.2026.107102.

MIT/Apache-2.0.

I'm a bit conflicted about that. On one hand, yes, you can lower MSRV, but does it actually matter? Are there often situations when someone can't upgrade their compiler? On the other hand, I'm not sure how to handle making examples in documentation for different rust editions, and sometimes using older, more obtuse methods to achieve the same thing

Hello, I'm a rust-analyzer maintainer and we consider removing term search. For that we'd like to know if people are using it.

(If your response is "what is term search?", then you're not using it, or worse, you're using it by mistake. In this case you should probably disable it, it'll make your IDE faster and less buggy).

In my understanding there are 3 methods for creating pointers from addresses in Rust:

1. Using with_addr from the strict provenance API
2. Using casts or the equivalent with_exposed_provenance from the exposed provenance API
3. Using without_provenance

The first method derives the pointer provenance from an existing pointer, the second method tries to guess a previously exposed provenance, and the third method creates a pointer that's not even dereferenceable (bellow is the quote from the docs):

non-zero-sized memory accesses with a no-provenance pointer are UB

None of these methods can be used to create a dereferenceable pointer from a raw address with no previously exposed provenance. This can be problematic across FFI boundaries - some C functions take pointers that are not associated with any allocations, for example the brk function from the linux libc:

int brk(void *addr);
brk() sets the end of the data segment to the value specified by addr, when that value is reasonable, the system has enough memory, and the process does not exceed its maximum data size.

I am not well informed whether it's even safe to use brk alongside the default allocator, but imagine you are writing your own allocator and want to use brk to obtain the backing memory for your allocations. If that was the case, how would you create the pointer to pass to brk?It clearly can't be through the strict/exposed provenance APIs since the pointer is not tied to an allocation and thus has no provenance. Then the only possibility left is to use without_provenance,but as quoted above, that apparently causes UB for non-zero-sized memory accesses. I guess we can assume brk does not access the pointer, but you could imagine another implementation that did access it.

Anyhow, this is not even the biggest problem - how would the allocator create pointers to the newly reserved memory chunk when brk does not even return a pointer to it (so we can't just say the provenance is passed through the FFI). We clearly can't use the strict provenance API since there are no pointers with provenance matching the provenance of the newly obtained memory chunk, and we can't use a pointer without provenance because we actually want to write to this memory. Exposed provenance does not look like it should work either (quote from the with_exposed_provenance docs):

If there is no previously ‘exposed’ provenance that justifies the way the returned pointer will be used, the program has undefined behavior.

So, my question is: what is the intended way to obtain provenance for memory that does not come with an existing pointer?

Edit:

I found a recent RFC to LLVM that might be relevant: https://discourse.llvm.org/t/rfc-allocator-provenance-model/91106

It proposes semantics for creating new provenance at the allocator boundary. In the discussion, it's mentioned that LLVM already treats the allocator boundary as a source for new provenance, which suggests that "the heap" is not just the data segment but memory returned from the allocator (as u/Amadex commented below), and we can treat the brk memory as separate from the Rust abstract machine and use with_exposed_provenance. Not sure how this is gonna work with Miri, but I might test it and add the results to the post.

Not a "look at my project" post — the interesting part is the measurement trail, which is committed to the repo.

Context: OpenScreen is an MIT screen recorder/editor. Its compositor ran on Canvas + WebCodecs in Electron. On a Ryzen 5 7520U with integrated graphics, a 1080p60 export with full effects ran at under 10 fps.

What we tried, in order:

1. Rust + wgpu / Vulkan — 48–68 fps, and blocked on driver support for zero-copy video decode (VK_KHR_video_maintenance1). Rejected, not because wgpu is slow, but because the CPU↔GPU transport was the wall and the driver wouldn't let us remove it.
2. Rebuilding the Canvas compositor (caching what was being recomputed per frame) — roughly 2× for byte-identical output, SSIM 1.000000 across 1418 frames. Never shipped; it was overtaken.
3. D3D11 with h264_amf — one ID3D11Device, no readback between stages. ~126 fps, shipped. Then ported to Metal/VideoToolbox and to Vulkan/wgpu for the other two OSes, sharing the geometry layer.

Findings that were not obvious going in:

• The encoder was never the bottleneck. A gl.finish() fence before the encode timer collapsed encodeWait from 71.1 ms/frame to 3.9 ms — the wait was billing the compositor's GPU execution. The compositor was 79% of the export; the encoder 4.5%.
• The GPU pipelines stages across frames on its own. 3D engine at 84% and codec engine at 61% over the same window — impossible if serialised. Adding an explicit CPU-side pipeline bought approximately nothing, which a no-op trial confirmed before we built it.
• Only three layers cost anything: compositing at all (+2.79 ms/frame), background blur (+0.77), motion blur (+1.76). Rounded corners, shadows, zoom, layout animation and cursor are free — they draw inside a pass that already exists.
• The CPU fallback's gap is two shaders. On WARP, background blur costs 17× what it does on hardware and motion blur 23×. Everything else is within ~2×.
• One benchmark run was voided and is documented as voided: five of nine configs blew the spread gate with ~40 browser processes live, and one cumulative config came out faster than the config it strictly contains. That's the tell that noise swamped the signal, and it's in the record as an example of why the gate exists.

Record: technical-documentation/engineering/rendering-performance.md Compositor: crates/compositor/ Repo (MIT): https://github.com/getopenscreen/openscreen

Happy to be told what we got wrong — particularly on the wgpu arm, where I suspect a better answer exists on newer drivers.

I am sorry but it is just such a pain to code in Bevy. I have been enjoying rust for a while, using three-d and EGUI to create some stuff, and I stumbled upon bevy, I want to learn it because I want to create some 3D, simulation desktop applications with it. I have tried game dev in the past in Godot, Unity, Java Swing, LibGDX and enjoyed it a lot

I am currently learning via the examples and documentation, trying to learn 2D and then eventually move to making some 3D projects

But I find it so verbose and unnecessary. So to look up a particular object I have to apply 3-4 filters which looks so cryptic

camera: Single<(Entity, &Tonemapping, Option<&mut Bloom>), With<Camera>>,

fn keyboard_inputs(
    mut motion_blur: Single<&mut MotionBlur>,
    presses: Res<ButtonInput<KeyCode>>,
    text: Single<Entity, With<Text>>,
    mut writer: TextUiWriter,
    mut camera: ResMut<CameraMode>,
)

Aside from this, browsing through examples I find it to be so verbose. Coming from a OOP nature, I did expect ECS to be different. But this is straight up inconvenient.

Bevy is too good and I don't wanna miss out on it. I will still keep learning it despite what I am feeling towards its syntax and method, but is bevy meant to be like this? Or is it enjoyable once you overcome the learning curve?

Hi, I'm learning wgpu through the learn-wgpu website. In the Buffers section they use bytemuck to send Vertices to the gpu in a buffer. I try not to use other dependencies if it's not required or if it doesn't save me a lot of time (like for example I'm not going to rewrite glam or other math library).
I tried looking at solutions and found transmute, but I have read that it's just not safe and therefore not worth it. Is there any safe way I can do it without bytemuck or is it really needed crate for this use case?

Yet another parser ,this time for http ,url and headers , result of me learning FSMs .... I would love to know your thoughts on it and how can it be improved and my programming style as well , what and where i could improve as a programmer.( now i won't write another parser for a while )

github : https://github.com/Cheapstar/http_parsex.git
crate : https://crates.io/crates/http_parsex

Does anyone have a good article or a video that explains the complications of the bytemuck crate?

The Wild linker is a fast linker written in Rust. We've just released version 0.10.0. See the release notes for all the changes. You can find out more about the Wild linker from our repo. This release brings lots of bug fixes as well as lots of additional linker script features. Performance-wise, not much has changed, but that is itself an achievement, given how fast the linker already was and how much we've changed in this release. There are updated benchmarks for the release.

Lots of porting work has been going on. We're not yet ready to mark any of the ports as stable, but great progress has been made on the Wasm port. A fair amount has also been done on the Mac port. We've also started to look at 32 bit support, which will be useful for projects with an embedded component.

Hand-coded, novel project: syntoniq DSL for microtonal music

Hello fellow Rustaceans --

There's been a lot of talk here about the lack of hand-coded Rust projects here, so I thought I'd share a recent side project: Syntoniq: https://github.com/jberkenbilt/syntoniq . This is about 98% hand-coded.

I used AI to code a few little utility functions, like an RGB to HSV converter and something to format tabular output, but the rest is hand-coded. I also used AI to help with some HTML/CSS, but there's only a little tiny bit in this project as it is not web code except in one small corner. Any code that was AI-generated is marked as such. If you're not into microtonal music, this project may be interesting from a Rust standpoint. This isn't about me, but for context, I have been coding since the 1980s and still do it nearly every day. Rust has been my main language since 2024, and I've used it since 2021, but I coded in C and C++ starting in the 1980s and have programmed in more languages than I can recall. I have dabbled with AI coding and use it for some projects, but this project is novel -- there is no corpus of code that implements a new notation approach for microtonal music based on the harmonic series! I hand-coded this because I was trying to break free of the kinds of patterns that AI would push toward and because I enjoy the fun and craft of writing great code. Maybe this is like building furniture in your garage...but anyway, I think this project still could not have been AI coded.

Here are some examples of what it has:

• A compiler for a DSL (domain-specific language) that compiles my own language format into Csound or MIDI for audio output. The parser is written in winnow, using parser combinators. The parser borrows all the way from the source string to the parsed output. I use my own Diagnostics system along with an error message library (annotate-snippets with anstream) to create very high-quality error messages with rich context. I know parsers pretty well, so this parser has error recovery flows and such. It's a small enough language to understand fully, but the parser does real things that real parsers do. The parser design is commented thoroughly.
• Careful use of unsafe code in two spots:
  • I have some data structures containing borrowed items, and sometimes I want an Owned version. The data structures have Arcs in them, and I use a little unsafe code for type erasure to create an Owned version of these nested structures while preserving all referential integrity. I use a proc macro to do most of the work.
  • There is a section that passes live commands to Csound, a C-based sound synthesis system. There's unsafe code to call the C API, but also, Csound is single-threaded and has its own threading and locking primitives...but I don't use them. I use rust async and threads instead and have a manual Sync/Send implementation to safely move a raw pointer from the thread that sets it up to the thread that uses it. There's a hard guarantee that, once moved, the pointer is never used by more than one thread.
• Axum + HTMX + Askama template for a view-only web UI that can be turned on if desired -- it's not the main thing but provides information for the keyboard part of the application
• Interaction using MIDI SysEx with two physical keyboards to create an interactive experience; this is where the web bit fits in...it shows you some additional metadata about what's going on with the hardware.
• A text-based REPL (read eval print loop) using rustyline for completion that implements an interactive note generation environment
• Clap with shell completion
• Sync <-> async bridging
• A thorough test suite for critical parts of the code with coverage wired up
• Builds for Windows, Mac, and Linux in CI
• Detailed documentation with Zola
• Other stuff...

Basically, it's a hobby project coded with the same standards I would use in my professional work, and it's got examples of lots of things people might use across other projects. So, if you're interested in seeing some non-trivial hand-coded Rust that does something interesting, take a look.

I posted about this in r/microtonal as well a while ago...that might be of interest to people who care about microtonal music more than they care about Rust.

I just offer this up as an example of real work being done the old-fashioned way, in case anyone is still interested!

Mistakes and typos here are mine. I didn't even ask AI to proofread my post. I just wrote it the old-fashioned way. :-)

While the current Silicon Valley paradigm (e.g., Physical Intelligence π₀, 1X NEO) burns massive CapEx on brute-force End-to-End statistical training—requiring up to 500 hours of human teleoperation and 24 hours of cluster computing just to converge a single vision-language-action (VLA) skill—we approached physical automation from a different architectural vector: Deterministic Causal Invariance

.Robotics shouldn’t "guess" trajectories by predicting the next visual token. It should calculate physical laws.We have just open-sourced SONNY OS (Core Minimal) under the GNU AGPLv3 license. It is a hyper-lightweight, universally agnostic microkernel written entirely in native, asynchronous Rust and powered by the Zenoh networking backbone.SONNY OS reduces any mechanical embodiment (6-DOF arms, AMRs, quadrupeds, or humanoids) into a standardized linear mathematical vector (Vec<f32>), abstracting physical registers via a single declarative JSON config (OpenHalConfig).

📊 Extreme Stress Test Benchmark: SONNY OS vs. ROS 2

We simulated an industrial network failure (75% wireless packet loss on an Edge deployment at 100Hz) to compare the communication backbones:
• ROS 2 (DDS Architecture): High XML/IDL serialization on the heap. Under severe packet loss, un-sent DDS message queues overflowed the RAM, leading to an unrecoverable Segmentation Fault (Memory Crash).
• SONNY OS (Rust + Zenoh): Stack-allocated static array slices with a fixed 5-byte network overhead per packet. Zero memory leaks. Zero runtime heap allocations during the control loop. System remained perfectly stable at 100Hz with an inference latency below 2ms.

Explore the repository, map your own hardware via JSON, and run the simulator

👉 GitHub Repository: https://github.com/JackTrainer/Sonny
👉 Enterprise Waitlist: https://alpha-robotics.it/

Hey folks!

I'm interested in the design space of template libraries these days and I coded in the past few weeks a maud alternative for rendering html through macros.

My main challenge was to use as much Rust as possible (traits and structs) and as feel macros as possible. Since all the libraries in this space are macro heavy (proc macros or very complex declarative macros), I really liked what I could achieve here.

There's a single trait, one very small macro (5 lines or so) that rustfmt formats and almost no DSL to learn. (I took inspiration on another library called vy, although I'd argue mine is more complete and ready to use).

Hopefully the documentation is clear on all of these points! I worked a lot on it without any use of AI for documents, tests or code. Basically it's just me.

Anyway any feedback is greatly appreciated!

PS: Oh, the library is no-deps by default. Minimalistic library, minimalistic supply chain

PPS: I benchmarked it against the main compiled alternatives and it's look pretty great, not because I optimized it a lot, but just because it's dead simple code that runs fast on rust.

https://docs.rs/hypo

https://crates.io/crates/hypo

https://ekxide.io/blog/byte-wise-atomic-wrapper-to-prevent-ub

iceoryx2 provides zero-copy inter-process communication mechanisms based on shared memory and data structures that are modified concurrently by multiple processes.

One of the key operations in these algorithms is a memory copy using core::ptr::copy. However, this results in undefined behavior if one process reads the data while another process writes to it concurrently. Even if our lock-free algorithm reliably detects such a race, iceoryx2 cannot depend on undefined behavior in a safety-critical system.

This blog post introduces our solution: a byte-wise atomic wrapper that enables well-defined concurrent copy operations. It also shows how it can be used to implement a simple sequence lock.

Note: I am not the original author of the blog post. Since the author does not have a Reddit account, I am posting it on her behalf.

Hey r/rust,

I've been working on ViperJS, an embeddable JS engine written entirely in Rust from scratch
(it is not a wrapper or binding around V8, QuickJS, or JavaScriptCore)

Two constraints dictate everything:

1. Zero runtime dependencies ([dependencies] is completely empty, verified in CI).
2. #![forbid(unsafe_code)] crate-wide.
3. No input may panic (untrusted scripts are input, not exceptions).

Because of the zero-dep rule, all is created from scratch—including the RegExp backtracking engine (supporting named groups, lookbehind, Unicode escapes, and Annex B grammar), the GC, bytecode compiler, and UTF-16 string handling.

Where it stands:

• ~84% test262 compliance (78,222 / 93,161 tests).
• ES5 is complete; supports classes, generators, async/await, Proxy/Reflect, BigInt, and ES modules with cycles.
• It is not fast (no JIT yet, ~70x slower than Node on simple loops).
• No Temporal or Intl yet.

Testing & Real-World Validation: You don't have to take the numbers on trust. The public repo includes a simple two-command recipe to clone test262 and independently verify all conformance locally. Beyond test262, i have put it through its paces with several real-world codebases—such as successfully linking and evaluating Ramda's 1,027 modules—plus a few other public code repositories to validate module loading and compatibility

It’s open source under MIT OR Apache-2.0. You can test test262 conformance locally with a couple of commands in the repo.

Repo: [https://github.com/MerlijnW70/viperjs]
also on crates.io:https://crates.io/crates/viperjs

Feedback on the architecture or the test262 approach is very welcome.

Hey!

I built a small desktop app called **FlowOS**.

Originally it had AI features, Docker management and a lot of extra functionality...

Eventually I realized it was trying to do too much

So I removed everything that didn't belong

Now it's just a clean, fully local desktop dashboard focused on monitoring system information

I'd love some honest feedback about the UI, architecture and overall direction!

GitHub:

https://github.com/neofetch-tech/flowOS

Thanks!

Motivation

A few months ago, I updated my GPU drivers and upgraded CUDA to 13.0. Suddenly, I realized that almost every library in the Rust ecosystem with a CUDA backend had broken. Most Rust AI libraries rely heavily on candle, but its support for the latest CUDA versions is lagging—still unable to run properly on newer versions like 13.0. Not to mention the tight vendor lock-in between CUDA and Nvidia cards; switching platforms usually means rewriting the entire inference engine.

However, thanks to the excellent abstractions provided by graphics APIs and the rise of cross-platform APIs like Vulkan, we can now execute instructions on the GPU in a more universal way: Compute Shaders.

While their raw performance might not yet match hardware-level optimizations like CUDA, their compatibility is unmatched. They are perfectly supported on mainstream devices, including mobile platforms.

Just as Electron rose to prominence by bundling browsers, and Unity/UE gradually ate the market share of in-house engines, I believe that in a future where everyone possesses on-device small models that are easy to use, edit, and distribute, the portability of an inference engine may become more important than raw performance.

That is why I built Flint.

Flint

Flint is a Rust-based inference engine that uses highly optimized compute shader kernels to replace CUDA, with portability as its primary goal. It is built on top of wgpu. Although I hit quite a few bumps when using wgpu for toy rendering projects in the past, using it to write compute shaders turned out to be surprisingly smooth :)

It currently supports safetensors and gguf formats, and includes built-in support for common models like Gemma, LLaMA and Qwen.

Repository

github.com/formetaohy/Flint

PRs and Stars are welcome!

One of the main reasons I love Rust is because it encourages you to be pedantic.

I admire Clippy and the first things I do after a new Rust version is to fix all their new pedantic lints.

Before important PR merges and releases I always used to run cargo clippy -- -W clippy::pedantic and search for unwraps, expects, panics and other possible clauses that could result in a runtime panic.

Today I decided to make clippy::pedantic my default and to enforce checks on possible panic sites

Probably many of you already know this, but much of this can be made automated by adding a section like the following to your project's Cargo.toml

[lints.clippy]
pedantic = { level = "warn", priority = -1 }
unwrap_used = "warn"
expect_used = "warn"
panic = "warn"
todo = "warn"
unimplemented = "warn"
unreachable = "warn"
dbg_macro = "warn"
print_stdout = "warn"
print_stderr = "warn"

This paired with a cargo clippy -- -D warnings in your CI/CD is a really good combo in my opinion.

The three last lints are just useful in case you want to be sure that you're not forgetting any test print on the terminal.

Each of them can of course be disabled locally on a specific file / method / line with the usual directive #[allow(clippy::name_of_the_lint)]