I've been building an SSH client in Rust with claude as a student project and just released the first beta.

The core crate does the vault (Argon2id, AES-256-GCM, atomic writes, backups), SSH via russh and SFTP. A separate axum + SQLite server stores only the encrypted vault, using revisions with compare-and-swap. The frontend is React in Tauri 2; tokens and private keys stay in Rust memory and never reach the web view.

Code: https://github.com/niho2/nivterm

Architecture notes: https://github.com/niho2/nivterm/blob/main/docs/architecture.md

I'd especially appreciate a critical look at the vault and sync code.

I built cohors to see every git repo on my machine at once (unpushed, behind, dirty, stashes) and act on them in bulk. It started as a TUI and grew three more front-ends, and the part I'm happiest with is how they share one core.

cohors-core is pure and WASM-safe. It has no std::fs, no std::process, no threads and no Instant, and CI builds it for wasm32-unknown-unknown on every commit. The models, the selector language, the ranking of what needs attention and the view logic all live there. The browser dashboard is Leptos compiled to WASM and uses the same core models, so the terminal and the browser agree on what "at risk" means.

Git reads go through gix, with git2 as a fallback for the things gix doesn't cover yet. Discovery and snapshots run in parallel, and a broken repo shows up as an error row instead of a panic. The MCP server is hand-rolled JSON-RPC over stdio, because it was small enough that a dependency wasn't worth it.

A couple of architecture rules are tests rather than conventions. The front-ends aren't allowed to depend on the git or GitHub adapters directly, and every write action in the registry has to be wired to both the TUI keymap and the MCP catalog, or the build fails. The write side is deliberately boring: pull is fast-forward only and nothing force-pushes.

cargo install cohors

It's MIT. I'd appreciate a look at the crate layout, and at the gix and git2 split in particular.

https://github.com/rushirb2001/cohors

I wanted my clock, weather, music controls, and tasks always visible without running a 300 MB Electron app. So I built Life HUD, a native Windows widget bar that docks to the top or side of your screen and automatically reserves space, just like the taskbar.

Tech highlights:

• Rust + Slint, with direct Win32/WinRT integration

• Single native executable, no Electron or runtime dependencies

• ~0.5% of one CPU core with music playing

• Win32 AppBar API for docking, SMTC for media controls

• SVG bitmap caching to reduce Slint rendering overhead

• Offscreen widget snapshots for isolated UI development

• Modular service/controller/Slint architecture for adding widgets

Includes weather, Spotify/media controls, tasks, notes, Reddit, YouTube, news, sports, stocks, and search.

No accounts, no telemetry. MIT licensed.

GitHub: https://github.com/George-API/LifeHUD

Would appreciate feedback from Rust devs, especially on the Win32 interop, Slint architecture, and anything that could be made cleaner or more efficient.

Hey, im new here and i've been using rust for my projects since July, i've come from python where compiling with cython was a little slow but okay'ish but ever since i've come to rust my build times are at minimum 40-60min and my disk is crying for help. i use a lot of worktrees to work in parallel with claude (yeah ik you hate it but it is what it is) and i run 2 windows machines with ssd's. I've thought about putting my devbox pc on linux so i can run blaze but it would waste even more resources (ram, one machine got 20gb and other got 16gb) because i would still need to run some sort of windows vm as my app is windows based

any ideas?

https://iyiolacak.github.io/ai-ui-rewrite-rust/

Built with Ratatui. Runs WireGuard, OpenVPN and NetBird tunnels side by side, with live telemetry, IP/DNS leak checks and a kill switch. Feedback on the code welcome.

cargo binstall vortix · https://github.com/Harry-kp/vortix

Introducing Space. I’ve been working on it for the past year.

https://www.chord.ink/space

It works with the native Quick Look together, so you can edit, but with a premium feel：

Press Space on a text file in Finder and it opens a Quick Look window with syntax highlighting, pinch to zoom, code folding …you name it. It’s a real editor. 1.0 also ships with three plugins: Markdown, Syntax (by tree-sitter) and Vim.

Why build this? Text files in Quick Look can't be pinch-zoomed, have no color, and can't be edited. To fix a few words, you double-click, wait for another app to launch, and then either forget to quit it or have to press ⌘Q. The text is already in front of you. You should be able to just edit it.

