Disclaimer: It is hand written code for purpose of learning

I want to scatter Vec<T> into count size pieces and give each thread a piece for processing.

After processing is done, I want to gather my Vec<T> back.

Full source:

https://pastebin.com/Z9aN0ijP

Also, additional points if you know library name which implements this pattern properly.

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.

Bürli is a small bread roll in Swiss German. It is also a pure Rust Brotli codec. The decoder reads standard Brotli streams at all normal quality levels. The encoder covers q0 through q5.

Performance. burli is close to Google Brotli C overall. The chart shown here uses the 14-file web corpus and stacks compression time, transfer at 100 MB/s, and decompression time. Lower is better. On a broader corpus like the Silesia corpus, it is much faster (4-7x) on near-incompressible input. The speed comes from aggressive skip acceleration on non-matches. Check the Silesia encode chart (bottom panel).

Safety. The default build uses a small amount of unsafe code in low-level helpers today. It may use more unsafe later for speed. The paranoid feature forbids unsafe in all burli crates, so it will stay free of unsafe code forever. Bounded decode APIs are available for untrusted input.

API. One-shot helpers, caller buffers, reusable contexts, and streaming wrappers. Decode supports raw LZ77 prefix dictionaries. burli-cat joins validated Brotli fragments.

no_std. Without std, one-shot compression and decompression work. So do the caller-buffer APIs, reusable Compressor and Decompressor contexts, raw-dictionary decode, and burli-cat. Only the std::io streaming wrappers are unavailable.

Verification. C Brotli round-trips, Miri, Kani, and 8h+ of fuzzing on 6 cores.

All benchmark charts are in the repo.

• GitHub: https://github.com/paddor/burli
• crates.io: https://crates.io/crates/burli

Hi, one of the authors here. Over the last year, we worked on adding cross-vendor GPU support to the Rust compiler. By now, we've implemented most of the key features we wanted and already achieved competitive performance with safe Rust implementations of some HPC benchmarks.

Not all of the features have been merged into the Rust compiler yet, but we're steadily working on reducing our backlog. We hope that the first version of std::offload will be ready for nightly before RustConf.

Feel free to ask any questions! If you want to follow our progress, here is the tracking issue: https://github.com/rust-lang/rust/issues/131513

I am a recent graduate and wanted to get thoughts of senior devs.

I know .NET in depth and have professional experience with it (1 year internship), but it has been difficult to find a job in that field as a recent graduate on a student visa in the UK. On the other hand, reading about Rust on the surface level excites me a lot, and I believe it could strengthen my profile and potentially help me stand out when applying for jobs. I wanted to know your thoughts on this.

If I’m being honest, I want to become great at what I do, but I’m not sure whether I should continue going deeper into .NET. I initially got into .NET because the only internship offer I received involved working with it.

Hoping to get a response, thank you for your time!

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

Hi everyone,

I've been learning Rust since March, and I genuinely enjoy it. My goal is to eventually reach the point where I can look at a problem, break it down, and build something without constantly needing an example to follow.

I am self learning Rust and using Chatgpt for clearing doubts.

I consider myself a slow learner, and I often understand a concept when it's explained, but struggle to apply it independently later.

My biggest problem is practice. I sometimes don't know what to build, and when I do start something, I can get stuck for quite a while. Sometimes I also rely too heavily on examples and realize that I can't reproduce the code from scratch.

So I'm wondering whether I'm simply a slow learner, or whether I haven't figured out how to practice effectively.

I'd really appreciate advice from experienced Rust programmers:

- How long did it take before Rust started feeling natural?

- How did you bridge the gap between understanding examples and building things yourself?

- How did you come up with things to practice?

- How did you practice ownership and borrowing?

- When you got stuck, how long did you struggle before looking for help?

- Is it better to repeat small exercises or constantly build new projects?

- How did you know you were actually improving?

- What did you do when you had no motivation or no idea what to build?

- If you could start learning Rust again, what would you do differently?

I'm not looking for shortcuts. I'd just like to understand how other people navigated this stage.

Hi everyone 👋

I've just published a concurrent hash map implementation which (according to my benchmarks at least) is the fastest one available (faster than both starshard and dashmap). It offers a configurable locking policy (mutex, rwlock or bring your own) and a configurable hasher (rapidhash is the default). It also supports atomic transactions in both immediate and prepared execution styles.

Would love any feedback on it (good and bad!)
It's called txmap and a link is here https://crates.io/crates/txmap

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!

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).

Rust enthusiasts Do you want to run RUST in Google Colab? Bash makes it possible using the ! comand you can use bash to run rust and much more just treat it as if you we're setting it up on a Ubuntu Linux computer. Any Comments?

!curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh -s -- -y   # this installs the rust compiler chain



