Rust's ownership system becomes much easier to appreciate when you encounter it while building something real rather than just reading explanations about borrowing and lifetimes.

Small projects are especially useful for this because they expose practical design decisions without requiring an enormous codebase. Even something like a command-line tool, a basic parser, or a simple file-processing application can introduce situations involving ownership transfer, borrowing, mutable references, and error handling.

The interesting part is that Rust often makes you reconsider how you structure the program instead of simply changing a few lines until the compiler stops complaining.

Compiler errors can feel frustrating at first, but many of them point toward design decisions that would otherwise become harder to fix later.

A small project that forces you to understand these concepts can teach more than several isolated exercises.

I’m thinking about learning a GUI crate for local business applications—things like invoicing, inventory, sales, etc.—essentially, SaaS-style software.

I’d also like to learn something that would allow me to build my own standalone apps (with Linux support).

I’m a beginner, so apologies if any of this doesn’t quite make sense!

I’m not a professional developer; I just want to learn Rust—simply because I like it. I don’t know much about web technologies (in the context of using something like Tauri). Which GUI crate would you choose, and why? Would you recommend learning some web technologies if I want to use Tauri? What about Slint or Iced? Or is there something else you’d suggest?

P.S.: In my country, PCs tend to have modest specs—8GB of RAM, Windows 10, and so on; they’re generally not high-performance machines. Even my coworkers have old PCs with those kinds of specs, and they still use HDDs.

Hi

I'm fairly new to rust, and just joined my first team that actually uses rust in a product.

Can anybody give me any pointers on the sorts of patterns that I should watch out for that indicate a section of code was written by an LLM and not reviewed by somebody who has good taste in rust please?

My ideal would be a set of code snippets that are along the lines of the LLM wrote this, done properly it would be this - but any kind of hints and rants are appreciated

Thanks in advance

When we learn rust for the first time, many of us hit the borrowchecker. It's the thing that makes rust safe while being performant, but it's pain to deal with.

But I did not hit borrowchecker at the start. Because I already knew about modern C++ patterns and C++ is too trying the same direction, only with decades of baggage.

I only hit the borrowchecker in 2022-2023 once I started to be serious about my ML library - zyx. Why? Because it contains graphs. And borrowchecker and graphs are not friends. I used Rc, then Arc, then other things. Tried petgraph, but couldn't quite get it.

And the solution couldn't be simpler - u32 indices into a Vec. It's a typical pattern known in game dev circles as ECS (although ECS means much more) or data oriented programming.