Under the hood, Space runs on my custom fork of GPUI (from Zed). Official GPUI shapes and rasterizes glyphs on the CPU through the system's text APIs. That works fine for an editor you keep open all day, but Quick Look lives or dies by its first frame latency. A dense document on a 5K display takes about 110 ms on an M3 Pro, and every zoom step rasterizes the glyphs again, costing another 110 ms.

So I moved glyph rasterization to the GPU with Eric Lengyel's Slug algorithm, whose patents were dedicated to the public domain a few months ago. That document now draws in 38 ms, zooming is up to 8× faster, and with a bit of extra work, it supports that signature macOS feel: font smoothing and vibrant text.

But fancy tech is just the foundation. It doesn't automatically make an app feel great to use.

To honor the muscle memory Quick Look has ingrained in all of us, Space opens files locked by default. Press Space again to close, or use the Up/Down keys to browse files. Press ⌘L to unlock with the classic macOS unlock chime, and you're ready to go.

Two things I'd especially like to call out:

1. Switch the desktop pinning: Native Quick Look always follows you across desktops, which is annoying if you want to leave it there and work on other apps. In Space, you can turn it off.

2. Window Liftoff: The native panel shares a single desktop session, meaning you can never have multiple panels open. Space lets you liftoff a panel into its own session by double clicking on the filename or ⌘N. For anyone who cross-references files side-by-side, this is necessary.

More plugins (like Helix, Git, PDF, and Document) along with features like history and thumbnail parking are all on the roadmap. But for 1.0, Space has everything it needs. Hope you like it!

I wanted a practical Rust reference that cuts straight to how ownership, error handling, and data modeling actually work in a real codebase—and I wanted to guarantee that none of the code examples ever go stale.

So I built Rust / The Working Field Guide, a 15-chapter interactive primer and bench reference.

How it works under the hood

1. Build-time compiler verification

• Every example on the page is compiled by a custom verification runner (studio-verify) against a pinned rustc 1.100.0 (Edition 2024) toolchain whenever the site builds.

• Out of 15 examples, 12 compile and run, and 3 are intentionally rejected by the compiler to demonstrate specific diagnostics (like E0382 and E0515).

• If a snippet fails to match its declared outcome, the build fails.

2. Interactive Ownership Lab

Instead of just reading about move semantics and borrow checker rules, you can step through 6 experiments in The Ownership Observatory and predict whether a snippet compiles or triggers a borrow error before revealing the compiler's actual diagnostic.

3. Zero-dependency starter project

The guide walks through building Signal Notebook, a small CLI tool that parses and validates scores using only the standard library, progressing from basic types and Result/? propagation to iterator pipelines, concurrency, and daily clippy/rustfmt habits.

What’s covered across the 15 chapters

• Foundations & Rust 1.100.0: Tooling (rustup, cargo, rust-analyzer), Edition 2024 vs. compiler versions, and newly stabilized features like naming the never type (Result<T, !>) and str::trim_prefix.

• Ownership & Lifetimes: Moving vs. borrowing, interior mutability, and why 'static bounds don't rescue dangling references to local allocations.

• Idiomatic Design & Failure: Using enums and newtypes (Score(u8)) to make invalid states unrepresentable, establishing a clear panic/invariant policy, and knowing when not to reach for traits or generics.

It's completely free, static, and designed to be read from top to bottom or used as a quick desk reference. I’d love feedback from both folks learning Rust and experienced Rustaceans on the structure, the interactive experiments, or anything that could be clearer!

I built behave, a small tool that records how a CLI behaves (stdout, stderr, exit code, files it writes) from cases generated out of its --help, and then checks another implementation against that recording. I pointed it at the Rust rewrites with GNU 9.12 as the reference: uutils coreutils, findutils, sed and procps.

So far that turned into 43 upstream bug reports and 50 fix PRs, 34 of them merged. Most of it is the long tail of compatibility rather than crashes: error messages that lost the file name or context, numeric looking file names reformatted by localisation in messages (tail 007 printed as 7), sort --check exiting 0 on read errors, tac rejecting a separator starting with '-', md5sum -c rejecting its own escaped lines, fmt writing lines longer than -w, env -S hints and -C messages, dircolors error locations.