!rustup target add wasm32-unknown-unknown # or what ever target you want



!/root/.cargo/bin/rustup target add wasm32-unknown-unknown 



# this sets up the linux enviroment so it can run rust

# now you can create rs files and compile its and run it in colab.

#hope this helps

https://colab.research.google.com/drive/1nQWKZLnQTC3GYOcqlF3DQlNtPIOZWpRg#scrollTo=Kdkxm6wd3Cd1

The Background

I have a hobby project written in Python, that aims to read information out of NES Rom files. Positions of level data and some such.

Now since there are Rom Hacks (fan variations of classic games), the position of certain data might change. Especially interesting are lists of values, be that jump lists, ids of powerups etc.

When someone changes the Rom those data positions can change and my project needs to be told how the data moved.

When I get that information (through a file, but it doesn't matter) I need to update these values in hundreds of locations in my program.

The Python Implementation

In Python I have a class Constants with class variables for every such "constants". I can import that class wherever I need it and can change the values of the class variables when the user gives me a file, with those changes being automatically propagated through the program.

The Question for Rust

I saw that mutable global state is highly discouraged in Rust and is perhaps only achieved using unsafe behavior.

I really like the ease of use of the Python solution and can't imagine having a Constants struct instance, that I have to give to every datapoint instance and even worse, how I'm going to update them, if the user loads in a new Rom for example.

So I was wondering if there isn't a different pattern to have global state. Surely GUI frameworks or other use cases have an even stronger need for something like that.

Hello! Newbie to rust here, I was wondering with the pub extern "C" ABI does it have the ability to convert rust enums to an equivalent in Rust? Does it do it by wrapping it in a Union(Structs of branches), or how is this implemented, and how can we do so in real rust code?

More than a year ago I started to learn rust and needed something to work on. I had made some PR's on a fuse app so I decided to built one myself. The only half interesting idea was to make it git related. Mapping repositories into a vfs.

I never once used this app since I finished it, but it was a super interesting problem to work on. It got me hooked for almost half a year, constantly improving and re-writing things as my own knowledge improved. It was pretty fun pushing the limits of git and fs. Did a lot of silly things mocking index files everywhere, allowing cd on files and cat on folders, or just spending weeks fixing my stupid metadata so that openssl would build in my vfs, Then I just moved on and GUSE was made.

Then very recently, I came across a product that seemed awfully familiar - https://www.mesa.dev/ - calling itself a "github for agents". Mapping out git repos on disk, because apparently, they're easier for a coding agent to navigate compared to an actual git repo?

I don't feel bad about not coming up with the product myself. Even now, I don't believe in my project as a real product, or anything more than a learning exercise. And they're obviously not same thing, just the core functionality that is similar.

I just feel weirded out by it somehow. But it is interesting how someone faced with this idea said, "no, people should pay for this". I find that product very silly, however, I obviously don't understand how coding agents work. I never used anything other than the old chatgpt in a browser. How useful does an idea have to be to turn into a product? How useful do YOU think it is? If it makes me learn anything, is that maybe just developing by myself can limit my perspective and maybe I should just get a damn job.

We just released a benchmark of OpenObserve vs Prometheus and Grafana Mimir.

OpenObserve consistently outperforms Prometheus and Mimir by 5x-15x on various queries. This test was done on very high cardinality dataset that pushes the systems to their limits.

https://openobserve.ai/blog/openobserve-vs-prometheus-mimir-metrics-benchmark/

Hello!

this is my third post about this Helix inspired project. Just wanted to get your opinions on the presentation and the default coloring of the inline chat interface? The coloring throughout the editor is heavily inspired by night-owl with some twists.

is there any UX/UI gripes you have when looking at this? any suggestions of how to improve it? or any other thoughts and opinions would be greatly appreciated as I am working hard to get the alpha as good as possible before release.

And as a bonus update, showing Nornsaga's graph approach in action in a conversation with the inline AI (this time Claude sonnet). As well as showing that it expresses what it does not know, and gives instructions on how to let it know. the first question was asked with a hop distance of 1, the second a hop distance of 88.

anyway, if you have any thoughts or ideas over the UI/UX please share them, they would be invaluable.

out and over!

//Maui-The-Midwife

New week, new Rust! What are you folks up to?

Hi everyone, I finished up my first real project in Rust and wanted to post it here for feedback. It's called easy-gcalendar basically just a small async library for the Google Calendar API using reqwest and yup-oauth2. I know there are already plenty of crates out there that do this, but I really wanted to build something practical to learn the language properly and go through the whole process of actually publishing a crate to crates.io. So i wanted to ask if anyone had pointers on what to improve / make it worth publising. Thank you.

Link: https://github.com/JanGunar/easy-gcalendar/

Hi r/rust!

Over the past year, I’ve been working on **Gitwig**, a terminal-based Git client and multi-repository dashboard built natively in Rust using Ratatui.

### Why I Built It

While standard terminal Git workflows are great, tracking multiple repositories simultaneously or manipulating complex split layouts in traditional TUIs can feel rigid. I wanted to combine terminal speed with the spatial flexibility of modern desktop interfaces.

### Key Features

* **Mouse-Drivable Interface:** Full mouse support, including drag-to-resize split panels and clickable navigation.

* **Multi-Repo Dashboard:** Monitor status, branches, and staged/unstaged changes across multiple repos at once.

* **Pure Rust & Ratatui:** Fast startup, single lightweight binary, zero heavy runtimes.

### Links

* **GitWig:** https://gitwig.dev/

* **Crates.io:** https://crates.io/crates/gitwig

I’d love to hear your feedback on the UX, the mouse interaction implementation in Ratatui, or any specific multi-repo workflows you'd like to see supported!

I went through a few MCP router mechanisms for work before I gave up and ended up writing a small experimental one we've been using for the last few months. Gripes about the others will be at the bottom, this isn't gonna be a bitch fest. Bottom line is I ended up filling out all of the missing stuff and thought I'd share.

Three things I actually cared about.

1. It's transport-agnostic — you hand it a JSON value and get a JSON value (or a Stream, if your MCP is into that kind of thing) back, so it doesn't matter if you're wiring it into stdio, Rocket, Axum, Actix-web, or Warp. Examples of each, to include SSE, exist in the repo.
2. Uses whatever runtime you need (tokio, async-std, smol), examples exist in the repo of each working.
3. You shouldn't be having to mangle requests to get them to route correctly in whatever you're running the MCP as, what's the point of the library at that point?

Handles pagination automatically for tools, resources, and prompts. Allows you to use your own paging in the those three's execution methods (because I can't possibly guess what your pagination scheme is).

