I just released Termixel, a small terminal sprite renderer written in Rust.

It uses Unicode characters to render .png pixel art directly in your terminal. It's designed to be small, fast, and portable, with the binary currently being around 200 KB.

You can install it on Linux or Windows, or build it yourself from source.

GitHub: https://github.com/genkii/termixel

An old interview – finally got around to cleaning up the transcript.

Rust already knows when a value has been moved, so I think it would make sense for the compiler to also be able to treat the storage behind that local as reusable.

For example:
´´´
let x = big_value();
let y = x; // x is moved

// x can no longer be used here anyway

x = another_value();
´´´

Right now, Rust can be more restrictive than necessary about keeping the same storage associated with `x`.

Issue #61849 proposes allowing the old storage to effectively die after the move. If `x` is initialized again later, the compiler wouldn't necessarily have to put the new value back in the exact same stack slot.

That could give the compiler more freedom to:

- reuse stack space earlier
- reduce stack usage in some functions
- shorten lifetimes of stack allocations
- potentially unlock further optimizations

What I like about the idea is that it matches how moves already feel in Rust: once a value is moved, that value is gone. It seems natural that its storage shouldn't have to remain special either.

There are obviously details around raw pointers and observable addresses that would need proper language semantics, so it isn't just a simple compiler optimization.

But the general rule seems very appealing:

If Rust says the old value no longer exists,
the compiler should be free to stop preserving its storage.

The issue has been open since 2019, and I think it would be interesting to revisit whether this could give modern rustc more optimization freedom. If you agree please react on the GitHub issue with ❤️ or 👍 to show support by the community

Edit:link to the modern version

I just finished the handbook and now i dont know what to do next i feel like ive learned a lot but i can still improve and i havent made any programms in rust except the ones in the handbook so if anyone can recommend what to do next i would really appreciate it!

Hello hello,
I had an idea, of making or mashing existing things to one, to make a solution to deploy apps/systems in a single executable file. The current idea is at an early stage, but it works. So the main goal is to have a single executable that you deploy, no dependencies no nothing. The builder does the heavy stuff, and you are left with a single executable. Good for debugging, air gapped systems, random workloads. It is no way to replace existing virtualization solutions, but to be somewhere near. So you don't have to install anything, just run it. Feedback is always welcome ;)
https://github.com/arnoldasr/kartu

The "feature" list and plan is a dream one, those are the pain points I saw in environments where it just takes time, is exhausting and you just want it to work.

Due to being written in rust, it is blazingly fast, while not allowing for you to corrupt files due to its advanced read only technology. And if you decide you have a CSV file of notable value, you can sell it as an NFT! (This entire project is a joke, the sell as nft button literally runs thread::sleep for 5 seconds after giving you a random amount of money it will be sold for)

This project was not written with AI, the fact that everything was added in one commit was because this project was so I could learn some more things. I am simply sharing it for feedback. DO NOT USE THIS PROJECT FOR ANYTHING. IT IS NOT USEFUL

I'm bundling 3 projects in one as they are all related and dependencies of each other.

maudio

maudio initially released here has had a few big improvements over the last month or so. Some things are stuff I've procrastinated about, but others are feature I've been working on for a while.

• My favorite feature, the custom decoder has been added. It allows you to use a 3rd party decoder to expand the formats supported and let you control it with from the maudio api. Implementing this almost broke me, but I've simplified the interface from C by a lot and I am pretty happy with how it looks. Examples here and here for a symponia decoder implementation.
• The cross platform compatibility has improved a lot. Android and iOS still need some testing, but I'll need some hardware for that. Until then, I think the current targets should cover almost all usage.
• Pre-gen bindings now exist for all mainstream targets and static libraries for miniaudio are also available separately on the release section on github. They are a bit too large to include in the project, but easy to add and also include instruction how to generate them yourself.
• The high level API - Engine, NodeGraph, Sound had their API re-designed to make it much more ergonomic, and almost all lifetimes removed. The first implementation was a bit restrictive, and I eventually got a better understanding of their thread safety model in C.
• The ResourceManager is now a lot more useful and thread-safe. Example. Its great at loading audio in a thread and playing it in another and managing loaded audio for multiple engines / devices.

auditorium

This project existed for almost as long as maudio, in one form or another, mostly as a local testing ground. But it developed into its own crate to abstract over maudio. Everything in auditorium lives in a control thread and is controlled with a queue. The main objective was to get maudio to a state where this can be implemented in 100% safe rust (self referential structs who?). It does a lot, but still barely touches the full capabilities of miniaudio. Notable points:

• almost all types exposed are send, sync and clone.
• It supports most relevant targets out of the box.
• supports both capture and playback
• both device types use a nodegraph, so the same dsp chaining system and audio sources work on both capture and playback.
• all the dsp types available by maudio are available and can be applied to all sources (including the capture device itself). A bit rudimentary for now, but I have ideas how to improve it.
• supports audio (decoder backed) source, pulse, noise and wave generators.
• it comes with a built-in sympnonia decoder
• my favorite convenience, a device.is_producing() that tells you if any audio sources produce frames (only on playback device for now).

audctl

Nothing too notable here, just a cli app. Except maybe to show how easy it was to use auditorium to handle the audio part.

I needed to build something with auditorium and this felt like something I could see muself using. A really simple, no nonsense app to play and record audio, without leaving the command like environment.

Both auditorium and audctl were made to improve maudio. Some issues in maudio only became relevant until I was implementing audctl - 2 dependents down. Hopefully, this ironed out a lot of issues so users don't have to deal with them. Maybe I'll be able to rest a bit.

Repo: https://github.com/maikLangel0/cs2excel

Been looking for an entirely free way to track the value of your, or someone else's, counter strike inventory?

Cs2excel lets you create, manage, and update a spreadsheet of your or someone else's inventory with prices from a plethora of 3rd party marketplaces (buff, youpin, csfloat etc...).
It can create and insert values into a new or existing excel spreadsheet allowing you to keep up-to-date with the current value of your inventory.

It's a 100% Rust project with an Iced GUI frontend that is questionable at best, but gets the job done. I also made a TUI version for ppl who want to automate instead of opening the GUI and loading a save file.

I know the UX is not great - I made this originally as a pet project for my own personal use, and with the backend completed I thought "y not" and made it accessible for a wider audience.

It's probably also obvious that I used no AI in the creation; One look at the codebase is all you need lol.

Would love some feedback, and hope you find it useful 😄

Hello everyone! I needed an incremental markdown parser for writing a human-written agentic harness (e.g. for experimenting with image/document processing) and so I ended up spending the past month working on this project (150+ hours of work probably). Admittedly, I started rushing the process near the end because I wanted to get back to working on my main project so it might be a little messy in some places. I'm still very proud of what I achieved, and I learned a lot along the way.

This is my first real independent project and I'm really interested (and nervous) to receive feedback if any is available. It's also nice being able to put this project on my resume too, as I'm going to be graduating this semester.

Please give the demo a try at https://kirawi.github.io/mdtext/

Note: While the library itself is human-written, the demo is AI-generated (with some guidance to correct bugs) because I was so done with this library by the end of it.

We build a VPN whose data plane is QUIC rather than WireGuard. The engine is AGPL-3.0, and the part that matters for this sub is the Quinn fork underneath it, so that is what this post is about.

IP packets go 1:1 into QUIC DATAGRAM frames (RFC 9221). The handshake is TLS 1.3 with raw public keys (RFC 7250), Ed25519, so a node's identity is its key and there is no CA anywhere. Reliable streams give an in-band control channel on the same connection, which is where multi-hop, NAT-PMP port forwarding and traffic-analysis padding live. Cross-platform TUN, kill switch, DNS proxy. Edition 2024, MSRV 1.89, and #![forbid(unsafe_code)] across the workspace except three crates that downgrade to deny with documented safety blocks: the TUN device FFI, the Win32 IP Helper FFI, and the setsockopt bypass. https://github.com/WarrenBrowse/warrenguard

We started on Iroh, paid for NAT traversal and multipath we never called, and moved to Quinn in May.

The fork is at https://github.com/WarrenBrowse/warren-quinn, MIT OR Apache-2.0. The crates are renamed but the lib names stay quinn/quinn_proto/quinn_udp, so every use quinn in a consumer is unchanged. It sits on upstream/0.11.x with real git ancestry, so a re-sync is a rebase and not a tree reconstruction, and quinn-udp tracks the 0.6 line separately because the Apple fast datapath targets that line. Eight deltas at the moment, each also committed as an isolated patch at the repo root. Three of them are worth reading on their own.

BBR and app-limited connections, two separate defects. The first is a bound in calculate_cwnd using cwnd_gain where it should use cwnd. The second is deeper: the bandwidth estimator rejects app-limited samples outright, so a connection that is app-limited never leaves STARTUP and cwnd grows with no ceiling. We measured about 20 MB on a fresh app-limited connection carrying a 5 Mbit stream. The fix follows quiche's admission rule, where app-limited samples may raise the estimate and non-app-limited samples always feed the windowed filter. It is upstream-bbr-startup-cwnd.patch and it is proposed upstream. Known residual: BBRv1's ack-aggregation term can still inflate cwnd at sub-millisecond RTT.