Every fix PR comes with a test, and the uutils maintainers have been quick and precise in review.

The repo also ships hand checked specs for 41 coreutils utilities (about 1,400 cases) recorded from GNU 9.12, so anyone can run them against a uutils build. Against uutils 0.12.0, 1,135 of 1,418 match exactly, and 1,327 if you ignore stderr wording.

If you are porting a CLI to Rust, the loop is: behave probe <tool>, behave run, behave diff --impl ./target/release/<tool>.

Repo: https://github.com/emirmrkaljevic/behave Full list of findings: https://github.com/emirmrkaljevic/behave/blob/main/docs/upstream-findings.md

Happy to hear what other rewrites people would want checked.

Preface

I deliberately submitted this with "discussion" flair rather than "project" flair, because I'm only sharing code to frame my thoughts around project quality and LLMs and provide a concrete example for commenters to reference. I'm not looking for a gold star: the code sucks, it is incomplete, and nowhere near the quality bar I hold myself to. The code is not worth reviewing, I would never ask anyone to use it in real life, and have no plans to publish it to crates.io. Shit on it all you like.

I recognize this is not exactly a Rust specific post; I entirely understand and respect if the mods chose to remove it. I am posting it here because the denizens of /r/rust are incredibly defensive of keeping "AI Slop" out of the community, and maintaining a high quality bar for the community. I'm hoping that some of the discussion can be used to teach people who don't understand why their posts are being removed what considerations go into quality projects.

Lastly, many apologies for writing a novel. Despite the length, I promise it is all written by a meat popsicle, I just get rather verbose when writing about something I am passionate about.

Post Content Starts Here

