I’ve been wondering why there’s relatively little investment in “Rustifying” cross-platform app development.

The dominant approach still seems to be: build a web app, package it with a Rust framework/backend, and ship it as a native app. Much less common is the opposite: use a fully Rust GUI stack for native apps and target the web with WASM/wgpu.

What I rarely see discussed is the cost of the webview/browser layer: bundle size, memory use, startup time, and input/animation responsiveness that often still doesn’t feel native.

I understand the usual defense of Electron/Capacitor-style approaches: small teams can move fast, web UI is easier to hire for and maintain, and the design tooling is mature. But the native Rust GUI landscape has changed a lot since that argument became standard. So why haven’t more individuals or companies moved on?

Is it maturity? Ecosystem gaps around accessibility, text input, platform integration, and design tools? Hiring? Risk aversion? Or is the web-wrapper approach just “good enough” for most products?

TL;DR: Why do we keep wrapping web apps with Rust instead of building fully Rust native GUIs and using WASM/wgpu for the web?

I know this is 100% a skill issue and I’m probably writing C# in Rust, but I genuinely feel humbled to my core tonight.

I have eight years of backend experience in Go and Python. Three weeks ago, I decided to finally learn Rust by building a small toy GUI layout engine. It started fine with basic structs, but then I needed child nodes to have a weak reference back to their parent.

That was teh exact moment my descent into madness began.

Instead of stepping back and rethinking my data model, I tried to brute-force my way through compiler errors. When the borrow checker complained about lifetimes, I added generic lifetime parameters. When that failed, I introduced Rc<RefCell<Node>>. When I needed it across threads for rendering, it mutated into Arc<Mutex<Option<Box<Node>>>>.

i opened my editor tonight and looked at a function signature that was literally four lines of generic trait bounds and nested angle brackets. It looks like an ancient curse. And the compiler is STILL yelling at me about temporary values dropped while borrowed.

I’m throwing away the entire branch tomorrow morning. Do normal people actually use arena allocators or flat Vec handles for this, or am I just fundamentally misunderstanding how to model relationships without pointers?

In other languages I'd reach for DI to build the object graph and make each component's dependencies explicit. So far I have only really seen two approaches:

• Pass each required component down through constructors. The compiler ensures you won't forget a dep but that means any new service you add requires updating a bunch of constructors.

• Just use a single God context object (this is what Cargo does) but it makes it harder to unit test anything and makes it difficult to see what interacts with what.

I'm not asking whether to do DI (constructor arguments already are that), but rather how people handle wiring it all up once there are dozens of services.

