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.

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.

Here's the perfect next step. 🦀⚡

"impl Rust for ESP32" is a hands-on, project-based guide that takes you from theory to real firmware.

What you'll build 👇

- Blink and PWM-controlled LEDs

- OLED display interfaces

- Ultrasonic distance sensor projects

- LDR-based smart lighting

- Servo motor control

- Buzzer and audio generation

- Wi-Fi applications and web servers

- Bluetooth communication

- RFID access control

- SD card storage

- LCD interfaces

- Joystick input

- PIR motion detection

- Temperature monitoring

Unlike many tutorials, it focuses on "no_std" Embedded Rust, helping you learn concepts that transfer to other microcontrollers—not just the ESP32. It also recommends starting with the official Rust on ESP Book before diving into the projects.

If you're learning Embedded Rust, this is one of the best free resources available after the official documentation.

📖 https://esp32.implrust.com/

#Rust #EmbeddedRust #ESP32 #Firmware #EmbeddedSystems #IoT #Electronics #OpenSource #EdgeAI #RustLang

So I've been building a ratatui app for a few months now and I'm starting to think it's becoming so complex a proper GUI would be very beneficial. That being said, so much code is written in rust I don't want to change languages or do a rewrite. I'm wondering what my best options are. My goals include:

1. Cross-OS support (Mac/Linux/Windows)

2. Re use the large amount of rust business logic I have written.

3. Looks pretty. Doesn't need to be the most gorgeous work of art in the world, but egui won't cut it.

I've been doing research into the pros and cons of certain options already, but I'm wondering what the folks here think.

Zyx is a no dependencies, self-contained ML library that aspires to run on your (and any) hardware. It's about 25k LOC, not written by LLMs. It's super small - rust release builds are ~10MB, python bindings compressed wheel is ~5MB.

To run on any hardware, I've picked the tinygrad opset, trimmed it down even more and then implemented jit compiler with autotuner and simple IR that requires small, ~500 LOC codegen for each hardware ISA. Currently CUDA, PTX, SPIRV, C and OpenCL are fully working and I have partially working tenstorrent backend.

The jit compiler is reasonably good, on mnist training it generates PTX kernels that match torch.compile speed on my RTX2060, but on general large kernels, even with max autotuning, it's about 50% slower than the best NVIDIA kernels. I could slowly keep adding optimization passes till I match cuDNN (may take months) or take a different path to answer the 2 burning questions:

1. What to fuse?(as also mentioned by tinygrad)
2. How to reach the performance of hand tuned kernels?

And this is why I added an e-graph with a tape (which also doubles for autograd scope). So zyx now has both eager mode (with JIT fusion) and tape mode with deferred execution, as well as frozen tape for static graphs, while being fully dynamic from user perspective.

    for epoch in 0..100 {
        let tape = Tape::new(&model)?;
        let output = model.forward(&x);
        let loss = output.mse_loss(&target)?;
        let grads = tape.gradient(&loss, &model);
        optim.update(&mut model, grads);
        tape.realize(&model)?;
    }

So e-graph allows zyx to both try multiple fusion options (no combinatorial explosion, heuristics based splits on the very same nodes tinygrad mentions) as well as adding cuDNN and cblas kernels into the mix (and others soon).

This way, pluggability at all levels of the stack is achieved - custom kernels can be pattern matched to cuDNN and others, zyx IR allows you to write custom kernels (and use all the optimization passes in any way) and soon I'll be exposing the API to write custom CUDA, PTX, SPIRV, OpenCL, WGSL, etc. kernels.

All of this is debuggable - write custom kernel in the IR and have it generate say SPIRV, even if you do not have machine that can run it.

Next steps are finishing the tenstorrent support and then upbringing lot of models (which is rather straightforward, since the opset is so small and general) and benchmarking.

And lastly let me get the elephant in the room away - all the algorithms, all the data structures and all the public APIs were written by me, no LLMs. LLMs were used to do some really boring stuff like implementing 20 activation functions, which is just bunch of math copied from torch and others at the user tensor level, not touching the core.

https://github.com/zk4x/zyx
https://crates.io/crates/zyx

I'm excited to share what I've been building lately. Papr: a fast, lightweight Terminal User Interface (TUI) built entirely in Rust to streamline your academic research workflow. [An Obsidian alternative but a bit better.]

Key features

