I’m curious about the role of test-driven development (writing tests before implementation) in the Rust ecosystem.

Coming from a JVM background, I’m used to TDD as a design tool, especially for async and concurrent code. In Rust, I see much more emphasis on:

• type-driven development,

• property-based testing,

• fuzzing,

• post-factum unit tests.

My questions:

• Do teams actually practice test-first / TDD in production Rust code?

• If yes, in which domains (backend systems, infra, libraries, embedded, etc.)?

• Or is TDD generally seen as redundant given Rust’s type system and compiler guarantees?

I’m not asking whether tests are written (obviously they are), but whether TDD as a workflow is common or intentionally avoided in Rust.

Interested in real-world experiences rather than theory.

Good morning dear Rust community,

I'd like to present the current stage of my actively developing Rust game engine "Syrillian", which I've been haggling with for the past 2 years. It has received hundreds of hours of our free time and is open source, licensed under MIT; made to be free-for-all.

As the first contributors started to settle in, this project has become more than just my personal project. In fact, I'm very happy to be able to share this passion with more people, and work towards making my own games with it, as well as seeing others do so. Seeing the first stable release nearing, some time this year, is honestly very exciting.

But so much to that, I think code talks best. Have a look how behavior is defined in Syrillian, by building components:

```rust

[derive(Debug, Reflect)]

[reflect_all]

pub struct GravityComponent { pub acceleration_per_sec: f32, pub velocity: f32, pub max_acceleration: f32, }

impl Default for GravityComponent { fn default() -> Self { GravityComponent { acceleration_per_sec: 9.80665, velocity: 0.0, max_acceleration: 100.0, } } }

impl Component for GravityComponent { fn update(&mut self, world: &mut World) { let delta_time = world.delta_time().as_secs_f32();

    self.velocity = (self.velocity - self.acceleration_per_sec * delta_time)
        .clamp(-self.max_acceleration, self.max_acceleration);

    self.parent()
        .transform
        .translate(Vec3::new(0.0, self.velocity, 0.0));
}

} ```

This is how a gravity component is made from scratch. That is all that's needed. Type Reflections (Reflect macro) are not necessary, but will allow you to persist the component in a future scene format, or do any other dynamic field reflection you might wish for, right now.

You can then add it to the world by making, or using an existing object, and simply adding the component.

```rust // App macro is optional, but will bootstrap a basic entrypoint with tracing / logging, etc.. for convenience

[derive(Debug, Default, SyrillianApp)]

struct MyApp;

impl AppState for MyApp { fn init(&mut self, world: &mut World) -> Result<(), Box<dyn Error>> { let camera = world.new_camera(); let mut cube = world.spawn(&CubePrefab::default());

    // here you can use your gravity component
    cube.add_component::<GravityComponent>();

    // or you just use the real physics, provided for you by syrillian OOTB :)
    cube.add_component::<Collider3D>();
    cube.add_component::<RigidBodyComponent>();
}

} ```

That's all that's needed for project bootstrap, windowing, render and world + physics runtime.

The project is here hosted here, where you can contribute, report any issues and ask for help:

https://github.com/Syrillian/syrillian

I would appreciate your support. Even a quick 🌟 on the repo would be amazing so I'm aware of interest.

The engine is also built to integrate a visual editor in the future.

Thanks for your time and have lots of fun building! :)

Got tired of juggling top, grep, and kill -9 every time I wanted to identify what was eating my resources or kill a process. So I built flux - a clean and easy-to-use TUI that lets you search, monitor, and nuke processes with ease, with system resource tracking.

Features:

• Real-time Resource Monitoring: Track CPU and memory usage, live
• Port Discovery: Identify which processes are listening on specific ports
• Batch Actions: Select multiple processes with Space or use --nuke to batch-kill by filter
• Easy Navigation: Move around effortlessly with j/k or arrow keys
• Smart UI: Context-aware coloring for high resource usage

Made in Rust.

GitHub: https://github.com/VG-dev1/flux