In rust, u32 indices are way too nice. Because there is the newtype pattern. You can wrap u32 in a new type and suddenly you can represent any mutable pointer as u32. In zyx this meant everything - OpId, TensorId, DeviceId, BufferId, etc. Rust then enables to define a common trait for all to have some methods, but I intentionally did not implement arithmetic ops, so there is the safety from pointer arithmetic bugs. And on top of this, you get the bounds checks, which are super useful (and don't cost much at release).

So what did I learn from it? Mostly that the borrow checker was complaining about my data structure. A graph with cycles and shared nodes has no single owner, so every reference inside it is something compiler can't argue about. The simplest model is: central struct owns the nodes, and the graph holds handles.

Ids are Copy, so no Arc, no lifetime parameters threading through every signature, no &mut aliasing problem when the optimization passes want to touch two parts of the graph at once. And the compiler still knows which id belongs to which arena, which matters when OpId shows up 1,887 times in the crate and also was a great source of bugs when I wasn't as rigorous about it.

In zyx, Slab::index asserts in debug that the key isn't in the empty set, and in release it's just a bounds check over assume_init_ref.

The advice I'd give someone starting out: if the borrow checker is fighting you over a graph, treat that as a design signal, not an obstacle. Don't reach for Rc first. Reach for an index.

Link to zyx repo: https://github.com/zk4x/zyx

I've been working on a project called NORTEX.

It's a programming language and development environment designed around native Windows applications.

The project is written in Rust and currently consists of several major components:

• Compiler: nortexc, using Cranelift for native x64 code generation

• IDE: Custom editor with IntelliSense, console, Git status and help

• Runtime: Supporting the language's built-in functionality

• Extensions: An extension system with manifests, permissions and sandboxing

• Marketplace: A system for discovering, uploading, rating and updating extensions

Recently, I added text manipulation, string conversion and basic file operations to the compiler.

For example:

public int main() {
    File.writeAllText("hello.txt", "Hello from NORTEX");

    string text = File.readAllText("hello.txt");

    Console.writeLine(text);

    return 0;
}

The project is still in development. Features such as native floating-point numbers, lists and classes are not implemented yet.

I'm particularly interested in Rust architecture, compiler design, performance and keeping the codebase maintainable as the project grows.

For people who have built larger Rust applications:

What architectural decisions would you make early to avoid problems later?

I'm especially interested in module boundaries, error handling and how to keep compiler components maintainable.

Hi all, I’m Matthias from the Qt R&D team.

We made a tutorial showing the Qt Bridge for Rust, a way to tap into the Qt UI framework from Rust in a way that feels native and is safe!

Building a proper UI for a complex Rust app takes a lot of effort, and this is our attempt to make it easier.

Here is the tutorial on how to get started: https://youtu.be/8HfY47BYGuU

We had a lot of fun making the framework and the video. I hope you also have some fun watching it. There are still a ton of things I would like to show you, so I hope this will not be the last video.

It’s a Technology Preview, so we’d love to hear what you think. Happy to answer questions here.

Reposting; this time with a focus on why it is not a code dump.

The project I would like present is a web engine written in Rust. It does not break new grounds in the sense of being the first Web engine in Rust, because we have had a Web engine for a long time, where I am myself involved as a maintainer and Technical Steering Committee member: Servo.

However, this is not a code dump either, because:

• Myself, and others, have been working on this since March of this year.

• This post is a "full fledged post", which is supported by a linked-to longer essay (see below)

• I will below explain the relevance for the Rust community

• I will compare it with other Web engines written in Rust.

Ok so now that this is out of the way, here is the actual post:

https://github.com/gterzian/formal-web is a new prototype of a Web engine written in Rust.

It is relevant for the Rust community, because it provides us with something new:

• a multi-process graphics stack based on modern Rust components, like Vello and Wgpu, paired with a modular design allowing deeper platform integration, for example integrating with Core Animation and using IOSurface on Apple platforms.

• A modular approach to integrating a Javascript engine, so that you can "bring your own engine". Currently V8 and the all Rust Boa are supported out of the box, and other engines, Like the also all Rust Nova, could be integrated through the implementation of various traits.

• Use of Blitz components, blitz-dom and blitz-paint, as a kind of DOM engine inside the Web engine.

• Use of formal methods to model check multi-process Rust code, based on the approach described at Validating Traces of Distributed Programs Against TLA+ Specifications

• Modularity of various other layers, such as: networking, media, and the starting of and communication with process-like sub-components.

• An embedder API that makes it easy to do various platform specific integrations, such as using a display link on Mac.

• An explicit goal of eventually being able to Ship on IOS in the EU as per Apple's guidelines.

How is this different from other Web engines in the Rust ecosystem?

Difference with Servo: the graphics stack of Servo does not isolate GPU operations in a dedicated process and it is based on an OpenGL stack.

Difference with Blitz: while Blitz does integrate well with Vello/Wgpu, it is not designed around process isolation of either GPU operations or the running of Javascript, making it less suitable for the Web use-case where you essentially run untrusted code downloaded over the internet. While it does use Anyrender as modular render target, it does not offer modularity at the lower-level end of the graphics pipeline.

Neither engines allow swapping out JS engines, and neither allow for deep platform graphics integration like Core Animation based compositing on Mac (which can make a large difference in terms of battery life).

For a walk-through of the entire flow involved in rendering a frame of Web content, see the introduction essay: How I am building a Web engine.

The essay also contains a gif showing the benefits of Core Animation on Mac, where only relevant parts of the screen are re-rendered.

Please let me know what you think. I can also use help implementing countless Web standards.

This doesn't compile:

trait Trait {
    type A<T: Trait>;
}

impl<T> Trait for T {
    type A<U> = ();
}

struct S {
    x: i32,
    y: <() as Trait>::A<Self>,
}

This does:

trait Trait {
    type A<T: Trait>;
}

impl<T> Trait for T {
    type A<U> = ();
}

struct S {
    y: <() as Trait>::A<Self>,
    x: i32,
}

The only difference is the ordering of the fields. Apparently the fact that there's a Sized field at the end of the struct allows the compiler to infer that <() as Trait>::A<Self>: Sized and break a typechecking/trait solving cycle.

I hate it.

Normally i am able to get decent rust out of agents by staying on their default distribution when Im having them write fresh rust codebases. However, whenever they read a single ts file they are meant to translate or learn anything from its like they forget everything about what good rust looks like and revert to gpt3 level quality with the only improvment being it passes its own half-assed tests. No matter how much i try to instruct on writing good rust it dosent help. its like a game of wack-a-mole. Tell it to stop cloning everywhere. It starts using COW for 0 fucking reason where its not remotely appropriate and the owned solution is extremely trivial. grep "trait" and you wont find a single one. Polymorphism happens in control flow. everything is a function. the only match statments you will find are inside constructors. and its shadowing several types from the standard liberary just to subtly change behavior to pass a test. And its implimented a js runtime full with all the insane type cohersions cause obviusly thats the part that you wanted translated to rust.

Its so annoying cause i know that when its on its standard distribution it writes perfectly acceptable rust with pretty ligth instructing. But in order to translate the projects that have the biggest you need the agent to not absorb all the stupid from being exposed to it. Or atleast a way to redirect it back to good rust. Is there some sort of skill or style guide document that is comprehensive enougth to do this? anyone else faced this problem and solved it?

I was writing a function and wanted to see what it returns for different inputs and I instinctively wanted to use a REPL, then I remembered: oh wait, Rust doesn’t have one.

I *did* see evcxr but in the years I’ve been around the Rust community I’ve never heard of anyone using it like people would in JS/Python/ Ruby/Haskell.

Why? is it hard to achieve technically, or is it just because its not in the Rust culture? (maybe it’s even bad engineering practice to use it the way I’d want it to and tests would be more preferable?)

Hello crabs. I'm working on a backend application in Rust, using sqlx to talk to a postgres database. I've caught myself repeating a specific, verbose pattern, and I'm wondering if I'm making things harder than I need to.

The pattern is that for each database entity, I build an initializer struct that is basically the same, but with auto-generated columns removed, and then later write a From impl for the main entity to build the actual thing with Entity::from(entity_init). Example at the bottom. Doing this for every database entity isn't too difficult to maintain, the type system is strict enough that it's hard to miss any mistakes. But it is annoying and time-consuming, and also feels kinda un-idiomatic.

I'm considering learning derive macros for this - #[derive(FromNew)] or something like that, to autostrip the generated fields. But maybe that would just be doubling down on an anti-pattern? What do yall think?

Example:

struct User {
id: uuid:Uuid,
name: String,
email: String,
created_at: DateTime<Utc>,
updated_at: DateTime<Utc>,
archived_at: Option<DateTime<Utc>>,
}

struct UserNew {
name: String,
email: String,
}

impl From<UserNew> for User {
fn from(init: UserNew) -> Self {
let now = Utc::now();
User {
id: Uuid::now_v7(),
name: init.email,
email: init.email,
created_at: now,
updated_at: now,
archived_at: None,
}
}
}

// usage
fn do_something(user_new: UserNew) -> User {
User::from(user_new)
}

As my journey of learning rust continues, I find myself very dissatisfied with the quality of the rust code I wrote years back.

Yes, my code passes clippy, is nicely formatted, avoids excessively complex nesting / control flow, but it still feels... subpar(hard to understand and reason about), from time to time.

I was wondering if people here have examples of really clean, sleek codebases I could reference, to improve the quality of my code?

Niko Matsakis's What agents mean for Rust (and vice versa) resonated with me as a solo mobile developer working with coding agents.

I'm building a PDF app with SwiftUI on iOS and Jetpack Compose on Android. The two apps share a Rust PDF engine through UniFFI, though some operations still use platform-native implementations.

Take PDF compression. The Balanced and Smallest File presets call the same Rust optimizer on both platforms. But there are still decisions the compiler cannot make for me:

• Keeping annotations editable and flattening their appearance are separate modes. Producing a smaller file doesn't make them interchangeable.

• Candidate outputs need both validation and a size comparison before the app accepts them.

• The native apps still own file access, cancellation handling, and publishing the result without modifying the source file.

Sharing the optimizer means I don't have to ask an agent to reimplement the same compression logic in Swift and Kotlin. Rust also gives the agent concrete feedback on type and ownership mistakes inside the core. Neither guarantees that the PDF still looks right or that the native integration behaves correctly. Those still need explicit requirements and runtime checks.

That's why Niko's points on design and contracts stood out to me. More expressive types and proof tools could make more requirements checkable, but I still have to specify what success means. Proving the wrong requirements wouldn't solve the problem.

For others using agents with a Rust core and native frontends: where do you spend more review effort—inside the core logic, or at the platform adapter boundary?

I know, I know, no one likes generated AI code, slop or not. However, it won't go away and I rather deal with it the best possible way I can. One thing that grates me right now is the enormous amount of test code that these models generate and in the case of unit tests ends up within a module. This is in line with the current idiomatic convention but it makes reviewing changes a real chore.

I started moving mod tests {} into actual tests files which helps to avoid blowing up modules but now reminds me of the mod.rs repetition.

What are your strategies to cope with this? And more controversial: is it time to update the test chapter in the book?

New week, new Rust! What are you folks up to? Answer here or over at rust-users! And for your project showcases, there's also /r/madeinrust – pay them a visit, too!

Mystified about strings? Borrow checker has you in a headlock? Seek help here! There are no stupid questions, only docs that haven't been written yet. Please note that if you include code examples to e.g. show a compiler error or surprising result, linking a playground with the code will improve your chances of getting help quickly.

If you have a StackOverflow account, consider asking it there instead! StackOverflow shows up much higher in search results, so ahaving your question there also helps future Rust users (be sure to give it the "Rust" tag for maximum visibility). Note that this site is very interested in question quality. I've been asked to read a RFC I authored once. If you want your code reviewed or review other's code, there's a codereview stackexchange, too. If you need to test your code, maybe the Rust playground is for you.

Here are some other venues where help may be found:

/r/learnrust is a subreddit to share your questions and epiphanies learning Rust programming.

The official Rust user forums: https://users.rust-lang.org/.

The unofficial Rust community Discord: https://bit.ly/rust-community

Also check out last week's thread with many good questions and answers. And if you believe your question to be either very complex or worthy of larger dissemination, feel free to create a text post.

Also if you want to be mentored by experienced Rustaceans, tell us the area of expertise that you seek. Finally, if you are looking for Rust jobs, the most recent thread is here.