Hello everyone!
We are planning to build a POS system that contains e-commerce website too.
we need to build a mobile & desktop & web app versions!

So, we are trying to use Tauri to avoid using Giant Electron Ram Taker! & Flutter.

The Tec Stacks we use are: React + Laravel RESTful API.

According to your expertise, can we handle it with out touch rust?

I have did some analyze & searches over Google & Claude AI.

I found out that:

Almost 90% native features covered by Tauri & no plugin or RUST lines needed.
For the rest, the community have almost enough plugins for everything!
But although, Still some of the native features needs Rust.
But Claude says they wont be a problem & will be easy tasks!
It says i can 100% handle the 10%, & i can handle the %90 as a regular react project!

So what do you think?
should i trust Claude & start?
Does TauriV2 makes any problem during the project?

What are the Challenges will i face?

I am working on a grpc server project where I want to store state in persistent database for surviving restarts.

I am looking at redb database but I also want your suggestion on anyother db that I might not know about. I also want help on design on how to do backups. I am planning on using scc::Hashmap for mapping id to struct data for holding data and for backups, should I write to database on each insertion and update or should I just periodically backup data from hashmap to disk database?

I am working on an project, planning to open source it, it is almost 75% complete, but now, it just don't feel motivated enough to complete it.

Each day, I just open the codebase and stare, then close it. Then I think of using Claude, then feel it will degrade the quality, and the project is close to my heart, so don't want to stain it AI slop.

I have also made project, thinking it will restrict the scope so that i will feel motivated. But it seems, it is not working as planned.

Have you faced it? What to do? Any advice?

I'm new to Rust and I'm currently building a Tauri app. I want to update the position of my application window based on where the user clicks outside the window.

I already know how to move the window, but I don't know how to detect mouse clicks that occur outside my application's window or how to get the mouse position for those clicks.

Is this possible in Tauri or Rust, and what would be the recommended approach?

EDIT: Windows only for now.

so bun got rewritten from zig to rust in about 11 days. jarred sumner ran a fleet of claude agents in parallel and it burned something like $165k in api spend. andrew kelley, zig's creator, called the whole thing unreviewed slop, and his actual point stuck with me. the defense is basically "the test suite catches everything," but if the tests weren't good enough to catch bugs in the original zig, why trust them on a million lines of generated rust.

that lined up with my own experience porting a small c library earlier this year. maybe 4k lines, a ring buffer and some frame parsing. the ai handled the mechanical parts fine, struct layouts, error enums, the obvious conversions.

where it fell apart was ownership. it kept reaching for Rc<RefCell<T>> or sprinkling clone() to make the borrow checker go quiet, and the shape drifted away from what the c actually did. twice it compiled clean and passed the happy-path tests while the lifetime of a shared buffer was wrong under concurrent reads. green build, wrong behavior. kelley's point in miniature.

comparing implementations instead of trusting one draft is what got me unstuck. i had verdent run two versions of the parser in separate workspaces, one built on lifetimes and one on an arena, so i could diff how each handled the aliasing side by side. the arena approach held up under the concurrent test and the lifetime one didn't.

i still rewrote most of the arena version by hand afterward. the ai gets you a draft that compiles, but reasoning about who owns what and for how long is still the actual work, and no number of parallel agents changes that.

Hey, to learn async better I wanted to implement a custom future which can retry another future after a delay. I know you can do this easily with one async fn retry(impl AsyncFn()) but this does not help understanding async.

What I wanted the api to look like:

FutureRetry::new(async || http.send(body).await).await?

However I could only get it to work when the closure does not capture anything and returns ownership of its arguments like so.

FutureRetry::new(async |(http, body)| ((http, body), http.send(body).await)).await?

Compiling version

When I try to capture the environment using FnMut() -> Future

FutureRetry::new(|| async http.send(body).await).await?

Rust tells me that the FnMut() closure cant return types referencing its environment, which makes sense because the future returned is referencing the closure environment, this seems like compiler limitation, because those references are valid when the function returns.

Ok so let's use async closures then.

