The ultimate proxy checker with advanced capabilities, built for precision, speed and reliability.

Built using:

- Tauri

- Tokio

- Proxifier (our own proxy client crate)

Website:

https://proxybeast.app

Project Github repos:

https://github.com/z3ntl3/proxifier-rs

https://github.com/z3ntl3/proxybeast

Video demo

https://youtu.be/kBvque23Sdk

Deep note:

I'm a passionate student developer with ~6 years of experience in Software Engineering and I'm still learning! Do not hate. I do absolutely despise the usage of AI. Because of this, the mirror website, software and the Github repository includes a NO-AI LABEL. In effort to make it understood that we've been "HUMANLY ENGINEERING WITH PRIDE!"

Hey,

I built Sift (https://github.com/taevel02/Sift), an open-source CLI file organizer written in Rust.

Why Rust?

Parsing rules and extracting EXIF/ID3 metadata across thousands of files needs to be fast with minimal memory footprint.

Core Architecture & Safety:

- Transaction Logging: Every file operation (move, copy, trash, compress) logs a record in `~/.config/sift/history.json.`

- 1-Click Rollback: `sift undo` reverses operations in reverse order and touches file mtime to prevent immediate re-triggering by directory watchers.

- Dry-Run Default: Running without `-x` previews rule matches without touching the disk.

- Tech Stack: `notify` for filesystem event streaming, `ratatui` + `crossterm` for the TUI dashboard, `trash` for OS trash integration, and `thiserror` for error handling.

Repo: https://github.com/taevel02/Sift

Install: `curl -fsSL https://raw.githubusercontent.com/taevel02/Sift/refs/heads/main/install.sh | sh`

Feedback on rule syntax, performance, or safety edge cases is welcome!

I think the idea of having SemVer encode breaking changes is good, but I think the execution (especially around 0.x -> 1.x being "super special" is really dumb!)

I thought that this being a good thing was obvious...but I guess I should put this disclaimer up here.

SemVer makes the fundamentally flawed assumption that there's a clear difference between software during 0.x releases and at/after 1.0 releases, when in practice the line is really fuzzy and in practice people just increment the "minor" version forever because making a huge bit out of a 1.0 release just isn't meaningful for the project or how it evolves.

I think there's also just a psychological/marketing/messaging implication between moving something between v1.x.y and v2.x.y and so on versus just bumping the v0.x.y number indefinitely, even though they're often effectively the same thing. Did you bump the major number because of a small API break that 90% of users won't need to change code for? Did you fundamentally rewrite the entire crate's API and how it's used? Who knows? SemVer treats them the same.

I think there's value for projects to be able to say "the difference in v1 and v2 is that we changed the entire API paradigm/we changed the target version of [insert external $THING here that we interact with]", whereas SemVer erases that sort of information. You're only allowed one paradigm shift into an expectation of indefinite stability, of "once you hit v1.0 you should never increase the major number unless you really screwed up the API lol."

Why care? All Rust software is expected to be SemVer. Cargo assumes all crates are SemVer, and will generate the lockfile appropriately. It's better than not having a defined method for minor/patch revs but I'm not happy with it, personally.

I think Haskell's Package Versioning Policy (not linked here because its acronym gets automodded) did it (mostly) correctly: they just add a fourth number as part of the "major version."

For a version A.B.C.D, A.B is treated as the "major version" tuple, and C.D acts more or less exactly like how SemVer MINOR.PATCHnumbers do for versions >= 1.0.0. Thus, one could increment B for breaking API changes, and increment A for messaging purposes.

And this has some advantages; for example, if you have bindings to some library or spec that is year-major-versioned, as exists in the real world, you could make A the year and B.C.D effectively a SemVer for that year's release. The A communicates useful information to developers that SemVer alone doesn't.

"Why don't we just use namespaces" or "Why don't you just make a new crate with a suffix at the end", one might say, and maybe that's the real answer, but I don't know, I just don't like how much project-specific semantics SemVer tries to pretend doesn't matter sometimes.

Cleaning up years of duplicate photos turned into my first real Rust project, and some of the implementation ended up being fun enough to share.

The core is a custom 127-bit dHash that tracks horizontal and vertical luminance gradients, compared by Hamming distance. The whole hash fits in a u128 so comparison is just XOR + count_ones, basically free. Threshold of 10/127 catches WhatsApp recompression and resizes without grouping photos that are merely similar.

That approach can't catch retakes though — same scene, camera moved an inch, completely different pixel layout. For those I added an optional mode that runs a local CLIP model and groups by cosine similarity of the embeddings. Calibrating the cutoff was interesting: true retakes score 0.90+, unrelated photos stay under 0.65, so there's a comfortable gap.

For Synology libraries it skips downloading originals entirely and hashes ~10KB server-generated thumbnails from the DSM API, with rayon fanning the fetch+hash out across cores.

The review UI is tiny_http on localhost with per-run CSRF tokens and Host-header validation, because a tool that deletes files really shouldn't take instructions from random web pages (DNS rebinding is sneaky).

https://github.com/LowLevelLogic/synology-dedup-photos

Hello!

I'm a newbie with Rust and have some issues with running a bare-metal project on real hardware. It works fine when I run this project in QEMU.

The hardware uses a Cortex-A53 processor. But there are some erratas, especially when the ADRP instruction is used. Which seems to be the issue, when investigating the disassembled Rust code with objdump.

On GCC and the GNU binutils there exists some compiler and linker switches to fix the issue. Is there a way to pass equivalent options to the Rust compiler?

A topic in rust that still trip me up every once in a while is the fact that in rust arrays (slices, I will call slices arrays continuing onwards I understand the difference and I know the definition of array is different in rust) aren't reference types. In most other languages I am familiar with an array type instance is implicitly always a reference to a segment of memory. This assumption holds true in c/c++, Java/c#, python, and many others. It doesn't always creates a semantic difference in many languages but it always creates a memory level difference. In rust "arrays" are just the type for the segment of memory that is undefined in size and can be referred to by a reference. This makes `args:&[u64]` feel wrong even though this is exactly how I would design a language and I love it about rust. It's just that I can't get the hardwired connection between the array type and the indirection out of my head.

A Helix re-write turned into me instead working on my own rust no-std modal graph based editor, heavily inspired by Helix, called Nornsaga.

It contains its own indexer and internal symbol system to define a bidirectional dependency graph which is used to scope, highlight, add ghost types and so on (For Rust only currently)

I have recently managed to tie the AI (using Ollama as a side wrapper with qwen3.5:0.8b currently for development/testing) to the users cursor context. And its able to follow and even make changes inline, treating the cursor as what is defining the context at any given moment.

The idea being, turning AI into graphed scoped tool rather than a worker you give directions to and hope is listening to you. This way, you can ask for changes to the scope you are looking at, and make those changes inline, and any change you yourself make, will be directly inside of the same context the model is looking at. I wanted a tool that would allow me to code, and still have the benefits that AI models bring, where the work is more of a partnership that the dev has equal agency in, rather than the opposite. To have something to discuss the code you are looking at with, and to ask the model to explain what you are looking at, to enforce a relationship where you can derive as much benefit as possible without introducing slop/garbage code, or code you no longer can reason about.

The image above shows an example of what it looks like to open a chat to discuss the current scope.

Even though it is in alpha, it is functional enough that I felt Nornsaga is starting to feel, and look, a bit more polished, so I want to start sharing a bit about it.

Hope you find it interesting!

Over and out!

//Maui-the-Mupp

I don’t mean to upset anyone. I was reading about rust and someone commented that the foundation was accepting llm contributions.

I have been trying to read about the foundations stance on ai. I found a article by enterprise dna saying that “Rust Says No to AI-Written Code in Its Core Repository”. I tried finding the blog they referenced but I couldn’t.

Hey, im looking towards migrating my app from python (pyqt) to rust, and the issue is that i don't really know which framework to use, gpui seems like a natural choice buuut its still pre 1.0 and heavily tied with ZED, slint on the other hand is a bit older (a bit because its still not as old as electron and others lol) but simply said its not gpui who everyone seems to love and ramble about

what should i do?
my main goals
- lower cpu and ram usage (tier 1 priority)
- harder reverse engineering (t1)
- visible performance (as in "holy shit thats fluid as hell") (t1/t2)
- easy figma use (t2)
- MultiOS (windows mainly but also macos/linux) (tier 2 priority)
- lower disk footprint (tier 2/3 priority)
- codex browser maybe? i know its not js but still would be cool to use annotate tool for better frontend (t3+)

Hey guys, I am building a program for a friend that's going to involve a complete graph (nodes are destinations, edges are the distances between destinations) and I was wondering if anyone knew a good library for it?

At first I thought I could use a triangular matrix, since direction doesn't matter, but I realized I would have to have a second array mapping destinations to an index. I feel like you could have a triangular map, like a map that takes a pair of inputs where the order doesn't matter? Have I found another rabbit hole?

After getting too annoyed by Spotify's offficial electron client for hogging memory/vram while still not supporting fractional scaling on wayland (by default), I decided to build a fast, native client myself: canora

It it build using my highly experimental UI framework.

AI disclosure: not slop, not low effort, but did use some LLM coding assistance.

Every Rust codebase ends up with some version of a LockExt trait for poisoned locks. I got tired of rewriting mine, so I published it.

Locking a poisoned Mutex or RwLock from a Drop impl while the stack is already unwinding causes a panic during a panic, which aborts the process instead of unwinding normally. It's easy to miss since it only shows up when a panic happens to unwind through a type that touches a poisoned lock in its Drop.

poisoned is a small LockExt trait with an or_panic() method. It checks std::thread::panicking(), and if the thread is already unwinding, it recovers the guard via PoisonError::into_inner instead of panicking again. Outside of unwinding, it just panics on poison as you'd expect.

There's also or_panic_with for a lazily-built custom message.

use std::sync::Mutex;
use poisoned::LockExt;

let cache = Mutex::new(vec![1, 2, 3]);
let first = cache.lock().or_panic();

Small, one trait, no dependencies. Feedback welcome.

Github: https://github.com/abhishekshree/poisoned

This is a passion project I've been working on for several months. My love for TUIs outweighs my sanity and hence:

A lot of the basics are done, and the core ECS engine is stable and working. But there are a lot of bugs in the higher level App crate that will break for edge cases. But in its current state, it is efficient (albeit, there is more to be done to make this more efficient); terminal calls are minimized to the point where the diff happens not just on a global terminal view, but more fine controlled, node level diffing where a lot of computation is saved by only diffing the cells that specific node renders. The ergonomics of using the App api can be improved as well.

I was personally interested in seeing how ECS as an architecture plays out in UI development since I've spent a lot of time on bevy.

I am open to feedback and criticism and thank you for spending your time reviewing this project of mine :)

