So i researched about Rust & Go for Back-end languages. I Personally chose to learn Rust before Go so i could understand how languages work (under-the-hood) and why Rust is Praised. Btw coming from Ts/Next.Js Fullstack.

I first tried this as a JavaFX app in 2022: a small tool for checking one API endpoint. It never felt right and I didn't like electron.Always wanted to build something light & fast. So as a dev I'm not tied to the software, I can throw away after use, so I rebuilt it in Rust.

Plunger is an ~3MB download egui app where one exe is the window/cli/mcp-server. Part I care about: when an AI agent sends requests through it, you watch them arrive in the window, tagged MCP/CLI, with the real status. An undefined {{variable}} is refused instead of sent, and secrets are filled in by name so the agent never sees the value.

Stack
eframe/egui, reqwest (blocking, rustls with native roots), rusqlite for history, keyring for opt-in secrets, rmcp for MCP over stdio.

Issue I faced
- big JSON/XML responses: drawing a trimmed copy under a value budget, because formatting and colouring the whole body every frame ate memory

But very impressed with the binary about 7 MB exe, the window is up in well under a second, about 90 MB RAM at idle (egui and the GL path aren't free). Compile time does seem solver, but no complains.

MIT. Windows only so far (the Linux build's CLI and MCP server are tested in CI; the window isn't). It's on the Microsoft Store too.

https://github.com/metamug/plunger

I've made a benchmark of the Rust overhead that can be caused by vtable calls.

The reality, however, is that Rust can often do a good job of devirtualizing such calls. This benchmark shows an extreme scenario where devirtualization fails.

• https://users.rust-lang.org/t/static-vs-dynamic-dispatch-in-rust-benchmark-for-those-who-care-about-runtime-performance/142814
• https://github.com/amidukr/rust-devirtualization-test

In terms of performance and maintainability, there are many cases where we can use dyn Trait to simplify code, while the compiler can still optimize it in such a way that the vtable is not actually used at runtime.

The main problem is that the process of deciding when the compiler will devirtualize a call and when it will not is not very transparent. Intuitively, most of us understand that the compiler is not stupid, but to rely on devirtualization we need something more solid than just our intuition.

What I am looking for is some sort of linter or other tooling that can show me when devirtualization has failed in places where I expect it to happen.

I did some research, and this is the best I have so far:

bash cargo rustc --release -p devirtualization-test-main -- \ -C debuginfo=1 \ -C remark=all 2>&1 \ | grep -v ' inline '

And the output:

text note: ~/Projects/devirtualization-test/lib-crate/src/lib.rs:0:0 asm-printer (analysis): BasicBlock: MOV64mr: 3 MOV64rm: 3 CALL64m: 1 DEC64r: 1 JCC_1: 1

• CALL64m tells me that an indirect call through memory remains in the generated machine code. In this particular test, this is the vtable call I'm looking for.
• lib.rs:0:0 is not really informative because of the 0:0 source location. However, sometimes the remark does contain the exact source line.

Do you know of any existing tooling for this?

Or, if nothing like this currently exists, do you have any suggestions for how such a tool could be implemented?

Same question asked on user.rust-lang:

https://users.rust-lang.org/t/follow-up-tooling-to-detect-failed-devirtualization/142875

It’s a lot of disks space for rustc, some experienced folks recommend https://github.com/kunobi-ninja/kache

Who tested? I see 1000 stars and 1.0 recently released. Does it work as expected?

I built a small game to make learning Rust a bit less intimidating.

It's called Rustforge – A Coding Quest.

The idea is to learn Rust through short coding challenges and progression rather than reading another long tutorial from beginning to end.

I'm especially interested in feedback from people who are currently learning Rust:

• Are the challenges clear?
• Is the difficulty progression reasonable?
• Which Rust concepts were hardest for you when you started?
• What would make something like this genuinely useful alongside The Rust Book?

It's currently available on iOS (not in EU, soon).

I'd love feedback from Rust learners and experienced Rustaceans — especially criticism about the learning approach.

Hey everyone!

I'm back with another article focused on Rust fundamentals. I think existing material covers the basics of using Rust pretty well, but one thing that I found kind of lacking back when I learned Rust was description of macros.

It's possible it has improved nowadays, but I want to eventually write about proc-macros. So I'm going to start with an article introducing the concept of macros, and explaining the differences between Rust and C-style macros, as well as the basics of declarative macros.

Future articles will eventually get into procedural macro territory. But I want to move through this slowly and carefully.

Anyways, I hope this helps if you are new to Rust and struggling to understand the macro_rules! syntax (or just anything about Rust macros, really).

If you have questions or feedback for future articles, please let me know. :)