In my personal life, I am a nerd, and enjoy playing Tabletop RPGs with friends. In the past, I have created tools to help me manage my games and characters (mostly spreadsheets, with some SPA's). I recently "wrote" some rust crates using Claude Opus to parse PCGen Game Data files, and the process me me wonder when, and even if, LLM written code can cross the rubicon to be considered "Quality" rather than "AI Slop".

In my professional life, I have been a Software Engineer since 2011, and cut my teeth on tmux and Vim (Emacs is an abomination). I am incredibly conservative when it comes to adopting / trusting LLMs. While I can recognize them as academically impressive, I think they are heavily misunderstood and misused. I am incredibly frustrated by the "AI Bros" who think they are "Rockstar Engineers" because they can throw money at AI providers and let an LLM produce something that looks slick, without actually understanding what it does (hence, the majority of my recent comments within /r/rust asking "What human involvement did you have beyond 'hey Claude, do X?'" in project posts).

I am currently employed as a Principal Engineer at an AI-forward company, within a particularly AI-bullish org. With so many tools available, and so much pressure to deliver, I am concerned about appropriate AI usage by my engineers, am fighting to make sure they know human judgement is still a critical expectation of their work. While I don't get much opportunity to code much anymore, I want to make sure they are still growing as professionals and understand what they are building rather than turning into "Press accept for Claude" robots.

Over the past year, I've called out many instances where engineers have overly trusted their LLM tools, leading to bizarre architectural designs and/or clearly low quality code, that they cannot justify when asked to explain, and admit that "Claude did that". There have been some articles going around our space about Cognitive Offloading vs Cognitive Surrender, and making sure engineers can still complete the "whiteboard defense" (link omitted, see end of post), both of which I think are good simplifications / explanations of my biggest concerns.

Edit: Removed specific examples of my LLM experimentation, after re-reading and realizing it distracts from what I'm trying to actually discuss

I've been experimenting with LLM codegen so I can better understand what my engineers are doing firsthand, trying to do everything from "vibe this for me, I don't care how" to "this is my overall goal, start with this small component and let me watch you like a hawk". The project I linked here is more of a loop of "vibe the slop then clean it up through follow up code review", but it made me wonder if it's even recoverable.

Thus I ask /r/rust:

1. Can a project primarily coded by LLM ever break out of being "AI Slop"?

2. If yes, what level of human involvement / judgement / guidance is necessary to cross the threshold?

3. What do you want to see to prove human involvement / judgement / guidance was applied to a project, to help you build confidence in it's quality, regardless of human / LLM authorship?

Note: This post was originally posted and quickly removed by AutoMod for linking to X. This is a repost with the X link removed, and the content copied below.

Appendix: Whiteboard Defense

Originally posted by Mitchell Hashimoto to X

The "whiteboard defense:" I should be able to pull you aside at any moment and ask you to explain any customer-facing system you've shipped. You should be able to clearly explain how it works and defend the decisions you made. This is my benchmark for responsible AI usage.

I don't expect line-level familiarity with the code. I don't care if you remember the exact function name or implementation detail. You may not even know it. I don't care.

But if I ask "why did you do X instead of Y?", "what happens if this actor behaves maliciously?", "what data structure did you use here and why?", or "where does this fail?" you should be able to answer confidently.

For PoCs, demos, experiments, whatever: I don't care. Generate 100% of it and understand none of it. Speed over quality every time in those specific scenarios.

But if you're shipping customer-facing work, you can't be shipping things you don't understand at a high level.

Hello everyone, I was thinking of starting some real projects after some warmup stuff I did with Rust. What are some tips for a beginner, generally? Or the cliche: If you were to start writing rust for the first time with your current knowledge, what would you do differently?

Why were panic handlers added in 2015? Did kernel devs asked for them or was there another motivation for them?

I vaguely remember about that or no_panic being asked by Linux devs, but can't find any sources.

Golang port, Cloud Hypervisor support, WebKitGTK3 video support, GIMP port, Servo 0.7 update, RISC-V dynamic linking, NUMA real hardware testing, virtiofs support and many more.

https://www.redox-os.org/news/this-month-261031/

im about to port js/ts codebase to rust using agents, I dont want it to write loose rust code

cargo toml:

[lints.rust]
warnings = "deny"
unsafe_code = "forbid"
rust_2018_idioms = { level = "deny", priority = -1 }
unused_qualifications = "deny"
unreachable_pub = "deny"
missing_debug_implementations = "deny"
missing_docs = "deny"

[lints.clippy]
all = "deny"
pedantic = "deny"
cargo = "deny"

allow_attributes_without_reason = "deny"
arc_with_non_send_sync = { level = "deny", priority = -1 }
as_conversions = "deny"
await_holding_lock = { level = "deny", priority = -1 }
dbg_macro = "deny"
expect_used = "deny"
fn_params_excessive_bools = "deny"
indexing_slicing = "deny"
mutex_atomic = "deny"
option_option = "deny"
panic = "deny"
rc_buffer = "deny"
rc_mutex = "deny"
significant_drop_in_scrutinee = "deny"
struct_excessive_bools = "deny"
todo = "deny"
unimplemented = "deny"
unwrap_used = "deny"

clippy toml:

msrv = "1.99.1"

max-fn-params-bools = 1
max-struct-bools = 1

allow-expect-in-consts = false
allow-expect-in-tests = true
allow-indexing-slicing-in-tests = true
allow-panic-in-tests = true
allow-unwrap-in-consts = false
allow-unwrap-in-tests = true

Instruction:
- Every mutable state machine must use a tagged enum.

- Invalid combinations must be unrepresentable.

- State fields stay private.

- One type owns the state and transitions it.

- No parallel booleans, magic sentinels, or nullable phase markers.

- No Rc, Cell, or RefCell in domain state.

- Arc and Mutex are limited to genuine cross-thread ownership.

- Every stateful subsystem must document its states, events, and invariants.

- Every transition and invariant needs an observable test.

- Agents cannot weaken these rules or add exceptions without explicit approval.

i need to read a file containing variables, which has the exact same format as a regular .env file (KEY="value")

the loadenv crate only reads $(pwd)/.env and does not accept custom paths (unless modified, which defeats the point of using a crate)

i won't ask AI

Hi all. I am doing 1BRC and I needed to print something on console with eprintln!. I do a lot of measurements and my code wall time was 1.22 seconds on 8 CPU cores. So I wanted to commit my changes and before that I removed the eprintln! code. You know. But that change increased my code wall time to 1.36 seconds.

This is the code before (wall time 1.22 seconds with 170272167824 instructions:u):

fn one(map: &[u8], thread_number: usize) -> HashMap<StationName<'_>, MeasurementStats, IdealHasherBuilder> {
    let before = Instant::now();
    let mut stats: HashMap<StationName, MeasurementStats, IdealHasherBuilder> = HashMap::with_capacity_and_hasher(1_000, IdealHasherBuilder);
    for (station, temperature) in StationTemperatureIterator::new(map) {
        let t = parse_temperature(temperature);

        let stat = match stats.get_mut(&station) {
            Some(stat) => stat,
            None => stats.entry(station).or_insert(MeasurementStats::default())
        };
        stat.update(t);
    }
    eprintln!("Time (thread {}) - one: {}s", thread_number, before.elapsed().as_millis());
    stats
}