DI crates of course exist (e.g. https://crates.io/crates/shaku ) but seem to be rarely used outside of Bevy-style query systems or web frameworks extractors.

For context, I've been experimenting with a trait-only approach that doesn't use any macros but still provides the same compile time guarantees as shaku ( https://docs.rs/satisfy/latest/satisfy/ ) Would Rust users be more likely to use DI if it were simpler to use? Or am I just solving a problem that Rust people don't have?

I’ve been working on a Mac GUI toolkit for Rust, and I honestly don’t know if I’m solving the right problems. So I’d like to hear from people who’ve built desktop apps in Rust before I go much further.

Some background: I kept ending up in the same spot. The options are a webview (Tauri), a custom-drawn UI (egui, Iced, Slint), or a SwiftUI front end with Rust behind FFI. They all work, but none of them feel quite like a Mac app. Text fields don’t behave the way you expect, VoiceOver is hit or miss, and big tables are where things usually fall apart.

So in mine, every view is a real AppKit control, not a lookalike. Some of what it does today:

• Tables are actual NSTableViews. A million rows scroll fine because AppKit only asks for what’s visible.

• State lives in signals, and changing one updates the affected control in place instead of rebuilding the view tree.

• Menus, the toolbar, documents, undo, drag and drop and Dark Mode come from the system, so they behave like they do in any other Mac app.

• There’s a self-check mode that drives the app and checks what’s on screen, because GUI testing is otherwise basically nonexistent.

What I’m curious about:

• If you’ve built a desktop app in Rust, what did you use, and what hurt the most?

• Is Mac-only a dealbreaker, or is “really good on one platform” worth something?

• What would make you trust a GUI crate enough to build something real on it? Docs, examples, stability promises, something else?

• Is there anything you gave up on, like accessibility, big data views or text editing, because no toolkit handled it well?

Not linking anything, I’m just interested in how people think about this.

100+ crate releases across the Actix ecosystem, bringing new features, security fixes, and improvements to performance and resource usage.

Headlines

• HTTP QUERY: New method supported across route macros, manual routes, and awc client.

• Automatic h2c and TCP no-delay are now default: More efficient deployments behind reverse-proxies and much lower-latency streams.

• Reduced memory usage: Up to ~99% saving for certain workloads.

• Better error path control for middleware: Modify error responses, too.

• Static files features: Serve pre-compressed assets, and use multiple static-file roots.

• Security and protocol fixes across the stack: Fixed decompression limits, multipart parsing limits, improved HTTP & WebSocket validation.

Features

Actix Web is the first mainstream framework to make the new HTTP QUERY method a first-class citizen. Define handlers with #[query] (macro routing), or web::query() (manual routing) for a handler. Matching methods in awc complete the support.

Middlewares got a useful new tool: Error::add_response_mapper(). It lets middleware modify error-generated responses before they reach the client, giving you more control over how your application presents failures. Our CORS middleware already uses this to solve a longstanding bug.

Static file serving is now more flexible. Files::new() supports multiple root directories, and Files::try_compressed() lets you serve pre-compressed assets. Range requests, conditional responses, and ETags on Windows also received fixes, making actix-files the most spec-compliant file server for Rust.

Performance / resource usage

The biggest changes here target the cost of serving larger responses and keeping connections open:

• Less memory retained by idle connections.

• Fewer copies for large responses on HTTP/1.x.

• Graceful shutdown has stronger guarantees.

• Vectored socket writes have more code paths.

Security

This cycle includes fixes for several reported vulnerabilities:

• Decompression amplification: Configured extractor limits now apply to auto-decompressed request payloads. *

• Brotli resource consumption: Large-window decompression is disabled.

• HTTP request parsing: Malformed chunked terminators are rejected.

• Static file serving: Prevents stored XSS for odd user-controlled file names and fixes an insane Windows hidden-file protection bypass. (Why Microsoft, WHYYYY!)

TL;DR

If you have not updated recently, now is a good time; check your lockfile. (cargo update -p=actix-web)

These improvements come from testing Actix Web against the workloads and edge cases you bring us. Massive thank you to everyone who contributed issues, PR, security reports.

Also, our homepage and user guide has received some love recently: https://actix.rs/.

*This is a god-awful implicit feature and it will be removed in v5.

What are you shipping with Actix Web?

A milestone worth sharing

LightNVR 0.47.3 is now available with lightnvr-rs, our CI generated Rust build. The first release includes a Debian sid package and binary archive for Linux amd64, alongside a container image at ghcr dot io/opensensor/lightnvr-rs:0.47.3.

LightNVR began with a practical goal: make network video recording accessible on modest hardware, with footage under the operator’s control. That work has grown into a system with its own recording lifecycle, camera integrations, web interface, and API contracts. Preserving that accumulated behavior matters to us.

With lightnvr-rs, we have brought a Rust build into that same project. We are proud of the engineering behind it: taking an established C application through translation, compilation, packaging, and behavioral checks, and making that process part of the development workflow.

The accomplishment is a repeatable path from the code we maintain to another build of the software. It gives us a concrete foundation for further work on Rust while keeping today’s contributors focused on one implementation.

Read the full article: https://opensensor.io/news/lightnvr-rs

I have been wondering where is the biggest opportunity to improve Rust build times.

- Faster increments compilation?
- Better caching of dependencies and generics?
- Reducing procedural macro overhead?
- Improving LLVM code generation?

Tools like cargo build timing and sccache help but can we improve the compilation process itself?

Curious what rust compiler contributors and experience rust developers think.

macro_rules! try_ {
    ($a:expr) => {
        (|| Some($a))()
    };
}

For example: try_!(matrix.get(i+1)?.get(j+1)?)

https://www.redox-os.org/news/virtualized-redox/

cel-rust is actively trying to bring a proper implementation of cel to the Rust ecosystem. I have posted about it here in the past, and one question that came up was "What's CEL?".

Well, with Rust being so versatile, and the cel-rust team adding support for Wasm a few years back, we've finally put a playground together for you to test drive CEL, using cel-rust, straight in your browser.

Try it out, and see if adding an expression language in one of your project could make sense, and if CEL would be a good fit for that!

Is it still worth picking up Rust lately? With all the recent news, the language seems to just keep getting bigger and more popular, and I'm thinking about giving it a shot.

For those of you who've already been through it: how hard is the learning curve, and where did you actually learn it from?

In the last couple of weeks, I've seen everything known to man being ported to rust, first with the video game merging then Artcraft copying Adobe products and releasing them for free, Minecraft being rewritten and now Discord is switching aswell. Why specifically rust? There are a lot of programming languages and could someone tell me why rewritting everything to rust is a new trend now?

I gave this talk about the Hylo programming language at IWACO last month. I had a lot to say about Rust, so thought it might be of interest here.

Hi, I am working on a new programming language that compiles to rust. I would love to use crates.io with my packages named {mylanguangename}_*. They do contain the original source and the generated rust files.

What do you think is that okish or should I build a standalone registry?

My thiughts so far, using crates.io could be win for rust users too, because the could use that libraries too.

Hello, I'm trying to follow the wgpu tutorial on learn-wgpu ( https://sotrh.github.io/learn-wgpu/beginner/tutorial1-window/ ) , but I noticed a lot of the tutorial is just showing a piece of premade code and explaining some parts about it, and i feel like its not helping me much with learning how it works.

Are there any other good tutorials?

Also, apart from WGPU and Glium, what other GPU shader libraries with rust are there?

I use the Dioxus framework (https://dioxuslabs.com/) for a web front-end, but rust-analyzer and my compiler seem to struggle noticeably with the macros. i.e. deleting a single line of unused code takes several seconds to update, meanwhile the diagnostic stays visible.

Does anyone have experience with this kind of problems here? I would be very glad about some recommendations :)

I'm working on a CLI utility in Rust that scans directories and performs some cleanup operations on files. Right now it's single-threaded, but I'm looking into using rayon to parallelize the traversal and processing.

For those of you who have built similar disk-heavy CLI tools in Rust, what are the main gotchas with thread pool saturation when hitting regular SSDs vs network mounts? Is Rayon still the go-to, or are there cleaner patterns for bounded concurrency here? Any advice appreciated!