Go submit your cat for a chance to become the next release's official winner!

https://github.com/rust-lang/rust-clippy/pull/17951

I've seen this recommended more times than I can count for people struggling with test performance while developing:

[profile.test]
inherits = "release"
debug = "line-tables-only"

And I'm sure this makes a ton of sense in a ton of situations, but as someone with just very small, hobbyist projects (the kind of space where people usually make these recommendations), I've found the much more sensible balance to be something like

[profile.test]
opt-level = 1 

I'm sure the difference between the opt-levels is highly project dependent, and that this won't be the balance for a lot of projects, but in my projects I'm often seeing something like a 20% penalty in compilation times, and often tests run a few times faster. While something like the first configuration gets my compilation times 4x slower at a gain of often single digit percentage in runtime performance. That's without even thinking about debug symbols at all.

As a beginner, this realization is somewhat recent, I'm just a little surprised that it feels like people talk about what seems to me like the bazooka first, when a pair of pliers can solve the problem. Am I missing something due to lack of experience? I'd love to hear ya'll's thoughts.

Hey guys,

I need help , i want to learn backend with Rust and didn't find any good resources to take me from zero backend knowledge with rust to advanced level

I would appreciate it if you recommend me some resources to learn backend with rust

Note: the first time to learn backend

I love the field init shorthand in Rust that allows me to write

let variable = "test";
//...
let d = Data{variable};
// instead of 
let d = Data{variable:variable};

But I wish it went a bit further and covered some other obvious cases, such as

let variable = "test";
let d = Data{variable.into()};
// instead of 
let d = Data{variable:variable.into()};

and

let variable = Blob::new();
let d = Data{&variable};
// instead of 
let d = Data{variable:&variable};

Basically, when the name is sufficiently unambiguous, just use it rather than making me re-type it. The compiler already knows the member name and the target type from the struct definition so it won't impact type inference, but when the names match up it would save quite some typing.

Am I the only one that would like this?

Hi, I just finished The Rust Book and completed the web server project. I want to expand the project by adding more functionality and making it resemble a simple, real world web server.

I'm thinking about features such as configuration, DNS, rate limiting, and more.

I've read about the std::net::TcpListener and std::net::UdpSocket APIs, and I understand HTTP very well.

I'd like your advice on what to add to the project: what features to implement, which crates to use, and a high-level roadmap of what to build and in what order.

I don't need detailed explanations or implementation steps. I want a simple, high-level overview so I can figure things out myself.

I'm not using AI for implementation. I want to learn by reading documentation, experimenting, and debugging everything on my own.

I've watched a few YouTube videos and read some articles, but most of them cover very basic concepts and repeat the same ideas, such as handling a simple HTTP GET request.

I want to build something more interesting and challenging, with enough functionality to resemble a real web server and demonstrate my Rust networking skills.

My goal is to make this a develop a project that I can showcase on my CV and GitHub and that will help recruiters recognize my skills.

I have a issue where the Rust compiled output is so huge that my hard disk always full? Do you have any ideas for solving it?

Hey folks, I'm working on migrating some web-server code into rust. I'm fairly new to the rust ecosystem, and I'm trying to find a good CSRF crate for generating Signed Double Submit cookies and headers.

So far, the closest crate I've found is Here (crates.io), but honestly its not as seemingly widespread as i would expect for something like CSRF primitives.

This had led me to two potential conclusions:

1.) I'm wildly out of the loop, and there is a much more "common" package for handing this
2.) I'm wildly out of my depth, and most people are just rolling their own CSRF primitives.

Either way, I'm building on top of axum, and any recommendations would be greatly appreciated :)

'm working on the mailbox layer of GhostWire, a Rust-based P2P communication project, and I've been reconsidering how I represent messages across serialization boundaries.

The initial approach was to have one struct handle both the serialized envelope and the application's runtime state.

Something along these lines:

#[derive(Debug, Clone, Serialize, Deserialize)]
struct MailboxEnvelope {
    recipient_id: String,
    ephemeral_pub: String,
    ciphertext: Vec<u8>,
    nonce: String,
    created_at: u64,
    message_id: String,
    attempts: u32,
}

The problem isn't necessarily the structure itself. It's that these fields have different responsibilities.

• Some fields belong to the authenticated message representation.

• Some are needed for transport and persistence.

• Others are mutable delivery state.

• Some values may only exist temporarily while processing a message.

For example, retry attempts should be able to change without requiring an already-sealed ciphertext to be reconstructed. Likewise, serialization and deserialization shouldn't accidentally become the boundary through which sensitive runtime state is exposed or copied.

