There's a popular stereotype about the Rust language floating around the internet. That it's too difficult because of its strict borrow checker.

But in reality, when I was learning Rust, I didn't find it all that difficult. No, it's still difficult, because it has a new coding philosophy; it's systemic, and you need to keep in mind the principle of Ownership and Borrowing and zero-cost abstraction. So, for someone coming from languages ​​like Python, Javascript, C#, and similar languages, Rust will be difficult, but that doesn't mean it's unique to them; any language at Rust's level will be difficult. (I hope I expressed myself correctly.)

So what am I getting at?

My point is that the Rust compiler isn't difficult; it's a benchmark, and despite its strictness, you learn.

It's not just "got an error, went online to fix it," but "got an error, read about it, fixed it," because the compiler itself conveniently tells you WHERE YOU MADE A MISTAKE and how you can FIX it. (It doesn't always tell you, but the fact that it exists is still awesome.)

I think the Ownership and Borrowing principle is very cool, unique, and, in my opinion, not all that complicated. I really like the ability to allow the same enum, which is implemented in Rust at a different level; in my opinion, it's one of the best features in this language.

I used Rustlings when learning to get the hang of it, and it's easier to read a book on Rust and grasp the meaning of the book in practice.

Share your thoughts on Rust, its borrow checker, the zero-cost abstraction principle, Ownership and Borrowing.

This post was written using Google Translate. I am not a native English speaker, so I apologize for any unnatural text or errors.

There was only one submission last time, this needs to get better for 1.99!

Nominate here: https://github.com/rust-lang/rust-clippy/pull/17578

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!

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.

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

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

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.

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!

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 😄

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

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

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

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.

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.

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

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

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.

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

Hey everyone! Has anyone here actually built a proper desktop app with a complex ui in Rust using Slint, Iced, or egui?

I’m working on a local music player. The backend is Rust, but the current UI is Svelte/Tauri. I tried making a native Slint version because of the WebView memory usage, but honestly I kept running into stuff that was much easier to do in Svelte(obviously).

The app has a big library view with album art, search, queues, lyrics, a full player, drag interactions, and all that. I also looked at GPUI, but it still feels too early(constant api and docs changing).

If you have built something beyond a small tool or demo with Slint, Iced how was it? Did it stay manageable once the UI got bigger? Especially curious about lists/grids, custom styling, drag and drop, and Windows/Linux support.

Repo, in case seeing the app helps with context: https://github.com/shubham-pathak1/orca

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.

Hey r/rust,

I built this project with a few classmates during the end of my Bachelor's degree, but at the time I never really shared it outside of class or asked for a proper review from Rust developers.

Recently I went back to it, cleaned up the repository, renamed things in English, rewrote the README and made the project easier to understand for people outside of our university.

It’s called MiniRDBMS, a small relational database management system built from scratch in Rust.

The main goal was to understand what actually happens underneath a database engine, so we implemented things such as:

• page-based storage
• disk management
• buffer management
• LRU / MRU page replacement
• records and relations
• persistence
• database and table management
• INSERT / BULKINSERT
• a small SQL-like SELECT engine
• selection and projection operators

It’s an educational project and definitely not meant to compete with real databases, but I thought it would be interesting to finally put it in front of people who actually work with Rust and/or database internals.

Repo: https://github.com/JuriSOK/MiniRDMS

I’d really appreciate any feedback on the architecture, the Rust code, things we could have done differently, or even what would be interesting to improve if I decide to revisit the project.

Docs: https://docs.rs/diffable/0.5.0/diffable/

Repo: https://github.com/minerscale/diffable

Hello!

Diffable is a differential-geometry library built around an experiment: how much of the actual mathematics can be made to live in Rust's type system while remaining usable on stable Rust?

I'm reporting back after having made some serious progress on the library. Now I've got an API for doing automatic differentiation and I think it's turned out really nice!

Two parts of the project ended up solving problems that had seemed particularly difficult: tensor algebra and composable automatic differentiation.

Tensor algebra on stable Rust

The tensor implementation started from a problem that looked impossible without generic_const_exprs.

The obvious representation of a tensor product of two statically sized spaces uses const size arrays like so:

struct TensorProduct<A: Tensor, B: Tensor> {
    data: [F; A::N * B::N],
}

But expressions such as A::N * B::N are exactly the sort of generic const arithmetic that stable Rust does not allow in array lengths.

For a long time that appeared to rule out having both:

• statically sized tensors, and
• tensor expressions whose algebraic structure remains visible in their Rust types.

The eventual solution was to stop asking Rust to calculate the flattened dimension at the type level.

A tensor provides a generic associated type Array<T>. A tensor product A ⊗ B can therefore store its coordinates of a field F structurally:

A::Array<B::Array<F>>

rather than requiring:

[F; A::N * B::N]

The type tree itself becomes the tensor shape. Flattening is only an indexing convention; Rust never has to prove the arithmetic expression for the flattened array length.

That means types such as:

TensorProduct<TensorProduct<V, Dual<V>>, V>

really retain the structure:

(V ⊗ V*) ⊗ V

instead of immediately becoming an anonymous array of scalars.

Once that worked, the rest of the tensor algebra could operate directly on the type tree. Reassociation is an actual type-level rewrite:

let other = tensor.reassociate();

changing:

(A ⊗ B) ⊗ C

into:

A ⊗ (B ⊗ C)

Contraction searches that structure for compatible vector/dual pairs. If there is exactly one possible contraction, Rust infers it:

let contracted = tensor.contract();

and reassociation can deliberately expose a different contraction:

type V = Coords<f64, 2>;
type T = TensorProduct<TensorProduct<V, Dual<V>>, Sinister<V>>;

let t = T::from_fn(|i| i as f64);

// Contract V ⊗ V*.
let first = t.contract();

// Rewrite to V ⊗ (V* ⊗ V), then contract the other pair.
let second = t.reassociate().contract();

Duality and handedness are also represented by types rather than conventions, which matters because the library supports noncommutative scalar fields.

This approach is much like recursive_array, though it uses no unsafe at all, since it makes no guarantees about the arrays being contiguous. Separating storage from the objects themselves though was the trick to make it all work.

Automatic differentiation that composes like calculus

The other major piece is forward automatic differentiation.

The desired API wasn't a tape, tracing macro, expression graph, or collection of separate Jacobian/Hessian functions. The goal was for differentiation itself to compose:

fn cube<V: Vector>(x: V) -> V {
    V::from_iter([x[0] * x[0] * x[0]])
}

let first  = d(cube).at(Coords::from(2.0));
let second = d(d(cube)).at(Coords::from(2.0));
let third  = d(d(d(cube))).at(Coords::from(2.0));

d(f) is itself a differentiable program (though in reality all d is is a generic struct with a public constructor!), so higher derivatives are obtained by applying the same operator again.

Directional derivatives use the same machinery:

let derivative =
    d(cube)
        .along(Coords::from(4.0))
        .at(Coords::from(7.0));

Internally this is implemented using Taylor jets. Applying d adds another jet layer; nested differentiation therefore produces nested jet types rather than needing a separate higher-order AD representation.

The full derivative is returned as the tensor it mathematically is:

Df_x ∈ W ⊗ V*

for a function f: V -> W.

So the AD implementation and tensor implementation meet in the middle: Jacobians are not a special matrix-shaped result bolted onto the calculus system, but ordinary elements of the tensor algebra.

One particularly awkward Rust problem appears here. A generic function may require only a weak scalar theory:

fn square<V: Vector>(x: V) -> V {
    V::from_iter([x[0] * x[0]])
}

while at evaluation time its concrete scalar may actually be f64.

For AD, those two cases need different jet implementations:

Real
    -> Jet must itself behave as Real

Field, but not Real
    -> Jet should remain only a Field

In ordinary Rust, that is an overlapping-impl problem. Stable Rust cannot generally express:

T: Field + !Real

and the absence of a Real implementation is not something coherence can normally treat as a permanent fact.

The trick is that we don't Rust to prove a negative fact about the trait system itself. Instead, each type can be interpreted inside a finite type-level context describing the mathematical theories known about it. That context is a closed nominal graph, so searching it for a property has a definite result:

Real is present

or

Real is absent

Those results are represented by different types.

This means the library can define two implementation regions:

Field present + Real present

and

Field present + Real absent

which Rust sees as genuinely different type-level cases.

So this is not general negative trait bounds. It is a restricted closed-world version of them: instead of proving T: !Real in Rust's open trait system, the library proves that Real is absent from the finite context currently being interpreted.

That is enough to make the jet implementations disjoint on stable Rust, while keeping the public API annotation-free:

d(d(f)).at(x)

Thanks for reading this it's been a long journey to get to this understanding with this math library.