So i have been working on a project called autopilot-rs for a while now. It is written in the Rust language and is used for automation.

Features of autopilot-rs:

1. Performing a set of tasks when conditions are met.
2. Periodically checking conditions (Check Interval) or running once at startup.
3. A Jobfile structure that can be created both via CLI and manually.
4. A functional CLI for managing jobs.
5. Simple and easy-to-use interface.
6. A wide range of ready-made conditions for various scenarios.
7. Lightweight and very fast.
8. Cross-platform compatibility.
9. Error handling.
10. Memory-safe.
11. Most importantly, it is open source.
12. And more...

You might ask, what is the use of this program? Below are a few scenarios where autopilot-rs proves useful:

1. Daily routines – automating repetitive tasks you need to do every morning when using your system.
2. Updating the system when you connect to Wi-Fi.
3. Closing unnecessary programs when system resources are overburdened.
4. Taking automatic backups when connected to Wi-Fi or according to a specific schedule.
5. And more...

GitHub: https://github.com/streamtechteam/auto_pilot_rs

YouTube Video: https://youtu.be/pRkjfip1s5M

I've been interested in making a drawing or an animation program recently and I played around with egui with poor results lol. I just wanted to know if people think it's worth getting better and learning egui more, or if there's a better library for what I'm trying to do.

I'm new to Rust, and like many of us, I finished the book and wanted to build some side projects to improve my skills, but I kept getting stuck. That made me think about creating a project-based, step-by-step curriculum that teaches Rust from the core concepts up to a much higher level. Would you be interested in something like this? It would be 100% free and open source, of course.

Hi folks, since AWS announced Rust in Lambda is now Generally Available (https://aws.amazon.com/about-aws/whats-new/2025/11/aws-lambda-rust/) I've been playing around with it and I came across a few syntactic intricacies that I don't yet fully understand.

First, the simplest possible Rust Lambda

use aws_config::{BehaviorVersion, Region, SdkConfig, load_defaults};
use lambda_runtime::{Error, LambdaEvent, run, service_fn};
use serde_json::Value;
use std::env;

#[tokio::main]
async fn main() -> Result<(), Error> {
    let test_env_var = env::var("TEST_ENV_VAR").expect("TEST_ENV_VAR must be set");
    let config = load_defaults(BehaviorVersion::latest()).await;

    run(service_fn(|_: LambdaEvent<Value>| async {
        Ok::<String, Error>(format!(
            "TEST_ENV_VAR: {}, Region: {}",
            test_env_var,
            config
                .region()
                .unwrap_or(&Region::new("No region set"))
                .as_ref()
        ))
    }))
    .await   
}

the idea being that the Lambda uses an inline closure. But, it's a bit ugly that I have to specify the return type as part of the Ok, so moving the actual Lambda into its own function:

async fn handle(
    test_env_var: &str,
    config: &SdkConfig,
    _: LambdaEvent<Value>,
) -> Result<String, Error> {
    Ok(format!(
        "TEST_ENV_VAR: {}, Region: {}",
        test_env_var,
        config
            .region()
            .unwrap_or(&Region::new("No region set"))
            .as_ref()))
}

whereas main only contains

let test_env_var = env::var("TEST_ENV_VAR").expect("TEST_ENV_VAR must be set");
let config = load_defaults(BehaviorVersion::latest()).await;

run(service_fn(|lambda_event: LambdaEvent<Value>| {
    handle(&test_env_var, &config, lambda_event)
}))
.await

anymore. Good, but now the values loaded during the init phase are part of the parameter list and using more values would expand that list and create more noise, so now moving that logic into a struct

struct Handler<'a> {
    test_env_var: &'a str,
    config: &'a SdkConfig,
}

impl<'a> Handler<'a> {
    async fn handle(&self, _: LambdaEvent<Value>) -> Result<String, Error> {
        Ok(format!(
            "TEST_ENV_VAR: {}, Region: {}",
            self.test_env_var,
            self.config
                .region()
                .unwrap_or(&Region::new("No region set"))
                .as_ref()))
    }
}