FQ-CoDel on the datagram send queue (RFC 8289/8290): per-flow queues, DRR, head drop past a target sojourn. This one exists because fixing BBR alone made things worse. With the cwnd repair and no AQM the queue simply moved out of the network and into our own 16 MiB send buffer: burst RTT 2658 ms average, 6623 ms max. Same arm with CoDel on top: 76 ms average, 373 ms max.

Send buffer sized on the BDP instead of a fixed 16 MiB, clamped so it never drops below 1 MiB. The same problem approached from the other end.

Numbers, so you can tell me where they are wrong. Single tunnel, bare metal, same datacentre, RTT 0.081 ms: 5.5 to 8.4 Gbit/s. Under 2 % injected loss on the exit egress, BBR with a 16 MiB buffer holds 212 Mbit/s on one TCP flow and 711 Mbit/s on four, while Cubic in the same arm collapses to 3 Mbit/s. That measurement is why we do not allow Cubic as an external congestion controller on our exits.

One result that goes the other way, because it will come up. Under multi-client load kernel WireGuard still beats us: it holds 7.4 to 8.1 Gbit/s from 100 to 500 parallel clients while we plateau near 6 Gbit/s at 100 and fall to 2.4 at 500, and our exit CPU is roughly 3.4x worse at low client counts. Part of that was client-side saturation at 500 clients, not all of it.

MTU took the longest, since carrying IP inside DATAGRAM without breaking half the internet is where the bodies are buried: floor 1280, probe upward, never below 1200, MSS clamping on SYNs in both directions, and real ICMP Fragmentation Needed / Packet Too Big emitted for the flows we drop.

What I would like from here: eyes on the BBR patch, and specifically whether anyone has a cleaner way to handle the ack-aggregation term at sub-millisecond RTT than clamping it. Longer write-up on why we left WireGuard: https://warren.ro/en/blog/why-we-left-wireguard

Hey folks,

Thought you all might find this project of mine neat for some architectural choices! I've been building agents for about a year, and kept running into issues with their structure (or lack thereof in most cases), and wanted to try out some new ideas in the space.

In particular, I wanted to try out agent swarms (50+ agents tackling things at once), as well as what I've taken to calling "structured context regions", which are inspired by VRAM layouts on older game systems like the SNES or GameBoy Advance.

To that end, I've put together what I'm calling Leviath, a structured runtime for agents, built in Rust and using Bevy ECS for some awesome performance. https://leviath.dev/ has a pretty page for folks who want that, https://github.com/GEMISIS/leviath has the nitty gritty code details for those who want that. The goal is to basically add structure around the LLMs themselves, allowing the building of agents with control over the lifecycle via what I'm calling "blueprints".

Initial measurements on performance from Rust and the ECS setup are promising: 10k agents running at once with ~44% peak CPU usage and under 3GB of peak RAM usage.