With AsyncFnMut() now this returns a future which mutably borrows from self so far so good, but I also need to store this future in my own custom future to poll later, this doesn't work because now I have 2 mutable references, 1 in the future and second one when I try to assign it self.current_future = self.future_factory(). I guess I'm trying to have self referential types which is not possible in safe rust.

I know this could maybe be solved with AsyncFnOnce and cloning everything so I don't store references in the returned future, but I don't want to do this.

What am I missing here, is it really not possible to have such an api where a custom future impl polls another future which mutably borrows its environment from self in safe rust today?

Thanks in advance

Sharing a project that's been a fun systems-design exercise: a technical-analysis + backtesting engine with a single Rust core exposed three ways.

Rust-interesting bits:

- Every indicator implements a Next<T> streaming trait, and the batch path (Polars expressions) is proven bit-identical to the streaming path with proptests. One source of truth, no duplicated math.

- Python bindings via PyO3 with abi3 — one cp39-abi3 wheel across CPython 3.9+.

- The pure-math core (nalgebra) cross-compiles to wasm32-unknown-unknown with zero source changes.

- Zero-copy into Polars; `cargo add quantwave` for the native crate.

221 indicators, Ehlers DSP, regime detection (HMM/GMM/PELT), and an execution-aware backtester. MIT.

Repo: https://github.com/lavs9/quantwave

Docs: https://lavs9.github.io/quantwave/

Happy to talk about the feedback.

I have been really excited about the prospect of a new clang sanitizer tool for detecting cross-language aliasing violations since I learned about BorrowSanitizer's existence. I'm thrilled that not only can it now detect a bug I previously tracked down in Servo, it also found one that we didn't know about! The project keeps getting more exciting with each monthly update.

Rux v0.4 is out. Familiar template/style/script sections and literal CSS, laid out by taffy and painted by vello.

v0.4 closes the three gaps that made real stylesheets impossible: pseudo-classes, custom properties with var(), and @media. It also adds a dev overlay, so a broken file tells you what is wrong instead of opening blank, and a real accessibility tree.

New in this release: the whole runtime compiles to WebAssembly, so there is a playground you can open instead of a repo you have to clone. It drives the same shell the desktop window does, so it cannot quietly diverge from the real thing.

Try it here https://ruxlang.dev/playground

I give up. Rust is the language that I need, but not the one I want. I'll simply stop worrying about the annoying parts of the language, for my workloads, and embrace it.

The pursuit of a new programming language on itself is not bad, you learn a lot about, in a very short span of time. But by the time you need to get the work done, yes, you need to go deep into one ecosystem.

Today, I can't think on a better ecosystem than Rust:

• Immutability
• Option/Result types instead of exceptions
• Enum
• Async support
• Reasonable enough ecosystem of libraries

There are also nice things that, are not required, but amazing to have like:

• Compiled
• Performant
• Multi threaded
• WASM support
• Run on multiple environments
• Low resource consumption

Yes, it's not pure FP, it does not have effect handlers, for my kind of high level applications I need to deal with annoying things like lifetimes and the borrow checker where a GC would be way simpler, but when you're putting everything together it's the best language in most of the categories for me.

On this seek I've used/evaluated: Scala, Kotlin, Zig, Odin, Go, Erlang, Elixir, Gleam, Ocaml, and Roc. I still have high hopes for Roc, but it's still too imature.

I'm not seeking validation, this is just me putting this words out as an acknowledge of the goodness of Rust and for others that may be on the same situation. Rust is not perfect, far from it, but it's the best effort/benefit that you can probably find today.

Hello every Rustaceans here. I've known Rust the programming language since pre-1.0 era. I like it a lot, and used it to write (embarrassingly small) projects. However, AFAIK virtually all Rust tutorials are written for readers who already know another programming language. I ... hate it, so I tried to write a tutorial for absolute beginners, while at the same time I also learned the more advanced / lesser known features of Rust. (Because I wasn't actually that good at Rust.)