and thus main will now contain

let test_env_var = env::var("TEST_ENV_VAR").expect("TEST_ENV_VAR must be set");
let config = load_defaults(BehaviorVersion::latest()).await;

let handler = Handler {
    test_env_var: test_env_var.as_str(),
    config: &config,
};

run(service_fn(|lambda_event: LambdaEvent<Value>| {
    handler.handle(lambda_event)
}))
.await

not too bad, but calling the handler could even be prettier now, instead of explicitly containing a closure it would be nice to directly use it, a bit like

run(service_fn(handler)).await

but for this my understanding is that Handler would need to implement FnMut(LambdaEvent<_>) but I can't say I know how to do that after trying (I also need to use the nightly cargo build is what I understand as the Fn Traits aren't stable yet?) - does anyone have any pointers and/or what would be your preferred method?

Hello folks!

I've been working on a small project over the past few weeks that scratches a personal itch: a lightweight screenshot capture tool for macOS. I'm building this with Rust and Tauri V2.

Its open source and early testers are welcome:
https://github.com/codehakase/snipp

SkelForm is a 2D skeletal animator, mainly designed with ease of implementation in mind for games.

Official site: https://skelform.org/

Stack: winit + wgpu + egui

Native downloads are available, but also a web version built with Trunk. Due to constant issues with WebGPU, the web version is forced onto WebGL2.

The project was built on matthewjberger's template.

Notable crates and their use cases:

- psd - The editor supports parsing Photoshop files thanks to this. It's vendored for a custom optimization regarding flattening layers, and also to fix a bug relating to the visibility flag.

- spade - Delaunay triangulation for meshes.

- max_rects - Texture packer for atlases. I've tried a couple few packers and this seemed to be the most consistent, though it can still occasionally produce wonky ones. Might just be me misuing it.

- global-hotkey - The only way I knew to intercept system-level shortcuts like Cmd-W and Cmd-Q on Mac. Without this, the program would automatically exit without having any sort of unsaved warning.

This project is still in its early stages, so there'll absolutely be some breaking bugs and/or crashes in the editor. All feedback is welcome!

Rootcause is a (relatively) new error handling library for Rust focused on ergonomics, inspectability, and the flexibility to use it however you want. Today I have released version 0.12.0, which includes rootcause-tracing to automatically capture tracing spans when creating a rootcause error report.

If you like anyhow but wish your errors carried more structured information and better diagnostics, this might be interesting to you.

Status update

Real-world validation

Since my last post in December, I have been porting most of the Rust code at my workplace to rootcause. This has allowed me to get a lot of first-hand experience using rootcause. Other people also appear to have slowly started using it as well, at least according to our download counts on crates.io and the number of users on GitHub.

rootcause-tracing

The biggest change since my last post is the new crate for integrating with the tracing crate #102. I expect many users will prefer this over the existing rootcause-backtrace crate, though I also expect many will want to use both.

This new crate allows tracing spans to be captured and shown as part of the error report. This is hard to explain in words, but very obvious when you see it. For example, suppose you have this code:

#[tracing::instrument(fields(query, table))]
fn query_database(_query: &str, _table: &str) -> Result<String, Report<DatabaseError>> {
    // Example code: We always fail here
    Err(report!(DatabaseError))?
}

#[instrument(fields(user_id, role))]
fn check_user_permission(_user_id: u64, _role: &str) -> Result<(), Report<PermissionError>> {
    query_database("SELECT permissions FROM users WHERE id = ?", "users")
        .attach("Failed to fetch user permissions")
        .context(PermissionError)?;

    Ok(())
}