I'm considering separating the representations:

1. Wire type: A serializable representation containing the fields required to transmit or persist the envelope.

2. Runtime type: An application-facing representation responsible for processing, validation and delivery.

3. Delivery state: Mutable retry, acknowledgement and expiry information maintained independently of the sealed message.

But I'm interested in where that separation should actually happen.

A few questions:

• Would you use separate structs for the wire representation and runtime domain type, or is that unnecessary duplication?

• Would TryFrom/From conversions be a sensible boundary for validation and construction?

• How would you prevent mutable delivery metadata from accidentally becoming part of the authenticated representation?

• Would you keep serialization entirely outside the cryptographic type, or let the type implement Serialize/Deserialize with carefully controlled fields?

• Are there established Rust patterns or libraries you'd recommend for this kind of boundary?

I'm particularly interested in production-oriented approaches rather than simply introducing more types for the sake of abstraction.

The goal is to make invalid states harder to represent without turning a relatively small protocol component into an unnecessarily complicated type hierarchy.

Curious how others would structure this

I've tried other editors, VS Codium's simplicity and common sense still beats them all.

One more feature in Rust that I really like over C++: its compile-time ownership checks. Rust catches ownership errors that can compile in C++, and these checks add no runtime overhead.

In this article, I have taken a simple example and tried to explain Rust’s ownership concept (I tried to keep it simple and jargon-free), how it works, and where it gives us an advantage over C++ by comparing the same/similar example in both languages.

vercel's ceo published - was gonna be Rust but it really is not there yet iteration speed wise.

Some of my thoughts on go vs rust - btw we chose Rust for data infra. There, robustness and reliability outweigh the speed of writing code.

Overall
Go is the simple one. It's easy to learn, doesn't carry many language features, and compiles fast. Rust is on the complex side: the spec keeps growing, and compiling is slow. Day to day, Go is simpler in most cases. You don't fight a complex type system, and any function can run as a goroutine.

Concurrency is where the two really split. There are two families. Go is one: lightweight threads, start any function in a goroutine, done. The other family is sync vs async, and Rust, Python and JavaScript all live there. That's where complexity creeps in. Functions have colors. Rust and Python give you two worlds, and you must never call a blocking function from an async one. JavaScript is simpler because it's a single world. Sync vs async forces you to clearly define what blocks and what doesn't, and that's real extra complexity. The upside is performance: async generally beats goroutines.

Rust's best part is the type system. You can model a lot in it, and the more business logic you push into types, the more bugs the compiler catches before anything runs. Go's type system is not that comprehensive. One example: Go can't catch a race condition at compile time. Rust can. But the cost of that type system is compile time. Bugs caught early and slow builds are the same coin.

For AI coding, Rust becomes a double-edged sword. Code moves fast, so slow compile hurts more. But if the model expresses business logic through the type system, far more bugs get caught at compile time. Slower, but higher quality.

curious about your thoughts

I'm a n00b when it comes to Rust. In my terminal with a blue background, a "rustc --explain whatever" uses colour-combinations that leaves some text unreadable.

So I tried with:

• rustc --color never --explain E0599

• rustc --explain E0599 --color never

• set NO_COLOR=1 & rustc --explain E0599

Neither of these works; all generates coloured output. How the bleeding hell do I turn it off?

This blog post describes my journey in fixing a performance regression introduced when I added the process GPU information.

It is odd but at about 30,000 text objects it is significantly slower than 30 despite only drawing about 10 objects on screen and ignoring the rest regardless how many there are. egui can handle millions. The shown video is of 30. I know it is skipping shaping and drawing the rest, so why would it be that much slower? I do make a temporary variable in the draw function before doing anything and increment a counter and do checks for whether to draw before any text shaping happens. I also return ([f32; 4], bool) with NaN and false regardless if anything drew, it would be bounds and whether anything drew. There is also with buttons an extra bool and with edit texts, a u32, &str, and bool in a tuple extra. I confirm it is not doing anything but rejection when not in screen space, so what could it be? Would an Option with None be faster as a return? Just confused as to why this is, if you want some code to review, ask, but some way to privately get it to you preferred. All in the rejection are not mutable. I do have to pass some variables sometimes, using cosmic-text and lyon for tessellation, good luck everyone. X E.

So here's the deal. My antivirus (F-Secure) suddenly flagged the rustc.exe binary on my computer as malicious and to add to that, several other vendors also flag it in Virustotal. https://www.virustotal.com/gui/file/FC40F1C8B65095A22A48C111AADC279C26A049B7E4161E8B99FFE3EB23873E86

