Google just published its Rust style guide, which it says is developed in consultation with Android, Chromium, Fuchsia and Chrome. Most of it is uncontroversial, but a few rules go against what most of the ecosystem does:

• Flat file layout. Crates live in a single directory with no subdirectories. If you feel the need to organise a crate into folders, Google says that's a sign the crate is too big and should be split.

• No glob imports, except for merging C++ namespaces.

• Avoid Rc and Arc. Prefer unique ownership and borrowing. Google explicitly says engineers coming from other languages reach for shared ownership too quickly.

• No async/.await in Chromium, and don't start threads through std.

• Avoid panics, prefer expect over unwrap to document the invariant, and never use catch_unwind.

• Library vs application code. API design rules are binding for libraries but only a strong recommendation for apps, where simplicity should win over reusability.

• Don't use traits to organise code. Traits are for generics, impl Trait/dyn Trait, and extension traits.

The stated reason for the deviations is Large-Scale Changes. Google wants code that tooling can refactor across the entire codebase, which explains the flat layout and the anti-glob-import stance more than readability does.

Update

Forgot to attach the link https://google.github.io/styleguide/rustguide.html

After finishing the Rust Book + 100 exercises, I built mal-cli: → A TUI client for MAL (search, profile, details...) → Uses threads + channels for event loop → UI with Ratatui

Learned a lot — feedback appreciated! Repo: https://github.com/L4z3x/mal-cli

Hey everyone! 👋
I'm Thomas, a Rust developer, and I’ve been working on a project I’m really excited to share: a new version of chess-tui, a terminal-based chess client written in Rust that lets you play real chess games against Lichess opponents right from your terminal.

Would love to have your feedbacks on that project !

Project link: https://github.com/thomas-mauran/chess-tui

I have been programming for 30 years. I know C, Haskell, Java, Kotlin, Swift, Python, APL. I have always had fun programming. Every language I have learned and used was an exciting experience. It has always been fun to learn new ways of thinking for approaching and solving problems. Each one gave a different and interesting perspective and set of challenges ....but they were all FUN.

Haskell was probably one of the more difficult experiences I had. I basically had to re-learn how to think and its type system can be a pain. Virtually none of the previous programming skills I had translated to Haskell. But, the difficulty paid off and I was able to take concepts I learned back to other languages.

When I decided to learn Rust, I had the same initial excitement of learning something new that I had when learning past languages. I read the Rust book and it all seemed to make sense.

The next obvious step was to make something in Rust. This is when everything turned from excitement to an absolute nightmare. Battle after battle after battle. Fighting with the Haskell type system was never anywhere nearly this difficult. I pushed through it and pushed through it and pushed through it. Making effort to learn something, after 30 years of programming, is not a new experience for me by any means.

I have reached my breaking point. This has been the worst experience learning a programming language that I have ever had by far. I found absolutely no joy in it in any shape or form. Every single step on the path was full of absolute frustration and misery. This has nearly killed my desire to program.

I've been trying to learn Rust recently, and I come from know mostly Java. For that reason, I've been messing around with writing the same programs in both languages to try to test myself.

Today I was curious and decided to see how much faster Rust was than Java, but, to my surprise, the Rust program runs significantly slower than the Java one. Did I write my Rust code inefficiently somehow? Could it be something to do with my IDE?

Info

Rust Playground

Rust Code

use std::time::Instant;

fn main() {
    let start_time = Instant::now();

    const MULT: usize = 38;
    for i in (MULT..10e8 as usize).step_by(MULT) {
        println!("{i}");
    }

    println!("Time taken to run the program: {} seconds", start_time.elapsed().as_secs());
}

Java Code

public class Main {
    public static void main(String[] args) {
        long startTime = System.nanoTime();

        final int MULT = 38;
        for (int i = 38; i < 10e8; i += MULT) {
            System.out.println(i);
        }

        System.out.printf(
                "Time taken to run the program: %.0f seconds",
                (System.nanoTime() - startTime) / Math.pow(10, 9)
        );
    }
}

Seriously, I would pay for this if I had to.

https://www.youtube.com/channel/UCmBgC0JN41HjyjAXfkdkp-Q/videos

I always believed learning from books/tutorials is better than learning from videos but learning Rust via traditional routes was slightly challenging. Because Rust does a lot of things that make a lot of sense later on but to a beginner the question of "why?!" can become overwhelming. Traditional learning sources have a hard time context-switching between why and how all the time, something a video can do with a lot more ease.

Doug's channel is one of the best on YouTube for tech learning. Luckily for us he is focusing on Rust! He has pretty much covered most of the primitives and is uploading new content all the time. Please do check it out and subscribe.

DISCLAIMER: No, I have never interacted with Doug in any capacity. I just found his videos to be super helpful hence the fanboy-ish tone.

It's definitely the opposite of idiomatic, but it seems like it might be the safer and stable solution in that situation.

Motivation: As part of my program I need a way for users to precisely model the data they want me to reflect, bit fields and all. Since I have yet to encounter a model/SDL that fits the bill I resorted to plain C files.

So, I'm trying to reflect C types loaded from header files at runtime. I need something similar to mod ir from rust's bindgen crate... Which is not pub unfortunately since it's not the intended use case of bindgen. Even so, I assume that backdooring an official a rust crate would probably be more stable and easier to maintain than hand rolling a bastardized version of my own.

I'm trying to implement in rust a system that behaves like JS Promises and the single threaded event loop, but allowing for scheduling tasks from other threads.

I started this as one-off experiment but liked how it turned out, what you guys think?

(see code)

Try it: https://8gwifi.org/code-playground/

Hi everyone,