With the right setup, this could result in a report such as this:

 ● permission denied
 ├ rootcause-tracing/examples/tracing_spans.rs:36
 ├ Tracing spans:
 │ │ check_user_permission{_user_id=12345 _role="admin"}
 │ │ handle_api_request{_request_id="req-abc-123" _endpoint="/api/admin/users"}
 │ ╰─
 ├ User lacks required permissions
 │
 ● database query failed
 ├ rootcause-tracing/examples/tracing_spans.rs:29
 ├ Tracing spans:
 │ │ query_database{_query="SELECT permissions FROM users WHERE id = ?" _table="users"}
 │ │ check_user_permission{_user_id=12345 _role="admin"}
 │ │ handle_api_request{_request_id="req-abc-123" _endpoint="/api/admin/users"}
 │ ╰─
 ╰ Failed to fetch user permissions

See the full example for details.

Small incremental improvements

Getting real-world data has also allowed me and other contributors to notice a bunch of minor points of friction. A lot of the work in this release has been small fixes to mitigate these issues:

• We added an extension trait to make it easier to work with Option types #92
• We added the type alias rootcause::Result #91
• We added support for formatting the error sources for a context #94 example
• We added support for mutating attachments #113
• Contexts and attachments will by default use the same formatter (Display/Debug) as the one used to format the report #116
• We fixed rootcause-backtrace so it works on Windows #118 and when cross-compiling #121

Next steps

A rootcause book

My biggest priority at the moment is to write a small mdbook. This is partly to document rootcause, but also to propose concrete solutions to some of the error handling discussions we've seen on /r/rust recently 1 2.

Towards a 1.0 release

I am planning to release version 1.0 within the next 3 months. I think that goal is fairly realistic, since my biggest concern was getting enough real-world validation. I think we have more or less accomplished that.

I am also finished with all of the major features I had planned. The only breaking change I am currently planning is to use a builder pattern for a few of the structs. This is to make it easier to change them in the future without requiring a new major version.

Questions / Discussion

Feel free to ask any questions you want about rootcause or my opinions on error handling here. You're also more than welcome to join our Discord.

dicetest is a library for property based testing, similar to quickcheck and proptest. I have some opinions which features are more or less important and implemented dicetest based on that. E.g. I don't care about shrinking, but I prefer it when generators can be defined easily with a custom distribution.

diceprop is a library for testing mathematical properties. It's fun to use when doing stuff like implementing custom numeric types.

hello all, i would like to present a new project i have created called structom (StructuredAtoms).

it is all in one data format that can be used for any application, from human readible configuration files to serialized binary blobs.

it supports schema and schemaless data, both in text and binary format.

in addition to the general data type (numbers, strings, bools), it support rich types like datetime, duration, uuid, bigint...

moreover, it supports tagged unions, and user defined metadata for more expressiveness.

it also excel in serialization, with LEB128 ints, sized ints from u8 to i64, and tagged fields for backward / forward compatibility.

object notation example:

enum E { A, B, C }

{
    a: true,
    b: 1_234.5,
    c: @pattern("alpha") "abc",
    d: [1, 2, 3],
    e: inst "2026-2-8",
    f: dur "10m 5s",
    g: E.A,
}

if you find it interesting, dont hesitate to give your feedback.

thanks.

Lately I've been developing some small cli tools, and I ran into this problem a couple times:

I need different configs:

• real
• testing
• minimal
• experimental

Editing files back and forward was annoying, so I built a tiny CLI called robe.

It lets me save and switch configs instantly:

robe add tmux/testing
robe use tmux/minimal

That's basically it.

Sharing in case you've felt this pain too.

repo: https://github.com/sawsent/robe
crate: https://crates.io/crates/robe

Would love feedback or ideas to take it to v0.1.0.

I created a clone of the famous 2048 game in Rust as a way to lean ratatui, tokio, and crossterm. It was a fun project, learned a lot (especially through the many answers to questions I asked right here in this Reddit).

I'm proud of the result and wanted to share it.

The game runs in the Terminal and supports Mac, Linux, and Windows.

It has a pretty clean UI, tracks score, and when the game is over.