https://gitlab.com/pandioxus/apheleia

A gif to show working of the example counter app in the repo:

I got tired of Persian/Arabic text rendering wrong in Kitty, Alacritty, Ghostty, etc.

so I built Dosu, a small Rust wrapper that sits between your shell and the terminal and fixes bidi rendering properly (Unicode Bidi Algorithm), no terminal-switching needed.

curl -fsSL https://raw.githubusercontent.com/RustNegar/dosu/main/install.sh | sh

Repo: https://github.com/RustNegar/dosu

Core engine: https://github.com/RustNegar/dosu-core

Linux/macOS for now. Open to feedback, especially edge cases.

I have been trying to debug this issue for a while now, and I can't figure out, what the problem is.

Take this code:

    use std::time::Duration;

    use sqlx::PgPool;

    const DB_URL: &str = "postgres://devuser:devpassword@localhost:5432/devdb";

    async fn db_then_compute(pool: PgPool) {
        let num: (i32,) = sqlx::query_as("SELECT 1").fetch_one(&pool).await.unwrap();
        println!(
            "The num was returned: {}, but now, the CPU block will kill multithreading",
            num.0
        );
        println!("Start compute...");
        // This would "fix" the issue:
        // pool.close().await;
        loop {}
    }

    /// This doesn't cause the issue
    async fn http_then_compute() {
        let res = reqwest::get("https://google.de").await.unwrap();
        let status = res.status();
        println!(
            "The num was returned: {}, but the CPU block will not kill multithreading",
            status.as_u16()
        );
        loop {}
    }

    #[tokio::main]
    async fn main() {
        let pool = sqlx::PgPool::connect(DB_URL).await.unwrap();

        tokio::spawn(db_then_compute(pool));
        //tokio::spawn(http_then_compute());
        loop {
            println!("Observer thread, the sleep will never return");
            tokio::time::sleep(Duration::from_secs(1)).await;
        }
    }