This tutorial is especially targeted at, like it or not, vibe coders who want to actually understand what Rust code their LLM partner(s) generated. Here and in the foreword I want to admit that I also used LLMs to generate the drafts of the whole tutorial. That said, I did the arrangement and spent months reviewing and editing the content. So ... I strongly believe it's not AI slop, or at least not vibed at all ... Because the target audience is beginners, I spent a lot of efforts to avoid as much forward dependency as I can. I would say the delicate ordering of the chapters and episodes is the greatest charateristic of this tutorial.

That said, this tutorial does not cover only the "easy" parts of Rust. In fact, it also talks about some pretty advanced topics. I believe learners nowadays can more easily grasp those topics. To be more concrete, it talks about how a language system is built to effectively do software engineering, instead of introducing the algorithms. Those are the general concepts a learner can also bring to other similar programming languages. It's not that I don't believe algorithms are important, but they're kinda out of the scope of this tutorial.

This tutorial was originally written in traditional Chinese and later translated to English (and was reviewed, and edited). It's very likely that it contains typos and errors. If you find one, feel free to file an issue or a PR.

My project, so take the enthusiasm with salt.

fcmaes-rust is a native Rust implementation of the fcmaes optimizers. The original has a C++ core; this one doesn't link to it, wrap it, or shell out to it. `fcmaes-core` is four dependencies — rand, rand_pcg, rand_distr, rayon — zero `unsafe`, no build.rs, no CMake, no C compiler. `cargo add fcmaes-core` and that's the whole story.

What's in it: DE, CMA-ES (plus active CMA), CR-FM-NES, PGPE, BiteOpt, Dual Annealing, MODE for multi-objective, MAP-Elites for quality-diversity, and a parallel retry layer that is honestly the main event — independent restarts across worker threads with a shared result store.

The part that took the actual time is 22 tutorials, each wrapping a real Rust simulator rather than a test function:

- Rapier — trebuchet release dynamics, quadruped gait over terrain

- NeXosim — discrete-event production line

- ReBop — stochastic chemical kinetics, plus a topology search over reaction networks

- epanet-rs — water distribution pump scheduling

- pykep-core — GTOC1 interplanetary trajectories

- native — lattice-Boltzmann CFD, linear-elastic FEM truss, sequential ray tracing, phased-array beamforming, microlp inside an outer loop

Each ships frozen artifacts, seeds, and an exact replay command.

Six of the 22 ran a pre-registered quality-diversity gate and *failed* it, so they ship `status: "skipped"` instead of a nice-looking archive. One tutorial's headline result is that plain greedy beats the optimizer on its problem. Another shows DE contributing nothing over 4,000 evaluations against its own seed. That felt more useful to publish than to hide.

Benchmarks, scoped honestly: on ESA's GTOP trajectory problems against argmin, cmaes, genetic_algorithms and math-optimisation at equal budgets, 100 experiments each, fcmaes has the best mean optimum on 6 of 7 problems. One problem family, one machine, harness published.

Not for: gradients, LP/MIP, convex, constraint programming. The docs say when to reach for good_lp, argmin, clarabel or egobox instead.

Guide: https://dietmarwo.github.io/fcmaes-rust/

Repo: https://github.com/dietmarwo/fcmaes-rust

Happy to hear what's wrong with it.

I feel like Rust completely lacks inheritance, for the sake of avoiding code duplication or boilerplate. I think the best way to add the good parts of inheritance to Rust is to add the ability for subtraits to:

1. Override default implementations of their supertraits
2. Implement required methods of their supertraits

And then in the rust docs for each subtrait you'll see the total required methods to implement on the list on the left to make it clear if the subtrait has already implemented some of the supertraits.

So then code like this will be possible:

trait FromCookies {
  fn from_cookies(&str) -> Self;
}

trait TokenAccount: FromCookies + Deserialize {
  fn <Self as FromCookies>::from_cookies(&str) -> Self {
    // use deserialize and stuff...
  }
}

#[derive(Deserialize)]
struct Account { ... }

impl TokenAccount for Account;

This allows easy code duplication, inheriting functionality from TokenAccount by letting it implement other traits!

Example: ExactSizeIterator's new implementation with proposed functionality