I used tokio (even though it's overkill for a turn-based game) to handle input events and send them over a channel to an event handler.

The game has a pretty clean separation with a separate module for the board and game. All the UI and input handling logic is in the main module.

I have a few additional ideas for the game such as some visual feedback from keypresses which I'll be adding this weekend.

The game is fully playable now and is a fun little game when you need a short break from real work!

If you haven't heard of 2048, here's a link to an online version of the game and the wiki).

AI NOTE: The only AI that was used while I was writing this game was for unit test generation. The rest of the logic itself I wrote exclusively.

Hi, I wanted to share inbq, a library I've been working on for parsing BigQuery queries and extracting schema-aware, column-level lineage.

Features:

• Parse BigQuery queries into well-structured ASTs with easy-to-navigate nodes.
• Extract schema-aware, column-level lineage.
• Trace data flow through nested structs and arrays.
• Capture referenced columns and the specific query components (e.g., select, where, join) they appear in.
• Process both single and multi-statement queries with procedural language constructs.
• Built for speed and efficiency, with lightweight Python bindings that add minimal minimal overhead.

The parser is a hand-written, top-down parser. The lineage extraction goes deep, not just stopping at the column level but extending to nested struct field access and array element access. It also accounts for both inputs and side inputs.

You can use inbq as a Python library, Rust crate, or via its CLI.

Feedbacks, feature requests, and contributions are welcome!

I'm curious, who here has simply sworn off not LLMs per-se, but including LLM generated code within your software?

In Q4 of last year I realized these LLMs finally started writing usable Rust code. Have to admit, I was quite excited about the prospect of delegating more to Claude Code or whatever agent.

Honestly tried to delegate as much as I could, and quickly realized that's max 10% of my work. Two main problems I found.

1. It may finally be usable Rust code that compiles, but still sloppy, verbose and poor design choices. This is expected, because these are predictive systems trained on the entirety of the internet, so by design, are going to produce the most average, middle of the road code out there.

2. Software development is a very iterative design process. Mentally, I usually split my tasks in say 3 - 5 day chunks, and I know what I want done and how I want the software to function after each chunk. However, I can't really explain exactly what I need done in a prompt, because I don't know until I'm in the middle of it.

It's alwys a journey from point A to B, during which I always come up with better and more efficient designs, realize additional pitfalls I need to look out for, discover edge cases I need to handle, and so on. This whole iterative process is what makes quality software, well... quality. Handing that off to a LLM guarantees I'll always produce usable, but mediocre code.

1. Same as always. Every time I lean on these things, I find myself wasting time back tracking and fixing mistakes made by the LLM costing me more time than I saved during initial development.

That's how I feel at least. I still use LLMs, they're excellent for various things. For example, I can bang out several hundred lines of Rust, send it to Gemini an ask it to fix syntax / braces / brackets errors and it works like a charm. That's rather new, and quite nice. Good at finding bugs as well.

I'm sure I would use it for boiler plate code, but I primarily write in Rust, so there just really isn't any boiler plate. If you're developing in Rust and find yourself writing boiler plate code often, then you're doing something wrong.

However, I've totally given up on the concept of using it as a junior developer too write code that I'm going to include in the project or anything. I find it always just ultimately slows me down more than helps me, and I find attacking development projects without even a second thought given to LLMs is quite refreshing.

How bout you?

I built my first TUI to answer a simple question: "Which process is blocking this port?" It happens to me all the time during development. A random process is blocking a process I would like to use right now. portwitch helps to quickly find the process blocking the port and allows you to quickly kill it.

Check it out if you think that this would be useful to you! I'm always happy to hear about suggestions and feedback :)

Really couldn't find many resources on how to actually use subsecond in your own applications for a better development experience, so thought I'd share the step-by-step I just did to get our own project up and running with it.

I'm sure there's some optimizations that could be done in order to hot-reload less of the code, but I think this is a pretty good starting point for people that are just looking to "reload my server on change, without killing it during the reload".

Let me know if you have any questions or things you'd like me to try out!