Empowering everyone to build reliable and efficient software.

The Rust Programming Language Blog offers insights, updates, and tutorials on the Rust programming language, focusing on its safety, performance, and concurrency features. Developers can learn about Rust language syntax, ownership model, and memory management, as well as explore advanced topics such as async programming and unsafe Rust. Additionally, the blog highlights community contributions, Rust ecosystem libraries, and upcoming language features, providing resources for Rust developers.

Rust

Rust users consistently cite reliability, efficiency, low-level control, supportive tooling, and extensibility as key strengths. The language's real power comes from achieving all these attributes simultaneously, creating a trusted, versatile tool that empowers developers to tackle new domains and problems they couldn't approach before. However, balance is crucial: complex type systems, async Rust's steep learning curve, and crates.io's overwhelming choice can undermine supportiveness. The Rust team recommends enumerating design goals, doubling down on extensibility (especially for diagnostics and build integration), and helping users navigate the ecosystem.

What do people love about Rust?

Each piece is necessary for the whole to work

The result: Rust as a gateway into new domains

I like the community and it’s mindset around it. As a counter-example, the community around C is extremely old and stuck in the 90s or even 80s. They don’t want to understand UX. They don’t want to understand humans. They just see bits and bytes as the ultimate truth, forgetting, that programming languages are specifically made for humans, since as robots, we could’ve written anything in ones and zeros to begin with.
The Rust community is highly knowledgeable and educated. Yet, they know, humans have to use the language, to create product for humans. C programmers create programs like a computer, to be run (not used!) by a computer, rather than humans.

Love its promises. It has amazing guarantees (that it enforces correctly 99% of the time). But the language itself (what I have to read and write) is a friggin’ eyesore – It’s a sea of sigils – Specially on bigger projects where people go nuts defining types to represent every step of the journey for any piece of data. It guarantees type contracts aren’t broken though… at the cost of time-consuming refactors and on-boarding.
<code>async</code> was a mistake that we all though was a great idea, imho. The <code>Pin</code> trait has its own special behavior even though you write it like any other type.
I don’t want to touch another line of Rust if I can avoid it despite the compiler being amazing (and still slow) and the resources out there being good and getting better.
I commented this on other similar posts: I never learned so much on other languages than with Rust, then I took those lessons to other languages I enjoy. I also tend to trust programs written in Rust more, not because the authors might be good programmers, but the language guarantees that help authors write fewer bugs.

<blockquote>
async Rust’s steep learning curve
</blockquote>
Automatic async is a mistake in any language, with the possible exception of Go. If you need to wait on an external API, for example, loading a file, waiting for a network download, checking for new game controllers, or etc; spin off each task to a threadpool. This is better because you manually control program flow, and also this is what automatic async does, only it hides the details from you by putting on a trenchcoat and pretending it’s an entirely new paradigm to your code. Automatic async is also infectious, in that the “easiest” way to implement automatic async is to make your whole code async (the red thread/blue thread problem).
Manual async, meanwhile, is what people did for at least a decade before the automatic async infection started.

definitely not the borrow checker XD

this is honestly why I wanna learn Rust! the mix of reliability, performance, and great tooling just sounds awesome.