Hello and welcome to another issue of This Week in Rust! Rust is a systems language pursuing the trifecta: safety, concurrency, and speed. This is a weekly summary of its progress and community. Want something mentioned? Tweet us at @ThisWeekInRust or send us a pull request. Want to get involved? We love contributions.
This Week in Rust is openly developed on GitHub. If you find any errors in this week's issue, please submit a PR.
Updates from Rust Community
News & Blog Posts
- Rewriting m4vgalib in Rust.
- A thought experiment: Using the ECS pattern outside of game engines.
- Spinlocks considered harmful.
- The state Of ggez, 2020.
- Interior mutability patterns.
- Should Clippy care from whence they came?
- Writing AWS Lambda functions in Rust.
- Rust lifetimes and iterators.
- Rocket and multipart forms.
- Lyon 0.15.0 - a new tessellator.
- The embedded WG's Raspberry Pi OS dev tutorials: Tutorial 13 - Kernel unit, integration, and console tests using QEMU.
- Optimising PineTime’s display driver with Rust and Mynewt.
- The embedded WG newsletter 22.
- rust-analyzer changelog 5.
- Rust in blockchain 7 – December 2019.
Crate of the Week
This week's crate is attohttpc, a tiny synchronous HTTP client library.
Thanks to Matěj Laitl for the suggestions!
Submit your suggestions and votes for next week!
Call for Participation
Always wanted to contribute to open-source projects but didn't know where to start? Every week we highlight some tasks from the Rust community for you to pick and get started!
Some of these tasks may also have mentors available, visit the task page for more information.
No issues were proposed for CfP.
If you are a Rust project owner and are looking for contributors, please submit tasks here.
Updates from Rust Core
184 pull requests were merged in the last week
- doc comments: less attribute mimicking
- require const stability attributes on intrinsics to be able to use them in constant contexts
- stabilize attribute macros on inline modules
- normalize
ident
- resolve long compile times when evaluating always valid constants
- avoid memory copy logic for zero-size types
- ensure that evaluating or validating a constant never reads from a static
- tweak errors for missing associated types and type parameters
- typeck: note other end-point when checking range pats
- refactorings to borrowck region diagnostic reporting
- various const eval and pattern matching ICE fixes
- fix ICE in mir interpretation
- allocate HIR on an arena 2/4 -- Expr & Pat
- allocate HIR on an arena 3/4 -- Ty
- initial implementation of
#![feature(bindings_after_at)]
- deprecate
Error::description
for real - add
IntoFuture
trait and support for await - do not ICE on lifetime error involving closures
- use
NonNull
inslice::
{Iter
,IterMut
} - implement padding for
IpAddr
without heap alloc - stabilize the
matches!
macro - differentiate
todo!
andunimplemented!
- fix
Instance::resolve()
incorrectly returning specialized instances - prune ill-conceived
BTreeMap::iter_mut
assertion and test its mutability - clean up const-hack PRs now that const if / match exist
- hashbrown: implement
drain_filter
forHashMap
- rustdoc: show the actual value of constant values in the documentation
Approved RFCs
Changes to Rust follow the Rust RFC (request for comments) process. These are the RFCs that were approved for implementation this week:
No RFCs were approved this week.
Final Comment Period
Every week the team announces the 'final comment period' for RFCs and key PRs which are reaching a decision. Express your opinions now.
RFCs
No RFCs are currently in final comment period.
Tracking Issues & PRs
No RFCs are currently in final comment period.
New RFCs
Upcoming Events
Asia Pacific
Europe
- Jan 8. Berlin, DE - OpenTechSchool Berlin - Rust Hack and Learn.
- Jan 9. Lisbon, PT - Rust Lisbon - Live Jan 2020.
- Jan 10. Darmstadt, DE - Rust Rhein-Main - 1st 2020 Rhein-Main Rust Meetup.
- Jan 16. Turin, IT - Mozilla Torino - Gruppo di studio Rust.
- Jan 22. Wrocław, PL - Rust Wrocław Meetup #16.
- Jan 23. Warsaw, PL - Rust Warsaw 3.
North America
- Jan 6. Houston, TX, US - Houston Linux Users Group - Rust Study Group.
- Jan 7. Denver, CO, US - Rust Boulder/Denver - Rust Meetup: January.
- Jan 8. Atlanta, GA, US - Grab a beer with fellow Rustaceans.
- Jan 8. Vancouver, BC, CA - Vancouver Rust meetup.
- Jan 8. Portland, OR, US - PDXRust - C-Side Tourism: Using C libraries from Rust.
- Jan 9. Columbus, OH, US - Columbus Rust Society - Monthly Meeting.
- Jan 9. San Diego, CA, US - San Diego Rust January 2020 Meetup.
- Jan 9. Lehi, UT, US - Utah Rust - January 2020 Regular Meetup.
- Jan 9. Arlington, VA, US - Rust DC — Mid-month Rustful.
- Jan 14. Seattle, WA, US - Seattle Rust Meetup - Physical Computing Workshop.
South America
If you are running a Rust event please add it to the calendar to get it mentioned here. Please remember to add a link to the event too. Email the Rust Community Team for access.
Rust Jobs
Tweet us at @ThisWeekInRust to get your job offers listed here!
Quote of the Week
Rust has multiple unique paradigms that don't even exist in other languages, such as lifetimes and compile-time-tracked "exclusive access". But instead of endorsing them from the beginning, as @mbrubeck's Rust: a unique perspective does, the Rust book tries to show a language that is "like other languages, but with (magical) compile-time checks". When the truth is that Rust's strength lies in non-
unsafe
Rust being less expressive than languages like C or C++.I think that Rust should start with the statement: "Welcome to a language that by being less expressive forces you to use constructs that are guaranteed at compile-time to be sound. But don't worry; after some time you will get used to the coding patterns that are allowed, and will then almost not notice the hindered expressiveness, only the enhanced zero-cost safety that will let you hack without fear."
- It doesn't sound bad imho, and is at least honest w.r.t. the struggles that someone refusing to shift their way of coding / mental coding patterns may encounter.
Thanks to Tom Phinney for the suggestion!
Please submit quotes and vote for next week!