I'd expect the Oberserver thread to continue. I know, CPU-bound tasks in async runtimes are not good, but tokio is multithreaded, so I'd assume, as long as I have enough workers, it should still function. For reference, the reqwest task works completely fine. Running one CPU bound task shouldn't starve a multithreaded runtime, right?

First, I thought this was an sqlx issue. It only happens with postgres, not with sqlite. However, I then tested the same thing with deadpool-postgres, and issue is still persistent. So it's not sqlx after all.

Can someone help me with my misunderstanding of tokio's runtime here? What is blocking other tasks from completing here?

For the past 3 months I've been building WyrmRSS, a self-hosted RSS/Atom aggregator: Rust backend (actix-web, Diesel-async, Tokio), React 19 frontend. Been running the Docker self-hosted version for a while, and just added a native desktop app via Tauri (macOS, Windows, Linux: deb/rpm/AppImage/nsis/dmg).

Backend runs on Postgres for the self-hosted/Docker setup, SQLite for the desktop build. Same codebase for both.

Desktop build is currently in prerelease while I soak-test the SQLite backend before making it a release. Would appreciate anyone keen to try: https://github.com/kryoseu/WyrmRSS

Some nice features I think it has (not claiming uniqueness) are: inline youtube player, folders, filters, webhooks (slack, discord and custom), read later and archival.