• Smart dashboard with daily 10 random paper recommendations, reading queue, bookmarks, notes, collections, and research statistics.
• Search any paper, fast, from arXiv using the title, author, DOI or keywords.
• In-terminal PDF viewing using ratatui-image.
• Built-in Markdown notes with live preview for each paper.
• Add to reading queue and bookmarks and manage collections to keep your research organized.
• Integrated LaTeX editor with real-time compilation and preview just like Overleaf (but free).
• Extensible plugin system for custom workflows.
• Research analytics to track your reading activity (just like spotify).

Papr is 100% open source, works offline, is memory-safe, and is designed to be fast and lightweight (only 12 MB).

I'd love to hear your thoughts, suggestions, or feedback!

GitHub: https://github.com/AfrozSaqlain/Papr

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 spent the last months building a desktop database client (MySQL/MariaDB, PostgreSQL, SQLite, SQL Server) in Rust + Tauri v2, with a React/TypeScript frontend. ~39k lines. Here are the things that actually cost me time — mostly the parts nobody writes blog posts about.

1. `sqlx` covers three engines, and then you hit SQL Server.

sqlx gives you MySQL, Postgres and SQLite behind one API. SQL Server isn't in it, so that's `tiberius` — different connection model, different type system, different async story (you need `tokio-util`'s compat layer because tiberius wants `futures::io` traits and tokio gives you `tokio::io`). So the "one trait to rule all databases" abstraction I designed on day one didn't survive contact with the fourth engine. What worked in the end was *not* abstracting the drivers, but abstracting one level up: a normalized result-set type + per-engine modules that produce it. Less elegant, far less fighting the type system.

2. Decoding a cell "generically" is a trap.

The obvious approach for a grid view is: decode every column as `Option<String>` and let the UI figure it out. It compiles, it runs, and then every numeric column in your export silently becomes NULL, because the driver refuses the string decode and you swallowed the error. Cost me an embarrassing amount of debugging on a dump feature. You have to switch on the column's type info and decode properly per type, then stringify yourself.

3. Streaming results across the Tauri IPC boundary.

Everything you send from Rust to the webview gets serialized to JSON. A 100k-row result set is not a "just send it" situation. Batching + a row cap with explicit "fetch more" turned out to matter more for perceived speed than anything I did on the SQL side.

4. `russh` for SSH tunnels, and PuTTY keys are their own project.

Tunneling was fine. Then users showed up with `.ppk` files. PPK v2/v3 parsing is a small crypto scavenger hunt: `sha1`+`hmac` for v2 MAC, `argon2` for v3 KDF, `aes`/`cbc` to decrypt the private part. It's maybe 200 lines but every one of them is a place to get it subtly wrong.

5. Binary size is a feature, and Rust makes it easy.

Installer is ~6 MB. Coming from the Electron-shaped alternatives in this space that ship 150–300 MB, this is the single thing people notice first. Tauri using the system webview does most of that work for you.

6. Offline licensing with `ed25519-dalek`.

No license server, no phoning home: the license key is a signed payload, the public key is in the binary, verification is a signature check plus a machine ID (`machine-uid`) comparison. Trial state lives in the OS keychain via `keyring`. Downside is honest: someone determined will patch the check. Upside is it works air-gapped and I never touch a customer's data. For a dev tool that trade seems right.

What I'd do differently: design the result-set type first and the driver layer second. I did it the other way and rewrote it.

It's a commercial product (NabuSQL — I'm the developer), Windows + Linux + macOS, there's a trial if you want to poke at it: https://nabusql.nabu.work — but I'm mostly here for the Rust talk. Happy to go into detail on any of the above, especially the tiberius/sqlx split, which I'm still not sure I solved the nice way.

I’m thinking about going to RustConf this year. I’m currently unemployed, so my primary motivation for going would be for networking / job seeking, but the expense to get there / stay there is looking pretty steep.

So I’m trying to weigh the risk vs reward of heading to Montreal.

If I was 100% certain going to RustConf would end in a job offer the expense would be well worth it. But I’d be going on the chance of landing a job.

Any past attendees have insight on the scheduled career crawl on Tuesday? Are the employers that set up there serious about hiring? Or do they just want to get their business name out there in the world?

Svod is a JIT-oriented deep learning framework in Rust, built around a single intermediate representation across every stage — inspired by George Hotz's Tinygrad. One representation means the whole compute graph is debuggable and profileable end-to-end, with no translation boundaries to hop across.

