Hello and welcome to another issue of This Week in Rust! Rust is a programming language empowering everyone to build reliable and efficient software. 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

Official

Project/Tooling Updates

Observations/Thoughts

Rust Walkthroughs

Miscellaneous

Crate of the Week

This week's crate is poem-openapi, a framework to implement OpenAPI services.

llogiq is very pleased with his suggestion.

Please 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.

Ockam

If you are a Rust project owner and are looking for contributors, please submit tasks here.

Updates from the Rust Project

244 pull requests were merged in the last week

Rust Compiler Performance Triage

Overall, many changes this week, but overall an improvement on multiple benchmarks over the week from a number of pull requests dedicated to optimizations of certain patterns. We are still seeing a large number of spurious changes due to rustc-perf#1105, which has yet to be addressed.

Triage done by @simulacrum. Revision range: 22c2d9d..1c028783

4 Regressions, 4 Improvements, 9 Mixed; 5 of them in rollups 41 comparisons made in total

Full report here

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 entered final comment period this week.

Tracking Issues & PRs

New RFCs

Upcoming Events

Rusty Events between 12/01-12/15 🦀

Online

North America

Europe

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

Tangram

Flaps

CoBloX

Globelise

Bionaut Labs

Massa Labs

Tweet us at @ThisWeekInRust to get your job offers listed here!

Quote of the Week

The design of the safe/unsafe split means that there is an asymmetric trust relationship between Safe and Unsafe Rust. Safe Rust inherently has to trust that any Unsafe Rust it touches has been written correctly. On the other hand, Unsafe Rust cannot trust Safe Rust without care.

As an example, Rust has the PartialOrd and Ord traits to differentiate between types which can "just" be compared, and those that provide a "total" ordering (which basically means that comparison behaves reasonably).

BTreeMap doesn't really make sense for partially-ordered types, and so it requires that its keys implement Ord . However, BTreeMap has Unsafe Rust code inside of its implementation. Because it would be unacceptable for a sloppy Ord implementation (which is Safe to write) to cause Undefined Behavior, the Unsafe code in BTreeMap must be written to be robust against Ord implementations which aren't actually total — even though that's the whole point of requiring Ord .

Gankra citing the Rustonomicon on github

Thanks to robin for the suggestion!

Please submit quotes and vote for next week!

This Week in Rust is edited by: nellshamrell, llogiq, cdmistman, ericseppanen, extrawurst, andrewpollack, U007D, kolharsam, joelmarcey, marriannegoldin.

Email list hosting is sponsored by The Rust Foundation

Discuss on r/rust