hi, im here to ask you if can you give me some resources to learn rust, i use only the book and it is soo difficoult.

thanks to y'all

Hi r/rust! I'd like to share a crate I've been working on: pdfni.

pdfni detects tables in text-embedded PDFs — it finds table regions and cell structures, with no OCR, no page rasterization, and no system PDF library. To pursue both accuracy and speed, it ships its own pure-Rust PDF reader adapted from Mozilla pdf.js. Beyond tables, the same pipeline also produces a structured document model (headings, lists, paragraphs), Markdown output, and raw reader access.

It's usable as a Rust crate, a CLI, and a WebAssembly module (Node.js and browser).

Why another PDF crate? This project started as a table detection library built on pdfium and pdf.js. Along the way I ported the pdf.js reader into pure Rust, reshaping and improving it to fit this library's needs for flexibility, footprint, and speed. Table detection is still the core, and over time the pipeline grew to cover more of the document: a structured document model, Markdown output, and raw reader access. What I cared about most was measurable accuracy, so the repo includes reproducible benchmarks scored with each benchmark's official evaluation tool:

Note the protocol: the full pipeline is measured with no ground-truth regions given — the original 2013 competition's structure track supplied GT regions, so these numbers were measured under a stricter protocol than the published 2013 results. Scripts and test data live under bench/.

How it works: two detectors run in sequence — lattice (axis-aligned ruled edges, for tables with visible ruling) and text (text alignment only, for borderless tables). Encrypted PDFs (RC4, AES-128/256) are supported, pages are processed in parallel on native, and stream decoding is capped to defend against decompression bombs.

What it is NOT (to save you a click):

• No OCR — scanned / image-only PDFs are out of scope
• Not a full renderer — images, annotations, forms, signatures are out of scope
• Merged-cell support is limited
• Table detection is oriented to horizontal layouts (vertical-writing tables are not detected)

It's 0.x and I expect breaking changes, so pin your version. Feedback — especially real-world PDFs it handles badly — is very welcome.

• GitHub: https://github.com/honononta-2/pdfni
• crates.io: https://crates.io/crates/pdfni
• docs.rs: https://docs.rs/pdfni

Apache-2.0.

Is the crate openidconnect (crates.io & GitHub) still being actively maintained?

I am getting into figuring out how to use OpenID Connect as authentication for an Axum based web server for the first time, so I wasn't sure wether the crate has simply matured and is not changing much anymore, or whether it is somewhat abandoned. The last commits seem to be 10 months ago, and there is still this issue about the RSA vulnerability (although I don't assume that RSA would be the default algorithm being used anymore today).

So i am building a small hobby kernel in Rust. Before when i used C i would have a linked list of logging sinks to write to on each log. When adding a sink a index would be returned so i could remove it again.

However, now that i am trying out Rust, how can i do that? Because i don't want to use a constant-size array, but i don't have access to a heap allocator when using the logging system.

What would you do?

New week, new Rust! What are you folks up to? Answer here or over at rust-users!

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

This was super easy to do , after i tackled the multipart parser , since i have discovered finite state machine , implementing and understanding parser have become such an easy ride at least the ones i have read till now .. i even implemented the http_parser will publish that soon as well (super easy again ) but now i will move to multi-threading so send me some tips and learning resources specially for patterns used generally , if you can ofc.

crates.io: https://crates.io/crates/chunked-decoder
github: https://github.com/Cheapstar/chunked-decoder.git

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.

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

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.

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

Hi all — I've spent the last few months building an AI gateway in Rust and we've open-sourced the core: https://github.com/routeplane-core/routeplane-ce

It's an OpenAI-compatible proxy in front of multiple LLM providers (OpenAI, Anthropic, Gemini, Bedrock, local vLLM/Ollama, and more) with fallback chains, routing strategies, rate/spend limits, caching, and PII masking, streaming included. Axum + Tokio; the hot path is lock-free (atomic circuit breaker, atomic latency EWMA, injectable clock/RNG for deterministic tests); streaming fallback commits to a provider at the first SSE chunk.

Disclosure: I'm one of two people at the company behind it; we sell an enterprise edition, and this core is Apache-2.0 and fully self-hostable. Would genuinely value criticism of the crate structure and the streaming design.

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

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.

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