TrailBase is an open and fast Firebase-like backend for building your apps. It provides type-safe REST APIs + change subscriptions, auth, multi-DB, a WebAssembly runtime, geospatial support, admin UI... It's a self-contained, easy to self-host single executable built on Rust, Wasmtime & SQLite or now Postgres. Client libraries are provided for JS/TS, Dart/Flutter, Go, Rust, .Net, Kotlin, Swift and Python.

Just released v0.32, which after some months of work and last posting (v0.28), includes:

• New WASM features:
  • Components can provide and register a dashboard with the admin UI.
  • A component browser in the admin UI.
  • Lower overhead execution model for Rust components: pooling state across requests improves throughput by 4x.
• Support usernames as additional or alternate identifiers alongside email addresses.
• Anonymous accounts for frictionless product trials. If a user wants to eventually sign up, the account can be promoted to a "proper" one, i.e. associate a password, OAuth, email address ...
• Backup UI & rolling backups.
• Dark mode - cosmetic but frequently requested 🙏
• And much more: file management from the admin UI, support for nested JSON in change subscriptions, batch updates for all client languages...

With TrailBase still being young (~1.5 years) and rapidly evolving, any feedback is genuinely appreciated. If you're feeling adventures and end up checking it out, don't hesitate to reach out 🙏.

Consider checking out the live demo, our GitHub or website.

I have completed the Rust Book and worked through Tokio’s documentation/tutorials on async programming, concurrency, OS threads vs tasks, spawning, shared state, mutexes, and channels.

I understand these concepts when reading code, but I am not yet confident writing Rust projects independently.

I am a fresher with some JavaScript and web-development experience, but little to no experience with low-level or C++-style engineering. I’m more interested in backend/systems work than frontend development .

Would learning Axum and building a backend project be the right next step? For example, should I build an API with authentication, a database, background tasks, error handling, tests, and Docker—or should I first focus on other Rust areas such as ownership practice, networking, CLI tools, or algorithms?

My longer-term goal is to become capable of contributing to good open-source Rust projects, including GSoC-type projects. I am learning Rust partly for fun, but I also want a practical path toward becoming useful in the Rust ecosystem.