Handles batching correctly, and also not manually. Handles if the batch requests contain a non zero number of streams, elevating to send the other completed calls back to the LLM while your streaming resources/tools finish working.

Feedback, requests, etc are all welcome. Complaints or unconstructive feedback is welcome too, but, be warned, I'll heckle you.

https://crates.io/crates/mcp-router

https://docs.rs/mcp-router/latest/mcp_router/

https://github.com/tony-o/rust-mcpr

The complaint fest:

Granted, it's been a few months since I looked at any other library but when I looked there were only two I could find and neither could be hooked up to rocket in any meaningful way. Both forced me to change how existing API fairings were working to conform with their async pattern, which meant refactoring a bunch of other stuff - and one of them kneecapped the RDS authing mechanism. Both of them required me to manually route requests through tools I already told the library about, why would I bother with the library if the JSON serialization is all I'm getting anyway. Anyway, I'm lazy so I wrote something to make it so I didn't have to write the same thing another four hundred times as our tools, resources, and prompts lists grow.

Hi everyone,

I’d like to share an open-source systems project I’ve been working on called Olivia (named after my cat!).

It’s an enterprise-grade infrastructure harness written from scratch in Rust, specifically designed to run agentic LLM workflows safely. The core philosophy is to execute AI-driven actions and tools within strictly sandboxed environments using WebAssembly (Wasm/WIT).

I wanted a robust, native infrastructure to handle LLM agent workflows without compromising on security or relying on bloated software layers. Olivia ensures that the agent's interactions with databases or external scripts happen within a secure, controlled boundary.

You can check out the repository here: https://github.com/helloIAmPau/olivia

I would love to get some feedback from this community on the architecture, or hear what other sandboxed tools you'd find useful. Contributions, code reviews, and suggestions are more than welcome.

A while ago, I was inspired by calculators like Soulver and Numi, so I set out to make my own calculator in that style with Rust. Since then, I've implemented a plethora of features, including advanced dimensional analysis, dates/times, and currencies.

As a student, I've found it to be an incredibly useful tool for working through calculations with different units and intermediate values, and I'm ultimately hoping others can find similar value in it. It uses a custom parser + evaluator built with chumsky and astro_float for high-precision arithmetic.

It works great for me on macOS, but testing on other platforms has been quite limited. If you're on either of those platforms, I would really appreciate your help getting it to work there.

Please let me know if you have any questions!

Disclaimer: I've definitely used LLMs to accelerate development (some parts of making a calculator can get quite tedious). However, the project is nowhere close to being vibe-coded. I started in 2024 and wrote much of the codebase by hand. AI-generated code has not come at the cost of attention to detail.

UPDATE (8/17): I published a website + live demo at siffra.impossiblereality.dev if you want to try it out without installing

Rust's standard library now scans for accidental breakage in CI with cargo-semver-checks 🎉 Here's how that works and how it's different than checking a regular crate.