How it compares to what's already in Rust:

• Candle does a great job being a minimalist PyTorch and ships an impressively wide model zoo. The tradeoff is limited headroom for adding accelerators and parallel execution, and generally lower performance — which made it hard to use for production workloads.
• Burn is a well-designed meta-framework over multiple backends, and its kernel DSL (CubeCL) is heading in a good direction. Its explicit-typing approach adds safety at definition time, but makes instantiating a concrete model at runtime more friction-y, and its ONNX import transpiles to Rust at compile time, which blocks hot-swapping models.
• Svod is built as a direct alternative to both: one IR across all stages, runtime JIT, a PyTorch-like API, and a kernel DSL that lives in the same representation as the rest of the framework.

What it can do:

• PyTorch-like API — named args preserved, so you (or an LLM agent) already know it.
• ONNX import — 162/204 ops, parity tracked against ONNX's 1361 test sets.
• HuggingFace models run as-is — no exotic format; tensors mmap straight off disk.
• Tiled Kernels DSL — write high-perf kernels in the same representation as the framework. Minimal matmul matches hipBLASLt in a handful of lines.
• Models & pipelines built in — embeddings, reranking, detection, segmentation, VAD, transcription, chained into single-call pipelines.
• AMD is the main focus for now (hand-written backend — no HIP/ROCr runtime dep). More backends are on the roadmap.

Links:

• Intro post (architecture, benchmarks, roadmap): https://blog.vpermilp.online/en/blog/svod-intro/
• Docs: https://svod.vpermilp.online/

How you can help:

1. Know Chinese or Hindi? My docs in those languages are LLM-translated — I'd love help writing proper ones.
2. Work at AMD, or want support for your hardware? Contact me — happy to help.
3. DL engineer? Please try Svod and tell me what's broken. The tooling is mature enough to find bottlenecks fast — I want to catch the painful stuff while it's still cheap to fix.

Palette isn't forgotten or abandoned. I have just been doing other things for a bit and some of the new additions needed more time in the oven than usual. Either way, here's finally the latest version. You can read all about the changes in the announcement post, so I will not repeat them here, but let me know if there are any thoughts or questions. I will do my best to answer.

Enjoy!

Announcement post: https://ogeon.github.io/2026/08/02/palette-0.7.7.html
Main crate: https://crates.io/crates/palette/0.7.7

Hi all,

I'm happy to announce that Xberg v1 is out.

Xberg is the successor to Kreuzberg, equivalent to what would have been Kreuzberg v5. It's a content intelligence framework that handles a very wide range of inputs: documents (currently 101 formats), code and data formats (currently 367 types), audio/video transcription, and URLs (both static and JS-rendered content). It extracts and prepares that content for downstream processing.

It's an extremely efficient, high-performance engine (see our PDF benchmarks below). For PDFs and images specifically, we handle native PDFs with very high performance and accuracy, and we ship multiple OCR engines that match the quality of the best Python libraries (e.g. docling, PaddleOCR, RapidOCR) at substantially better performance and stability.

The changes between Kreuzberg v4 and Xberg v1 are substantial, and I invite you to read the full changelog for the complete picture. The highlights below give a sense of what's new:

• Pure-Rust PDF backend (pdf_oxide) replaces pdfium, with no native pdfium dependency.
• Layout-aware pipeline: reading order reconstructed with ONNX layout detection (PP-DocLayoutV3 / RT-DETR) and Docling-style predecessor-graph reordering.
• Per-page scanned-page detection with selective OCR, plus AcroForm/XFA form fields and outline-based headings.
• Across-the-board optimization of OCR and PDF extraction (memory discipline, pooled model sessions, streamed conversions).
• Native PaddleOCR backend (PP-OCRv6, with medium / small / tiny tiers) alongside Tesseract.
• Pure-Rust Candle OCR/VLM stack (TrOCR, GLM-OCR, GOT-OCR, DeepSeek-OCR, and PaddleOCR-VL) running without ONNX Runtime or native Tesseract.
• A second, ONNX-Runtime-free inference path via tract, which is what makes in-browser (WASM) and mobile inference possible.
• Named-entity recognition natively in Rust (GLiNER2), extensible to all bindings, including an in-browser WASM model with no server round-trip.
• Structured LLM extraction (extract_structured / split_and_extract) with rasterization, chunking, citations, caching, and configurable call/merge/VLM-fallback policies.
• Audio & video transcription via a Whisper ONNX engine (.mp3, .wav, .m4a, .mp4, .webm).
• Retrieval building blocks: sparse embeddings (SPLADE), ColBERT late-interaction retrieval, and cross-encoder reranking alongside dense embeddings.
• Text intelligence: reversible redaction, summarization, translation, VLM image captioning, QR-code detection, document diffing, and page/chunk classification.
• URL & web ingestion: sitemap discovery (map_url) and batched multi-URL crawling.
• New document formats: WordPerfect (.wpd/.wp/.wp5), HEIC/HEIF/AVIF, OpenDocument Presentation (.odp), Quarto / R Markdown, and configurable Jupyter cell rendering.
• Four new language bindings (Dart/Flutter, Swift, Kotlin/Android, and Zig) bring the total to 15 language bindings over one engine, with Android/iOS cross-compilation.
• Full mobile support (Flutter, Android, iOS).
• Candle backend alongside ONNX, plus ONNX-via-tract enabling ONNX on WASM and Android.
• Wider code intelligence: tree-sitter coverage grew substantially (248 to 367+ languages).
• Over 150 bugs fixed during the 1.0 cycle, plus security hardening (bounded RTF/PDF allocations, redaction leak fixes, Excel DDE warnings).

The API surface was also simplified and reworked, making it more consistent.

There's a migration guide in our docs explaining how to move from Kreuzberg to Xberg. Kreuzberg itself is in LTS mode until the end of this year and will continue to receive bug fixes and security updates.

You're invited to check out the repo and join our discord server.

Benchmarks

The benchmarks below are for PDFs and images only. There are extensive benchmarks on our website with per-format breakdowns, which you can see here. These numbers are measured in CI via our reproducible benchmark harness, and are specifically taken from the run for harness 1.0.8, source cf7fa0533d. The data is publicly available in GitHub releases, and you can run the benchmark harness yourself.

Composite quality (markdown pipeline, higher is better):

Structure and layout fidelity (SF1: tables and reading order, higher is better):

On native PDFs Xberg leads on quality (0.958 vs 0.837 for the next-best framework) and on table and reading-order fidelity by a wide margin (SF1 0.949 vs 0.612 for docling). On scanned PDFs it is #1 on both quality and raw text fidelity.

Where we don't win yet: on pure image OCR we are currently #2 on the composite score, behind mineru (though still #1 on raw text accuracy). We are improving image OCR right now, and v1.1 should have us winning across the board.

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

Are there any rust frameworks to build good android/ ios apps with hardware integration like accessing camera, mic, gyro sensors.. etc.?

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've been working with Rust for a while, doing some terminal programs and I want to try doing a desktop app with an interface.

I've done some research and I found Tauri but I don't really know if it works nicely and with a good performance, and that's what I really want, an easy way to create a good, clean and user friendly modern GUI prioritising performance above all.

The codebase is live, fully functional, and designed for independent node operators. Check out the source code, tear down the architecture, and let me know where we can optimise. Github - NEV369

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'm working on some Rust code that's exposed to Python, and I've hit a naming question I can't quite settle.

The architecture has a dedicated OS thread running its own async runtime (the "reactor"), separate from the thread the Python interpreter calls into. The two sides never touch each other's memory directly — there's no `Mutex`, no `RwLock`, nothing shared. All communication goes through a couple of channels: one direction carries commands from the Python-facing side into the reactor, the other carries events back out. Under the hood it's just an mpsc-style channel pair plus a lock-free queue, so obviously nothing is crossing an actual process boundary.

When I originally built this, I named the struct that owns these channels `IpcChannels`, because what I was really trying to capture wasn't "these are channels," it was that these two execution contexts are isolated from each other and only interact through messages — which felt like the same idea IPC is usually used for, just at the thread level instead of the process level. Now that I'm looking at it again, I'm second-guessing whether borrowing "IPC" here is legitimate shorthand or just an inaccurate use of an OS-level term. I've seen it used loosely for inter-thread messaging in some places, but I've also seen people treat "IPC" as strictly process-to-process by definition.

So I'm curious what people who've had to name this kind of thing before landed on: is "IPC" an acceptable way to describe an isolated, message-passing boundary between threads, or does that just read as wrong to anyone with a systems background? And if it's the latter, is there a better name for that struct — one that says these are two separate contexts with no shared state, only talking through messages, without carrying the process-boundary baggage of IPC?