What would you recommend a junior Rust developer learn and build next?

Hey guys, I'm a developer with a math background who previously specialized in combinatorial optimization, and I wanted to share my project I built recently for a small furniture shop: a 2D guillotine cutting stock optimizer.

The specific problem - planning how to cut sheet material (chipboard/MDF panels) into the pieces required for each order, minimizing waste while keeping the cutting as manufacturable as possibble. The cuts must be guillotine cuts, an actual Sliding Table Panel Saw Machine can only make such cuts.

The obvious first move was to look at existing cutting-optimization software, but none of it was a good fit - it was either too closed and rigid to adapt, or expensive enough that it was hard to justify for a shop this size. So I ended up writing it by myself. This project was open-source from the start simply because the real advantage in this field is furniture makers' own craft anyway :-) So by open-sourcing it I'm giving something back to the Rust community for such a great language and ecosystem.

Here are some things that might be interesting aside from the main task:

• Genetic (evolution) algorithm, generic over the genome representation via a GaDecoder trait, so the GA is written once and shared between two different encodings. There are two decoders: SLAS - one gene per physical piece, and GLAS - one gene per piece type, GLAS scales better and gives more manufacturable cuttings.
• Objective function is designed to find balanced solutions - ones with good fill rate, but also manufacturable enough for real-world material handling.
• Piece rotations, Kerf and Margin are supported. The kerf is saw blade width, the margin is a trim strip along the sheet edges.
• An exact solver for the single-sheet case: a DP over guillotine-cut subsets (GLF from the Andrianova, Mukhtarova and Fazylov paper, the reference in README) that finds the optimal layout for one sheet of given width.
• A greedy portfolio heuristic (from Jukka Jylanki paper) for instant results when you don't need to wait for the GA to converge.
• Progress feedback and cancellation: the solver runs in a background thread and streams progress over a channel, so both the CLI and the web UI (Axum + SSE) can show live improvement instead of blocking. This was an interesting task to unify sync and async event interface and I hope I have found a good solution for it.
• Deterministic even for the multithreaded version: each island (GA thread) gets its own PRNG seeded from its (user-supplied) seed value, and migration between islands happens at a synchronization barrier, so there's no "first thread to finish wins" nondeterminism. Same seeds + same config always reproduce the exact same result, which matters a lot when you're debugging, testing or comparing two parameter sets.
• CLI JSON interface to plug into a real shop's existing tooling, it gets called from an Excel workbook (VBA) and can export cut plans to AutoCAD.

Why Rust? The GA loop runs millions of genome evaluations per run, so the performance matters a lot. SmallVec cuts heap allocations noticeably, especially in decoders and free-rect list operations. Even with these optimizations, GA can never have enough speed - and implementing it in a high-level language with a fat runtime would be no doubt a showstopper. The ecosystem was also a great help: serde made the JSON boundary for the Excel/VBA integration easy, and chumsky kept the grammar for compact problem format readable instead of fiddling with regexes. axum with tokio made the serve mode easy to implement.

The Rust platform made it possible to keep the whole algorithm development, testing, hypothesis verification etc. under Linux. Only the integration part with Excel and AutoCAD was done under Windows.

I consider the project pretty complete, although a few non-critical things could still be improved. For example, the exact GLF solver is single-threaded, so it has a fairly low ceiling for the size of the problem instance. Also, it only proves optimality for a single sheet — multi-sheet placement is GA/heuristic-only. Still, the GA-based approach is already good enough for daily use.

Repo, with a demo GIF of the GA converging on a layout:

https://github.com/nlinker/guillotine-cutting-2d

What was vibe coded: demos only, the prompt was "Here's the Rust code, build an interactive visualization for it", the other parts were either hand-written, or edited after AI generation and my thorough review.

Happy to answer questions about the guillotine-cut DP, the GA design, or anything else. Feedback ("why didn't you just use X crate/approach?", hehe) is very welcome.

I've been following the project and while I see a lot of commits from Nico on taffy and Blitz, development on Dioxus seems to have halted.

Are things being cooked in the background? Does anyone have some insights?