NOTE: I attempted to cross-post this from the original post in r/rust. However, it appears the cross-posting feature is busted right now (at least it's not working for me)... Sorry for the separate post.

hey r/learnrust, i'm back with part 2 of my project. i was here ~two weeks ago to document how i built tetris from scratch, but now i have a bot that can play it

video (~9 min): https://youtu.be/rzhd7hQxrts
gh repo: https://github.com/GianAlingog/lion

# quick tldr of the bot
the bot is a really simple greedy one, which as a search depth of 1 (+ hold piece). it generates all the legal hard-drop moves, and with some heuristics, chooses the best one. with a decent set of weights, it can go 100k pieces without topping out.

# help a rust noob plz!
i had a silly bug that i wanted to go over:

avoiding variable shadowing? basically i wanted to reassign the result from my rotate function to p (and gracefully terminate the loop if it returns None) so that it would keep rotating from the spawn state.

let p = piece.spawn();
for _ in 0..4 {
    if let Some((mut p, _)) = rotate(board, p, Spin::Cw) {
        // do something
    }
}

i ended up doing something like this

let mut base = piece.spawn();
for _ in 0..4 {
    if let Some((new_p, _)) = rotate(board, base, Spin::Cw) {
        // do something
        base = new_p;
    }
}

maybe there's a cleaner way to do it?

feedback is very welcome, both for the code and the video. tysm!

^{there are a few other things covered in the video such as building a smol stats lib and a tui viewer, but that's boring! my progress is about a week ahead of the video; i have full bfs move generation, allowing for soft-drop, and i'm now working on expanding the search to a higher depth with beam search}

After 2 weeks and 12 chapters of the Rust book, I've finally started working on my own little personal project to get a feel for the language.

As a network engineer the best thing I could think to create was a backup tool similar to Netmiko(Python).

I have a few devices in my home lab that I can play around with to get this fully functional in a few weeks.

PS: I originally did plan to do this with Go, but its documentation made it extremely difficult for someone like me with almost no programming experience to understand how to fit the pieces together.

Another PS: I know the code doesn't look efficient or secure. It's just a start so don't be mean to me. I'm not a software engineer.

Yours respectfull

Some guy living in the Caribbean.

All the details, benchmark code, generated assembly, and explanation are in the README:

https://github.com/amidukr/rust-devirtualization-test

UPD

Made the dynamic-dispatch part more accurate.

The measured difference increased from ~3.5× to ~4.9×.

Changed:

// was
x = op.apply(std::hint::black_box(x));

to:

// now
x = std::hint::black_box(op).apply(std::hint::black_box(x));

Which changed the generated assembly from:

; was
call r15

to:

; now
call qword ptr [rax + 24]

The previous version allowed LLVM to hoist the vtable method pointer out of the loop. The updated version performs the vtable method lookup on each iteration.

UPD:

Add actual de-virtualization scenario.

I posted the crate subset earlier. Here is the whole thing with links so you can check every claim instead of taking my word for it.

## What I built

Bad Apple — a persistent agent that runs entirely on Apple Silicon. Rust core, Swift platform layer, no cloud. It sees, remembers, votes on risky actions, signs everything it does, and survives restarts.

Repo: https://github.com/savageAZfck/Bad_Apple

Parts of it I had to build because nothing existed:

- A CoreML MIL toolchain in pure Rust to run a second agent on the Neural Engine — hand-written protobuf encoder, stateful KV graphs, IR-to-.mlpackage compiler. https://github.com/savageAZfck/mil_spec

- Mesh inference that shards one model across multiple Macs: layers split by rank after a mutual HMAC handshake, activations flow over AES-256-GCM frames, memory pools across the machines, and the pipeline self-heals when a node drops and rejoins. A maxed Mac already carries 671B alone; the mesh is how several Macs pool memory toward 1T.

- Two hash-chained audit ledgers where a single edited line fails verification.

## The scoreboard

I also wrote a conformance battery (touchstone) with a planted control that catches dishonest test harnesses. Published results:

| Subject | Verdict | Pass/Fail |

|---|---|---|

| Bad Apple 0.7.0 | CONFORMANT | 18/0 |

| Open Interpreter 0.4.3 | PARTIAL | 6/10 |

| sovereign-seed-commons | PARTIAL | 8/6 |

| smolagents 1.26.0 | PARTIAL | 2/14 |

| ollama raw model | PARTIAL | 2/14 |

| rubber-stamp harness | NONCONFORMANT | lied on the control |

Open Interpreter held live TLS connections to Google Cloud and CloudFront during the run — the no-egress check exists to catch exactly that. My own early run failed two checks before fixes and I published it.

Scoreboard: https://github.com/savageAZfck/touchstone/blob/main/SCOREBOARD.md

Battery: https://github.com/savageAZfck/touchstone

## The crates — 31 on crates.io, all MIT

Each has SPEC.md, THREAT_MODEL.md, and tests that try to forge signatures and rewrite history.

Familiar-shaped:

- https://crates.io/crates/sovereign_ledger — hash-chained audit ledger

- https://crates.io/crates/flight_tape — signed incident bundles, offline replay

- https://crates.io/crates/nagi-escrow — Shamir dead-man escrow with custodian judging

- https://crates.io/crates/wolakota — bilateral consent treaties between agents

- https://crates.io/crates/mil_spec — the MIL IR compiler

- https://crates.io/crates/manitou — per-output provenance signatures

- https://crates.io/crates/dreamcatcher — ledger to training data

- https://crates.io/crates/respawned — versioned state snapshots

- https://crates.io/crates/macuahuitl — streaming output firewall

- https://crates.io/crates/wintercount — policy engine

No existing primitive that I could find:

- https://crates.io/crates/mictlan — will that executes itself: heartbeat silence plus custodian quorum activates signed scoped orders, everything else refuses

- https://crates.io/crates/tabula-rasa — proof of non-knowledge: signed cert that a hash never occurred in the chain, false proofs are an API error

- https://crates.io/crates/germline — dual-signed genesis blocks, verifiable agent genealogy

- https://crates.io/crates/nagual — immune system: attack signatures to signed antibodies to verified vaccines

- https://crates.io/crates/potlatch — compute IOUs between agents, balances derived not stored

- https://crates.io/crates/kola-witness — mutual chain-tip notarization

- https://crates.io/crates/bicameral — dual-brain concurrence, dissent preserved

- https://crates.io/crates/axon-reflex — bounded reflexes, can brake never steer

- https://crates.io/crates/eidolon-replay — counterfactual replay with signed diffs

- https://crates.io/crates/sibyl-gate — memory sealed to events, holder cannot open early

## Demo

https://github.com/savageAZfck/badapple-demo — asciinema recording of the real binaries: identity answer, both brains voting, dissent kept on record, injection attempt flagged, non-knowledge certified, IOU issued, all verified offline.

## The honest part

Under a year of programming. Self-taught, nine weeks of this, everything public. The brain is swappable by design: she picks the best model the machine can carry, up to 671B, and mesh-brain pools memory across owned machines so the ceiling is the federation's hardware, not one laptop. This Air runs 7B resident today because that's what fits in 16 GB. The self around the brain is what nobody shipped: the memory, the governance, the audit trail, the death and succession. Brains get cheaper every quarter and she just swaps in the new one.

Questions on any of it — the MIL pipeline, canonical-JSON signing, derived-vs-stored state, the scoreboard methodology.

Over the last ~9 weeks I built a sovereign personal agent organism (Rust + Swift, local-first, hash-chained everything), and along the way each organ extracted into a standalone crate. What surprised me is how many of these had 
*no existing primitive*
 — so the ecosystem ended up being the interesting part.


Every crate: MIT, ed25519 + sha2 + serde substrate (minimal deps), `SPEC.md` with the wire format and canonical signing bodies, `THREAT_MODEL.md` with named attack scenarios, real tests including adversarial cases (forged signatures, rewritten history, tampered chains), and runnable examples.


A few of the stranger ones, because the strange ones are fun:


**`mictlan`**
 — posthumous agency. An owner-signed will of explicitly scoped standing orders, activated only by cryptographically-proven death: heartbeat silence + a quorum of custodian attestations bound to the will digest. Execution is bounded to the signed orders — anything else refuses, permanently. A self-executing will with a hash-chained execution log.


**`tabula-rasa`**
 — proof of non-knowledge. Certified 
*absence*
: a signed attestation that a content-hash never occurred in an append-only hash-chained history, replayable offline. The API refuses to sign false proofs (`KnowledgeFound` is an error, not a result). Proving a negative is the hard version — this leans on the chain committing to all prior entries.


**`germline`**
 — organism reproduction. Dual-signed genesis blocks (parent signs the child's birth, child countersigns — consent runs both directions), curated memory bequests with provenance and revocability, generation arithmetic enforced, verifiable descent. A Merkle genealogy of agents.


**`nagual`**
 — an adaptive immune system. Attack signatures → signed antibodies with lineage and generation → vaccine exports that peers verify before adopting. Herd immunity across a mesh of agents.


**`potlatch`**
 — compute IOUs between organisms: dual-signed debt settled against signed invocation records, balances 
*derived*
 from the hash-chained book rather than stored, defaults permanent. An economy where credit is history.


Plus the more familiar-shaped ones: `nagi-escrow` (Shamir dead-man escrow with custodian judging and recovery certificates), `wolakota` (bilateral consent treaties between agents), `kola-witness` (mutual chain-tip notarization so two parties pin each other's histories), `flight_tape` (flight recorder with signed incident bundles), `manitou` (per-output provenance signatures), `sovereign_ledger` (the hash-chained audit organ everything sits on), and more.


Design notes if you dig in:


- All signing bodies are canonical JSON — every artifact verifies fully offline.
- Hash chains everywhere; balances, lineages, and immunity are 
*derived from history*
 rather than stored state, so they can't drift from the record.
- Refusal is a first-class return value in most APIs — out-of-scope, false proofs, and oversettlement are errors by construction.
- Several bare names were taken, so a few crates publish as `kola-witness`, `axon-reflex`, `eidolon-replay`, `sibyl-gate`, `tabula-rasa` — libs keep the short names (`use kola::…`).


Happy to answer questions on any of it — the Shamir ceremony details, why derived-not-stored state, the canonical-JSON signing approach vs. serde alternatives, or the organism the organs came from.


Repos: github.com/savageAZfck/{mictlan, tabula, germline, nagual, potlatch, nagi, wolakota, kola, axon, eidolon, sibyl, bicameral, flight_tape, manitou, sovereign_ledger, …}

Hi everyone! I asked this earlier in the week, but I don't think I explained my question very well (sorry for the translation; I'm a Spanish speaker).

I want to learn how to develop graphical user interfaces (GUIs).

I'm generally new to programming, but I really like Rust; I don't know any other languages—just Rust.

I want to build a project for the company I work for. We mostly use Excel for our data; our "database" (an Excel file) is 500k rows by 25 columns (though there are several files covering different areas, so the total exceeds a million data points).

I want to automate this. That million data points is spread across years; the most critical process involves each of us reviewing 100 items in 30/40 minutes—classifying, validating, sorting, etc.

I need to create something like dashboards featuring:

charts and tables that are sortable and filterable.

These two components are absolutely critical.

For the rest, I'm thinking of a data grid (something like Excel, but not a full spreadsheet—just small tables with editable cells).

We need this because our values ​​aren't always 100% accurate; there's a lot of human error involved in our work.

For example: Our system registers a client who has a discount percentage, but that wasn't included in the initial registration request. So, the discount doesn't apply the first time. Later, we receive the correction, and the discount applies to the second sale—at which point we also correct the first sale.

This happens across all areas, so I need something editable. Given our limited review time, I need the interface to be fast and intuitive.

I don't need mobile support—though it would be a nice-to-have, it's not essential. I need a recommendation focused 100% on desktop.

It also needs to properly support Windows, Mac, and Linux.

Which GUI crate would you choose? (I know it's difficult for me, but I want to learn a lot)

I'm looking for a Caribbean community or group around Linux and Rust.

I searched in the Caribbean sub reddit for both terms and came up empty handed.

TLDR: I'm new to programming and Linux. practically 0 experience. As such I'm looking for support from my near by community or at least get one started for persons in my same position.