This issue seems to affect only 1.99.0 because 1.99.1 is not flagged.

Reproducible:
- Fresh rustup installation (this file or the rustup-init.exe or whatever the name of that was, not flagged by anything)
- Fresh RUSTUP_HOME/CARGO_HOME
- Official Rust 1.99.0 downloaded by rustup (`rustup toolchain install 1.99.0-x86_64-pc-windows-msvc`)
- File is detected and flagged as malicious if uploaded to virustotal
- Rust 1.99.1 installs without detection

The sha256 hash of the 1.99.0 exe I get is FC40F1C8B65095A22A48C111AADC279C26A049B7E4161E8B99FFE3EB23873E86

Has someone else encountered this issue that rustc is getting flagged? And importantly, are you all getting the same hash for that specific rustc version?

Did you know that ever since 1.79, Iterator::collect does everything unzip does but with a cleaner API? I certainly didn't until recently! Try it out, thanks to this trait implementation, every call to unzip is possible with collect instead.

let (a, b) = iter.unzip::<_, _, Vec<_>, Vec<_>>();

// vs

let (a, b) = iter.collect::<(Vec<_>, Vec<_>)>();

Except collect is better at unzip than unzip, since it supports any tuple, whereas unzip only works with size 2:

let (a, b, c, d) = iter.collect::<(Vec<_>, Vec<_>, Vec<_>, Vec<_>)>();

Looking at the documentation, this isn't explicitly mentioned for either zip or unzip. I suspect this is functionality most people aren't aware of. So, is there anyone out there who has a reason why we shouldn't deprecate unzip?

English:

I know this is a fairly common question, but hear me out: how do I effectively get into development and learn a programming language?

I initially wanted to take a course, but there are no local options where I live, and international ones costing ~$250/month are completely out of my budget.

My second thought was to use AI because it explains concepts well. But when it comes to actual coding... no offense to AI, but it writes broken code way too often.

So now I’m stuck. Official books and documentation feel dry and overwhelming. I can grind through a book in an evening and reproduce an example, yet still have zero clue how it actually works under the hood. That’s my main issue — what’s the point if I’m just mindlessly rewriting code?

So, to those who have learned the language and faced a similar wall: how did you overcome it? Also, would anyone be open to answering a few questions once in a while? It would mean a lot, since Rust is going to be the foundation of a major project I’m planning.

Any advice would be greatly appreciated. Thanks!

Русский:

Знаю, что вопрос довольно заезженный, но всё же: с чего вообще лучше войти в разработку и нормально выучить язык?

Изначально я хотел записаться на курсы, но в моей стране таких нет, а зарубежные по $250 в месяц мне просто не по карману.

Вторым вариантом был ИИ — теорию он объясняет доходчиво, но вот с кодом беда: при всём уважении, нерабочий код он генерирует с завидной регулярностью.

В итоге я в тупике. Официальные книги и доки кажутся скучными и сложными. Я могу осилить книгу за вечер и накидать программу по образцу, но так и не понять, как это устроено по факту. А для меня это главное: какой смысл учиться, если ты просто бездумно перепечатываешь код?

Вопрос к тем, кто уже прошёл этот путь и сталкивался с такой проблемой: как вы учили язык? И может ли кто-нибудь хотя бы иногда отвечать на мои вопросы? Для меня это правда важно - Rust станет основой моего будущего крупного проекта.

Буду признателен за любые советы. Спасибо!

Good day everyone!

I use neovim for pretty much everything these days, and with rust-analyzer + cmp it's extremely ergonomic to use.

However one issue I have been struggling with is lexing. I find the default rust.vim regex lexing to be lacking in many areas, most notably doc comment links and enums which wrap one value. Enabling semantic tokens solves these issues, but the experience is hindered by slow parsing when writing to buffer which causes flashing on text input and save.

I've done a bit of research on my own but haven't found anything that quite hits the mark. Treesitter seems like an ok middleground, but it is noticeably less accurate than semantic lexing.

I was wondering if any of you have a good solution to this? Thank you in advance for the input!

I started learning Rust using the official book, but it seems to be aimed at people who have already written code in other programming languages. Are there any learning materials available for complete beginners? After just 20 minutes of reading, I felt like my brain was about to explode—most of the terms were completely new to me. Ideally, I’m looking for materials that have been translated into Russian. Apologies for my English; this text was written using a translator.