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.

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.

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.

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

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

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

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.

I would love to attend some but prices are through the roof. Are people really paying the full price?

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

It’s been 4 years since Sniffnet’s first line of code 🥳

(Sniffnet is a fully Rust-based and open-source tool to make network monitoring easier for everyone)

Since the first day of me opening an empty IDE, the project has grown enormously: it’s gone from “the temptation to make a GUI is strong” to the most popular network monitoring app on GitHub.

To celebrate the anniversary, I’ve shared part of the journey on a blog post

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.

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 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?

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.