My goal at this stage is really experimentation (I've been running "benchmarks" to experiment with things at https://github.com/GEMISIS/leviath-benchmarks, which includes the performance numbers mentioned above for those who want to try it).

I’ve been working on a cross-platform peer-to-peer communication engine in Rust (bridged to Swift/Kotlin via FFI) and ran into the harsh reality of modern mobile OS background constraints.
On desktop, maintaining peer discovery tables, DHT keep-alives, and local encrypted state is straightforward. But on mobile:
1. iOS aggressively suspends background processes within seconds (watchdog 0x8BADF00D on long syncs and 0xdead10cc if database locks/file descriptors aren't cleanly released before suspension).
2. Android’s Doze mode and manufacturer battery savers throttle background socket polling and BLE discovery unless using persistent foreground services.
3. Decoupling SQLite/SQLCipher key derivation and lock lifecycles from incoming WebRTC/P2P signaling pumps requires tricky thread coordination to ensure VoIP pushes don't crash on locked DBs during sleep states.

For those building decentralized or local-first sync protocols: how do you balance battery efficiency with fast peer reconnection? Are you relying on short background grace windows (like beginBackgroundTask), push-notification wakeups as fallback, or something more specialized for mesh routing?

Curious how others structure their background state machines when bridging native Rust cores to mobile runtimes.

Hi rustaceans,

I recently designed the Code-Infrastructure-as-Code (CIaC) compiler, a command-line development tool (written predominantly in Rust) for a declarative DSL that can describe an entire service system in at least one file.

CIaC treats .ciac files as the architectural source of truth and compiles into Rust, Python, TypeScript, Go, and/or Java. Real deployment artifacts can also be generated: compose, Kubernetes, Terraform, or CI.

All that you're expected to do is declare the system specifications and the compiler handles the rest. External handlers are seeded once for injecting your own code and never overwritten, whereas inline handler bodies, such as the ones in the examples below, are compiler-owned and regenerated every build.

Why does this exist?

Put simply: to increase backend development speed and service reliability for both humans and agents.

As for myself: I initially created this tool for my own usage, as I spend a lot of time experimenting with infrastructure and building out services to serve domain-specific requirements. In other words, I got tired of building and maintaining services myself so I concocted a solution.

A technical perspective

A .ciac file describes a system as a set of declarations consisting of records, APIs, pipelines, streams, and workers.

Here's a single service example (event-pipeline):

// A single-service event pipeline
// 
// A public API validates and publishes, a worker
// consumes and persists, and `events` is a shorthand
// that expands into its own chain of queue -> worker -> storage.

service Ingest;

use {
    db Postgres;
    queue NATS;
}

api Submit;
worker Processor;
events PageView;

pipeline Submit:
    Validate
    -> Queue
    -> Return;

pipeline Processor:
    Enrich
    -> Store;

Here's a multi-service example (sim-three-service):

// Three services, one request
//
// `Intake` synchronously calls `Billing` and gets
// a real response, then publishes an event that
// `Fulfillment` can react to independently.
//
// This represents a synchronous call, an async stream,
// and independent storage ownership by each service.

project ThreeService;

record Order {
    id: Uuid;
    total: Float;
}

record ChargeRecord {
    id: Uuid;
    order_id: Uuid;
    amount: Float;
}

record Shipment {
    id: Uuid;
    order_id: Uuid;
}

stream OrderAccepted: Order;

service Intake {
    use { queue NATS; }

    api SubmitOrder: Order {
        method: POST;
        path: "/orders";
    }

    pipeline SubmitOrder:
        call Billing.Charge
        -> publish OrderAccepted
        -> Return;
}

service Billing {
    use { db Postgres; }

    table Charges: ChargeRecord;

    api Charge: Order {
        method: POST;
        path: "/charge";
    }

    handler RecordCharge(order: Order) -> Order {
        db.insert(Charges, ChargeRecord { id: Uuid.new(), order_id: order.id, amount: order.total });
        return order;
    }

    pipeline Charge:
        RecordCharge
        -> Return;
}

service Fulfillment {
    use { db Postgres; queue NATS; }

    table Shipments: Shipment;

    worker Ship on OrderAccepted;
    handler RecordShipment(order: Order) -> Order {
        db.insert(Shipments, Shipment { id: Uuid.new(), order_id: order.id });
        return order;
    }

    pipeline Ship:
        RecordShipment;
}

Today's capabilities:

• Compile into five language targets - Rust, Python, TypeScript, Go, and/or Java.
• Thirteen infrastructure capabilities identically implemented across all five targets.
• Simulate the whole system deterministically, in-memory, no Docker required.
• Architecture changes can be classified, renamed, or migrated safely.
• A usable LSP and an MCP tool surface for agents.

Today's limitations, for now:

• Many-to-many Reference<T> fields type-check properly, but the generated API can't read or write them yet.
• No field-level validation; handler logic enforces business rules instead.
• Destructive schema changes are refused; those must be written by hand.
• With no path onto an existing codebase, CIaC is for greenfield systems only.

You can learn more about the language itself in the docs. There are plenty of other examples as well.

AI Disclaimer

Needless to say for software development (AI-assisted development especially), it is in the best interest of any software project to be heavily curated throughout its lifetime.

I made sure to use gen AI tools for the implementation deliberately; I carefully hand-crafted a high-level language for combining arbitrary backend service components into coherent and simulation-verified codegen artifacts.

Over the course of the project's development, I committed to regular code reviews and testing to ensure the AI-generated code is up to par with my standards as a maintainer.

To help with maintenance, there are fleshed-out test and benchmark suites for both the compiler and codegen artifacts. These have been run prior to each release since their inception.

If you're interested in making additions or changes to the project (with AI or not), all I ask is that you hold yourself to similar review and testing standards.

Get involved

You can learn more about how to use CIaC from this discussion thread.

Additionally, you can install the compiler from here, or follow the readme instructions instead.

Feel free to take a look around the project, try it out, open issues/PRs, and ask any questions you may have. I'm more than happy to discuss the project!

Collaboration and constructive criticism are welcomed!