I am Bibek Bhusal and I am learning rust, I have been working on this project in rust for last week and wanted to share with the community. It's a simple pomodoro timer with stats, history, streak, waybar integration, and many more features.

This is my first big project, after building todolist and other small projects.

I would love to hear your feedback. here is the link for repo: https://github.com/BibekBhusal0/focusd

Even the default Rust logo would be better

My new book Learn Rust Programming Today has been published a few weeks ago. It is intended for software developers who already know how to program, and want to learn Rust. You can see the outline of the book and some sample content on the book's home page at Learn Rust Programming Today.

Most programming books will present you with isolated examples of language syntax, leaving you to complete the picture yourself when you actually need to get stuff done. Learn Rust Programming Today takes you on a complete journey from the start to the finished program that you can use, learning the necessary features of Rust on the way. It doesn't replace "The Book", but rather complements it.

During the course of the book you will build Today, a Rust command-line application that shows things that happened on this day in history (historical events, births of notable people, and so on) from various sources. You will also extend the program to handle days that are observed annually, such as Pi Day, and recurring events. You will also be able to add your own events.

The book examples are available at https://github.com/coniferprod/learn-rust
The Today program has its own repo: https://github.com/coniferprod/today-rs

You can ask any questions about the book in this thread, and I'll do my best to answer them.

To help people to get the best out of the code examples in my book (Manning), I have just written a summary of all of the various tools and configuration steps needed to do some embedded Rust development.

This include setting up cross-compiling targets, Arm embedded tool-chain, QEMU, gdb-multiarch, OpenOCD, probe-rs, st-link tools, serial communication tools, PICSimLab, and all that jazz. This setup can be use as a base for any embedded Rust development although currently its assuming that you are using a Cortex-M based MCU and Ubuntu as an OS. I hope this might help some of you getting started.

https://github.com/dcabanis/Embedded-Software-With-Rust-Book/blob/main/embedded-rust-ubuntu-setup.md

Hope You'll like it😊❤️

I started with the normal book, then moved to the Brown version. The Brown book is hard to read but worth it, despair and all.

The main reason it's hard, I think, is that it doesn't spend enough time on memory architecture. Once you understand the lower-level details of how memory is laid out, the concepts in the Brown book become far more intuitive.

One thing that threw me: most memory diagrams draw the stack growing upward, but the Brown book draws stack frames going downward. Turns out the downward direction is how most modern architectures work. The stack grows toward lower addresses. The name "stack" comes from the LIFO data structure and the mental model borrows from that, but the growth direction in practice is the opposite of the plates-stacking-up picture most people start with.

It all clicked once I got curious about these details. A couple of YouTube videos also gave me a much more intuitive way to think about data in Rust.

Here's the path I'd recommend for anyone learning ownership:

1. Read the original book first on ownership.

2. Watch this video on memory architecture: https://www.youtube.com/watch?v=_8-ht2AKyH4. The key idea is that in other languages you manage memory yourself, whereas Rust's ownership system does it for you. Supplement with this video I got from the CS50x Harvard, Memory lecture... video on pointers: https://www.youtube.com/watch?v=5VnDaHBi8dM. Worth working through that course too.

3. Read how the architecture works in practice: https://www.geeksforgeeks.org/c/memory-layout-of-c-program/

4. Then, finally, read the Brown EDU book on ownership. Get a cold wet towel ready for your head!

5. Then watch this: https://www.youtube.com/watch?v=fugcSHD-9Jw&t=317s ("The Only Diagram You Need to Understand Rust Ownership"). This is the one that ties it all together.

Do all that and ownership, lifetimes, and the rest should be a lot less painful to wrap your head around. The final video especially.

I have a small personal project, an Python web app with about 100 unique visitors per month. I use as playground, from time to time I rewrite in different frameworks and databases. Recently it was running on FastAPI, which is considered the faster async web framework for python.

Recently I've decided to rewrite in Rust. Used Axum. I took a lot of punches from the borrow checker but it was not as bad as I was expecting. It was harder get used to think in the good with strong typing.

My app on python was running at 70MB of ram when idle and around 100~150MB during usage. With Rust the idle consumption fell to only 4MB and usage fell to 10MB. I was not expecting improvements like that.

Super exciting. The next step is replacing the background worker of this app, which is taking approx. 15min to run, curious how fast I will be able to get out of.

Trying to start a thread on the little novice habits we all picked up early in Rust and what the cleaner version looks like once it clicks. Not talking about huge architecture stuff, just the small everyday patterns that quietly get better as you go.

I'll throw out a couple to get it going:

1. Cloning to dodge the borrow checker → just borrow

Reaching for .clone() the second the borrow checker complains:

fn process(data: Vec<u8>) -> usize {
    data.len()
}

let data = vec![1, 2, 3];
let len = process(data.clone()); // clone so we can still use data after
println!("still have {} bytes", data.len());

Take a slice instead and the clone disappears:

fn process(data: &[u8]) -> usize {
    data.len()
}

let data = vec![1, 2, 3];
let len = process(&data);
println!("still have {} bytes", data.len());

2. Rigid param types → flexible impl Into<String>

Taking String forces the caller to allocate up front, and taking &str just pushes the .to_string() inside so you allocate even when they already handed you an owned String:

struct User {
    name: String,
}

impl User {
    fn new(name: String) -> Self {
        User { name }
    }
}

User::new("scadoshi".to_string()); // caller has to build the String themselves

impl Into<String> lets them pass whichever they've got, and only allocates when it actually has to:

impl User {
    fn new(name: impl Into<String>) -> Self {
        User { name: name.into() }
    }
}

User::new("scadoshi");               // &str works
User::new(String::from("scadoshi")); // owned String moves straight in, no extra copy

What are yours?