and this is the code after (wall time 1.36 seconds width 202165675453 instructions:u):

fn one(map: &[u8], thread_number: usize) -> HashMap<StationName<'_>, MeasurementStats, IdealHasherBuilder> {
    let before = Instant::now();
    let mut stats: HashMap<StationName, MeasurementStats, IdealHasherBuilder> = HashMap::with_capacity_and_hasher(1_000, IdealHasherBuilder);
    for (station, temperature) in StationTemperatureIterator::new(map) {
        let t = parse_temperature(temperature);

        let stat = match stats.get_mut(&station) {
            Some(stat) => stat,
            None => stats.entry(station).or_insert(MeasurementStats::default())
        };
        stat.update(t);
    }
    stats
}

objdump showed me that get_mut is inlined in the version with eprintln!. Without it get_mut is a call on every row. So I added:

RUSTFLAGS="-C llvm-args=-inline-threshold=1000"

To make it fast again (1.09 seconds even faster than with eprintln!) but it's not something I would do at work as this config is for whole program instead of the problematic section.

So:

1. How do you handle this at work where performance matters?

2. How do you catch this generally? Those 11% is huge difference.

Code link: https://github.com/davidhruby/brrr/blob/part012/src/david/main.rs#L350

I am planning on making a simple websocket chat app to learn gpui and things since I've only tried egui. I made this small thing where you put in text and press a button and then it adds the message to a list and shows it. But, there's no cx.notify anywhere, so how does it know to update?

struct MessageListDelegate {
    messages: Vec<SharedString>,
}

impl ListDelegate for MessageListDelegate {
    type Item = ListItem;

    fn items_count(&self, _: usize, _: &App) -> usize {
        self.messages.len()
    }

    fn render_item(
        &mut self,
        ix: IndexPath,
        _: &mut Window,
        _: &mut Context<ListState<Self>>,
    ) -> Option<Self::Item> {
        self.messages
            .get(ix.row)
            .map(|text| ListItem::new(ix).child(text.clone()))
    }

    fn set_selected_index(
        &mut self,
        _: Option<IndexPath>,
        _: &mut Window,
        _: &mut Context<ListState<Self>>,
    ) {
    }
}

struct YapyapApp {
    message_list_state: Entity<ListState<MessageListDelegate>>,
    input_box: Entity<InputState>,
}

impl YapyapApp {
    fn new(window: &mut Window, cx: &mut App) -> Self {
        Self {
            message_list_state: cx
                .new(|cx| ListState::new(MessageListDelegate { messages: vec![] }, window, cx)),
            input_box: cx.new(|cx| InputState::new(window, cx).placeholder("Message")),
        }
    }
}

impl Render for YapyapApp {
    fn render(&mut self, window: &mut Window, cx: &mut Context<Self>) -> impl IntoElement {
        div()
            .flex()
            .flex_col()
            .size_full()
            .child(List::new(&self.message_list_state).flex_1())
            .child(
                div()
                    .flex()
                    .flex_row()
                    .border_color(Colors::for_appearance(window).border)
                    .border_t_1()
                    .p_2()
                    .gap_4()
                    .child(Input::new(&self.input_box).flex_1())
                    .child(
                        Button::new("send-message-button")
                            .label("Send")
                            .on_click(cx.listener(|this, _, _, cx| {
                                this.message_list_state.update(cx, |list_state, cx| {
                                    let text =
                                        this.input_box.read(cx).text().as_str().unwrap_or_default();
                                    list_state.delegate_mut().messages.push(text.into());
                                });
                            })),
                    ),
            )
    }
}

