In this first episode of the Rust Compile time series, Brian Anderson, one of Rust's original authors, shares with you his researches and experiences with Rust compile times, using the TiKV project as a case study.
I thought this might interest some people here: Lean (a theorem prover in C++) uses something like Arc for its garbage collection in the purely functional language it implements, and with some tricks (basically make_mut)…
Lately there has been considerable drama around Actix-web, for which I’ll point to Steve Klabnik’s A sad day for Rust to explain. This post is an opportunity to share some thoughts I’ve had about soundness, Rust, and open source community.
actix-web is dead. This situation is bad, from all sides. When Rust was a tiny, tiny community, I thought to myself, “wow, I wonder how long this will last? Probably 1.0 will kill it.” Sort of playing off of Eternal September, I assumed that over... | Steve Klabnik | “The most violent element in society is ignorance.” - Emma Goldman
This is my second post exploring the internals of tokio. You can find the first here. As a refresher the last article had two open questions at its core: How many outstanding requests can we stack up inside of tokio: Is there a finite queue somewhere or what?How does
My $dayjob is working in the cozy realms of Java, coddled by a GC and the amenities of a fat runtime. Common wisdom is to use a GC if you can afford it. I sometimes even write python if performance is a non-issue. Why would I then long for Rust every now and then?
This is a followup to the previous post about spinlocks. The gist of the previous post was that spinlocks has some pretty bad worst-case behaviors, and, for that reason, one shouldn’t blindly use a spinlock if using a sleeping mutex or avoiding blocking altogether is cumbersome.
2019 was a great year for clippy. It’s available on stable, even installed by default in the Rust distribution and selectable as a rustup component. We have more than 300 lints, and the upwards trend is unbroken. The lints that we have also see a steady stream of improvements.
reqwest v0.10 reqwest is a higher-level HTTP client for Rust. Let me introduce you the v0.10 release that adds async/await support! Some headline features are: • Add std::future::Future support (hello...
Rusts type system requires that there only ever is one mutable reference to a value or one or more shared references. What happens when you need multiple references to some value, but also need to mutate through them? We use a trick called interor mutability: to the outside world you act like a value is immutable so multiple references are allowed. But internally the type is actually mutable.
All types that provide interior mutability have an UnsafeCell at their core. UnsafeCell is the only primitive that allows multiple mutable pointers to its interior, without violating aliasing rules. The only way to use it safely is to only mutate the wrapped value when there are no other readers. No, the garantee has to be even stronger: we can not mutate it and can not create a mutable reference to the wrapped value while there are shared references to its value.
Both the book and the std::cell module give a good alternative explanation of interor mutability.
What are some patterns that have been developed to use interior mutability safely?
How do multithreaded synchronization primitives that provide interior mutability follow similar principles?
I would like to understand how Tokio works. My interests run to the real-time and concurrent side of things but I don't know much about Tokio itself. Before the introduction of async and stable futures I more or less intentionally avoided learning it, not out of any sense that Tokio
I think about failure a lot. Why do things go wrong and what can we do about it? Professionally I’m a software engineer, presently the Infrastructure Lead for Goodwater Capital. How does software fail and what can we do about it? How do human processes fail and what can
Hyperbola is an OS project aiming for maximum freedom in the ‘free software’ sense. They’ve apparently been around for two years, although I’ve only j…
It's that time of year again and we've got a small gift for all y'all for the holidays! The parallel compiler working group has implemented a plan for you to test out a build of rustc which has far more parallelism than …
We recently landed two PRs which together reformatted essentially all code in the compiler tree.
The first one, #65939, contained the initial formatting infrastructure. We currently use rustfmt directly, pinned to a version specified in src/stage0.txt. We expect to update it as needed, and otherwise once per cycle (coinciding with the bootstrap bump, most likely).
The second one which reformatted the majority of the codebase is #67540.
This change landed with the following rustfmt config. Note that this this configuration is subject to change (in particular, merge_derives may be removed in the future), but should be fairly stable. Your editor should automatically pick this configuration up inside the rust-lang/rust repository (it is located in the rustfmt.toml file in the root).
In our last post about Async Rust we looked at Futures concurrency, and before that we looked at Rust streams. In this post we bring the two together, and will take a closer look at concurrency with Rust streams.
Over in the top and flop topic, people have brought up error handling as both a pro and a con. So I wondered if people would be willing to go into more depth here.
I could be wrong but I think that most people like the …
We are excited to announce Thomas de Zeeuw as the new lead of Mio. Mio is the low level I/O portability abstraction that backs Tokio and other Rust projects. Thomas has been behind most of the Mio 0.7 effort and will be continuing to lead the crate to 1.0. He has written the rest of the announcement.
Good evening all! The parallel rustc working group (you can find us on Zulip!) has been developing and working on a parallel compiler for quite some time now, and we're getting very close to shipping! What we'd like to d…
The release of Tokio 0.2 was the culmination of a great deal of hard work from numerous contributors, and has brought several significant improvements to Tokio. Using std::future and async/await makes writing async code using Tokio much more ergonomic, and a new scheduler implementation makes Tokio 0.2’s thread pool as much as 10x faster. However, updating existing Tokio 0.1 projects to use 0.2 and std::future poses some new challenges. Therefore, we’re very excited to announce the release of the tokio-compat crate to help ease this transition, by providing a runtime compatible with both Tokio 0.1 and Tokio 0.2 futures.
LRtDW is a series of articles putting Rust features in context for low-level C programmers who maybe don't have a formal CS background — the sort of people who work on firmware, game engines, OS kernels, and the like. Basically, people like me.
async-std is a mature and stable port of the Rust standard library to its new async/await world, designed to make async programming easy, efficient, worry- and error-free.
We announced async-std on August 16th - exactly 4 month ago. Our focus for the initial release was providing a stable and reliable API for users to build async applications on, modelled after Rust standard library. It came with a number of innovative implementations: The first implementation of a JoinHandle based task API and single-allocation tasks.