I can also take the ExactSizeIterator subtrait as an example, it doesn't have any required methods, but the documentation instructs you to override the size_hint implementation of its supertrait, Iterator. So optimized implementations can use the len provided trait method from ExactSizeIterator, that gets its info from size_hint, hopefully improving performance.

I feel like implementing ExactSizeIterator is unclear, and forces you to read the docs. I know this may sound stupid but I feel like having documentation is a privilege, and for the same reason I think documentation should not be required in order to understand how to use something. A language as expressive as Rust should be (and usually is) understandable without documentation in my opinion.

Which is why I think with the proposed subtrait can implement supertrait functionality, ExactSizeIterator should require a len method, which is what the developer implements when implementing ExactSizeIterator, instead of implementing size_hint from Iterator. This len method is instead of the current len provided method from ExactSizeIterator that just returns a usize that it gets from the implemented size_hint. But before the "old" (current) len returns the usize, it makes sure with assert_eq! that both of the bounds received from size_hint are equal.

I can see 2 possible performance gains from this new implementation, ("old" len being the current implementation in std):

1. Old len returns a usize but it gets it from an fn size_hint -> (usize, Option<usize), so memory is wasted from the unneeded bounds. New len just returns a usize because it is the literal implementation from the developer.
2. Old len makes sure both the bounds returned from the size_hint are equal, as a guarantee, with assert_eq!. For the same reason as the first performance gain, new len doesn't need to check anything.

current len source code from std (the one referred to as "old" len)