fn main() {
    gpui_kit::application().run(|cx| {
        gpui_kit::init(cx);

        gpui_kit::open_window(WindowOptions::default(), cx, |window, cx| {
            cx.new(|cx| YapyapApp::new(window, cx))
        })
        .expect("should be able to open a window");
    })
}

Also, if you see any un-idiomatic things please say

There are already frameworks like vstd with verus featuring static semantic validation. For example:

verus! {
    fn devide(x: f64, y: f64) -> (result: f64)
        requires
            y > 0.0,
        ensures
            result * y == x
    {
        x / y
    }
}

what would you think about making the requires and ensures clauses language-primitives? Than you could write just:

fn devide(x: f64, y: f64) -> (result: f64)
    requires
        y > 0.0,
    ensures
        result * y == x
{
    x / y
}

without having any external dependencies like vstd.

Do you think it would be a valuable addition to Rust? And if yes, do you think it should be part of rustc or should it just feature contracts for external verification tools?

I'm happy to announce the release of Diesel 2.4.0, a ORM and query builder for Rust. This release contains the development of the last 14 months, including the contributions of 76 people.

Headline features include:

* Support for database views

* Improved support for enums

* Support for batch update statements

* A distinct backend for MariaDB

* Extended support for SQLite functionality, including hooks, pragmas and BLOB's

* Support for using Diesel (SQLite) in a no-std environment

* Migrations written in Rust

* Support for diesel-async in #[derive(MultiConnection)]

See the announcement blog post about details to each feature: https://diesel.rs/news/2_4_0_release/

I would like to use this possibility to thank all contributors and sponsors that made this release possible. A special thank goes to Luca for his large contributors to the release, to Prototype Found for funding the development of the Database View support and to RustFoundation for funding the general maintenance.

Nevertheless, the Diesel project is always looking for support. You can help by:

* Contributing Code, Documentation, or Guides.

* Answering questions in our discussion forum

* Reporting bugs in our issue tracker

* Helping to triage issues in our issue tracker

* Sponsoring the maintainers.

* Filling out this survey about the current state and future developments of Diesel

a.f() vs f(a)

So if you make a trait that you want other to implement its obviously gonna be dot syntax. So is using it for purely syntactic reasons a bad idea? Builder pattern seems a common example of this.

Hi r/rust, I got tired of running out of disk space while working on a Rust project and using a lot of git worktrees. So here's the solution we came up with. It's a bit of a hack and uses some unstable features and the `__CARGO_TEST_CHANNEL_OVERRIDE_DO_NOT_USE_THIS` var.

Please let me know if there's a better way to do this. It also doesn't completely solve the problem since the shared dir can still grow very large, but I think it's still a worthwhile improvement.

My coding agents' Rust build folders reached about 311 GB, even with sccache at a 57% hit rate.

Each agent works in its own git worktree with its own target/, and a cache hit skips the compile but still writes the artifact into that target/. So sccache saved CPU, not disk.

One agent's 52 GB build folder held:

• 63,616 *.rcgu.o debug object files, 19.5 GB of them

• 21 copies of the same binary, because Cargo never deletes old artifacts

The first change was lighter debug info for every build my agent supervisor starts:

CARGO_PROFILE_DEV_DEBUG=line-tables-only

Backtraces keep their file and line numbers, and agents running tests rarely need the full variable info.

The second was stopping worktrees nesting. Agents had made them three levels deep, which put 76 of 80 out of the cleanup job's reach. Now they sit at the repository root, and the step that finishes a task removes its worktree and target/.

Write-up (the Rust part is one section of it): https://maclulich.com/blog/agents-clean-up-after-themselves/#a-build-cache-saves-cpu-not-disk (my blog)

How are others handling target/ across many worktrees? A shared CARGO_TARGET_DIR serialises builds on the lock, and per-worktree targets cost disk.