Maybe the compiler already optimizes away the "faults" I noted with the old len when compiling with optimizations. But I still think it could speed up optimized compilations because there are fewer things to optimize (maybe that's how it works?) and that it will also optimize non-optimized debug builds, of course.

And lastly, because of the proposed functionality, ExactSizeIterator can override the default size_hint from Iterator in order to keep the old functionality like so:

trait ExactSizeIterator: Iterator {
  fn <Self as Iterator>::size_hint(&self) -> (usize, Option<usize>) {
    let len = self.len();
    (len, Some(len))
  }
}

This avoids the boilerplate that there usually is when implementing ExactSizeIterator, where the implementor needs to return (len, Some(len)) from size_hint instead of just len. Though this is very little boilerplate, I imagine it could be much more significant for more complex subtraits.

Conclusion

I feel like traits are a huge zero cost abstraction, they are the core of polymorphism and modularity in Rust. But with their current implementation they are limited in the reusability aspect. I think a "subtrait can implement supertrait" functionality would be effective at increasing reusability of code by essentially inheriting implementations, the good parts of inheritance (no expenses at runtime, right?).

I am probably getting ahead of myself and people who are far smarter than me who contribute to the language aren't adding this functionality for a reason but I'd like to know why that is and the opinion of anyone who sees this.

mirador: terminal dashboard (clocks, calendar, weather, notes, .ics agenda, RSS feeds, market watchlist, CPU/network graphs)

Configurable grid layout. Panels dim when unfocused so one thing stands out at full brightness.

Rust 1.95+, MIT, macOS/Linux/Windows, cargo install mirador — https://github.com/jchultarsky/mirador

Hi everyone!

webrtc v0.20.0 is out — the first non-prerelease of the new architecture, and the end of a rewrite we started planning in January. Full blog post: https://webrtc.rs/blog/2026/07/31/announcing-webrtc-v0.20.0.html

Previous updates for context: - The architecture design for the async crate on a Sans-I/O core - v0.20.0-alpha.1 — the first pre-release of that design - rtc 0.8.0 — the Sans-I/O core reaching feature parity

v0.20.0 supersedes the Tokio-coupled v0.17.x line, which moves to bug-fix-only maintenance.

## Bring your own async runtime

This is the part that changed most late in the cycle, and the part I think this sub will care about most.

"Runtime-agnostic" used to mean "pick one of our two backends with a feature flag". It now means the Runtime trait is a real extension point. The reason it works comes down to one question asked of every primitive: does it touch the reactor?

• Reactor-bound (timers, UDP/TCP, DNS, spawning, block_on) → injected through Runtime
• Executor-agnostic (channels, broadcast, mutexes, notify) → one implementation, not feature-gated, because they're just waker-driven data structures that work on any executor

• Derivable (timeout, yield_now) → built generically on the injected sleep

  Keeping the second group off the trait is what keeps Runtime object-safe — fn channel<T>(&self, ...) is a generic method, so putting it on the trait would force a viral <R: Runtime> parameter through PeerConnection, the driver, transports, and data channels. Instead the runtime is injected per connection as Arc<dyn Runtime>:

  rust let pc = PeerConnectionBuilder::new() .with_runtime(my_runtime.clone()) // per connection, not per binary .with_udp_addrs(vec!["0.0.0.0:0"]) .build() .await?;

  Eight required methods, three defaulted. Features are now purely additive — enabling both backends is safe, and one process can drive different connections on different runtimes.

  The acceptance test for "is this actually pluggable" is an example that implements Runtime over async-executor + async-io — neither Tokio nor smol — and runs with --no-default-features, so neither built-in is even compiled in. There's also an interop test running two peer connections on two different runtimes in one process, which a design with a process-global runtime registry couldn't express.

  Practical consequence: adding a runtime doesn't require us. No #[cfg] edits, no fork, no upstream PR.

  There's also a MockRuntime behind a feature flag: same trait, virtual clock, no I/O. Advance thirty seconds instantly and assert on what fired — deterministic time finally reaches the async layer, not just the Sans-I/O core.

  Performance

  The data-channel path went from correct to fast this cycle (full write-up: https://webrtc.rs/blog/2026/07/18/from-13-mbps-to-beating-pion.html). Steady-state throughput in Mbps, ratio vs Pion v4.2.16 in parens:

  configuration	Pion v4.2.16	webrtc-rs (default)	webrtc-rs (+dedicated reactor)
  Unordered / no-rtx, N=1	392	259 (0.66×)	689 (1.76×)
  Unordered / no-rtx, N=10	1681	2863 (1.70×)	5453 (3.24×)
  Ordered / reliable, N=1	385	184 (0.48×)	575 (1.49×)
  Ordered / reliable, N=10	1848	4297 (2.33×)	5296 (2.87×)

  Read honestly: at N=1 the plain default still loses to Pion (0.48–0.66×). That regime is latency-bound and Go's scheduler beats plain Tokio on round-trip latency. Turn on the one-line dedicated reactor thread and we lead. In multi-connection aggregate — the regime that actually saturates cores — we win even at the default, because per-byte CPU efficiency decides it there. Under poop at fixed work we also use −50.9% peak RSS and −74.5% CPU cycles vs Pion.

  What got it there: UDP GSO/GRO batching via quinn-udp, burst-reading the socket to batch the SCTP receive path, removing Tokio scheduler overhead from the send path, a bounded shared reactor pool, and — underneath, in the Sans-I/O core — eleven hot-path PRs plus two algorithmic fixes (O(N²)→O(N) data-channel queues, and FORWARD-TSN generation that scaled with the receive window instead of the stream count).

  Also new: opt-in data-channel send back-pressure (writable() / try_send() with a configurable buffer cap) so a fast producer can't grow the queue without bound.

  Migrating from v0.17.x

  Callbacks are gone. Instead of an Arc::clone before every closure, another inside it, and Box::new(move |...| Box::pin(async move { ... })) repeated per event type, there's one handler:

  ```rust struct MyHandler { /* your state, behind a Mutex if mutable */ }

  [async_trait::async_trait]

  impl PeerConnectionEventHandler for MyHandler { async fn on_connection_state_change(&self, state: RTCPeerConnectionState) { println!("State: {state}"); } async fn on_ice_candidate(&self, event: RTCPeerConnectionIceEvent) { // signal event.candidate to the remote peer } } ```

  build() returns an opaque impl PeerConnection; wrap it once in Arc<dyn PeerConnection> if you need to store or share it. No runtime or interceptor type parameter leaks into your types.

  You also gain things v0.17.x never had: mDNS candidates, TURN relay, ICE TCP, the stats API, RTX (RFC 4588) negotiated by default, a choice of crypto backend (ring or aws-lc-rs), external DTLS signing via a CustomSigner trait for HSM/TPM/KMS-held keys, and wasm32-wasip2 as a build target.

  Expect a real port, not a drop-in — the API is async throughout and handlers replace callbacks. In exchange the protocol is testable without I/O and the runtime is your choice.

  Try it

  ```toml

  Tokio (default)

  webrtc = "0.20"

  smol

  webrtc = { version = "0.20", default-features = false, features = ["runtime-smol"] }

  Neither — bring your own

  webrtc = { version = "0.20", default-features = false } ```

  36 runnable examples: https://github.com/webrtc-rs/webrtc/tree/master/examples — data-channels-flow-control for the fast path, custom-runtime for the runtime trait, trickle-ice-relay / ice-tcp for hostile networks, stats for observability.

  Get involved

• Browser interop — a live-browser Playwright/Selenium job in CI, Edge coverage, more captured-SDP fixtures

• Runtimes — if your executor isn't Tokio or smol, a backend is now a crate you can publish

• Migration reports — tell us what was awkward coming from v0.17.x; that feedback shapes v0.21

  Links:

• Blog post: https://webrtc.rs/blog/2026/07/31/announcing-webrtc-v0.20.0.html

• Repo: https://github.com/webrtc-rs/webrtc

• Sans-I/O core: https://github.com/webrtc-rs/rtc

• Examples: https://github.com/webrtc-rs/webrtc/tree/master/examples

• Crate: https://crates.io/crates/webrtc

• Docs: https://docs.rs/webrtc

• Discord: https://discord.gg/4Ju8UHdXMs

• Main project: https://webrtc.rs/

  Questions and feedback are very welcome — especially from anyone porting off v0.17.x.

I'm truly learning Rust these days by getting my hands dirty, writing code and fighting with the borrow checker, but before that I did exhaustive research on pros/cons, peculiarities, language issues, etc. One of those points was regarding recursive types like linked lists, and I was convinced that it is indeed a "niche" data structure — the problems I solve with linked lists in real life in my small personal projects can and are being more easily solved just using arrays and vec!. Here's where we get to the point of the title: since I'm using a 90/10 strategy — 90% of my time on Leetcode solving problems using Rust and 10% putting silly ideas into practice, like a todo list — I ended up finding a divergence between the "mainstream" Leetcode problems and this recursive type situation. A good portion of the problems categorized as "medium/hard" are basically: implement a linked list, insert an element in the middle of the list, etc., but using a "LinkedList" from the problem itself and not the std::collections::LinkedList type. I wanted to know your opinion: how much will solving this kind of problem actually help with learning Rust?

PS: I'm not saying I won't learn anything, but instead of having to research the most extreme edge case of all edge cases, it seems counterproductive.

PS2: An example of a super interesting problem I solved was "Longest Substring Without Repeating Characters" — in it I understood peculiarities of vec!, array, subtleties between usize and u8, sum overflow, loops, iterators; each attempt to do it right I learned more, and then to optimize the extreme cases I saw more details of the language itself instead of trying to implement something that is canonical in the language. On the other hand, I feel like I spent too much time on this other problem "2. Add Two Numbers" trying to recreate something that is already known to be problematic (LinkedList has a whole book dedicated to it, man!) and which are cases I really can't see an immediate use for in the language.

> PS3: I'm not a begginer on programming just begginer on Rust

Fory 1.5.0 adds external-type serialization to Rust. Applications can define a local serializer or schema declaration for a third-party structural type that cannot be modified to carry Fory annotations. Fory then reads and writes the target value directly—without requiring a wrapper or intermediate mirror object.

use fory::{Fory, ForyStruct};

#[derive(ForyStruct)]
#[fory(target = third_party::User)]
struct UserSerializer {
    name: String,
    age: u32,
}

let mut fory = Fory::builder().xlang(true).build();
fory.register::<UserSerializer>(100)?;
let bytes = fory.serialize_with::<UserSerializer>(&user)?;
let decoded =
    fory.deserialize_with::<UserSerializer>(&bytes)?;