If you are interested in becoming lead maintainer of TWiR, please fill this form:

https://docs.google.com/forms/d/e/1FAIpQLScJUYdkpLwQc_4zn3oxpVLdT3IHtKlYEBAzd6lgSgE3vsTOtA/viewform

I'm retiring from TWiR and TWiR is looking for a new lead maintainer. If you're interested and/or if you've questions, please respond below. If you'd like to contact me privately, please use the email on my GitHub profile.

My weekly routine:

(On average I spend about 4-6 hours/week on TWiR).

• Scout through reddit for posts to add in "News & Blog Posts" section (this is usually what takes majority of the time).
• Merge recently opened PRs.
• Go through Twitter mentions and add content if requested.
• Check email for any direct emails (search for rust and twir).
• Check reddit inbox.
• Fill-in other sections, e.g., RFC and calendar. (I could and should have automated it to some extent, but it is one of those things that I kept deferring to this weekend, and 5 years later, here we are).
• Generate the static pages using pelican --delete-output-directory content.
• Run the web-server locally and verify contents. (cd output; python3 -m http.server).
• Copy static pages to the GitHub Pages repository (rsync -razvP --delete --exclude /CNAME --exclude /.git output/ /path/to/this-week-in-rust.github.io/).
• Commit and push GitHub Pages repo.
• Publish to both reddit and Twitter. (I'll give access to the Twitter account).
• Create draft article for next week.
• Add reddit link in the footer of current post.
• Commit and push.
• Wait for about 24 hours (in case community finds any issue in the post).
• Send the newsletter through Mailchimp. (I'll give access to Mailchimp).
  • TWIR_NEWSLETTER_THEME=1 pelican --delete-output-directory content to generate HTML.
  • Start the server (cd output; python3 -m http.server) and copy HTML to /tmp/in.html.
  • Generate email-friendly HTML (juice --web-resources-images false /tmp/in.html /tmp/out.html).
  • Create a new campaign in Mailchimp, copy the HTML, and send the newsletter.

Design inspired and stolen from blog.rust-lang.org and rust-lang.org. Currently in draft status. Few issues still need to be resolved like handheld device compatibility, subscription form submission etc. Submitting the PR for early-stage feedback. This change also introduces one new dependency - https://github.com/miracle2k/webassets (which in turn requires that sass is present in PATH).

Following on from @nasa42's comment on #1003, this adds a Contributing Content section to the README to help give us guidelines on how to review contributions.

Previous conversation from https://github.com/cmr/this-week-in-rust/pull/1003#issuecomment-534965457:

Most of the PRs are about adding articles to "News & Blog Posts" section, and a review to determine if the article is worth including to newsletter or not would be quite helpful. Though I need to come up with some rough guidelines first to help determine that.

Some times it can be a challenge to get testers for an RFC implementation to get the feedback to know if its ready for stablization (see Mechanism for beta testing unstable features).

What if we had a new section "Acceptance Testing" where we queued up RFCs that are are at stage of needing general feedback, either as part of an intermediate design milestone (e.g. https://github.com/rust-lang/rfcs/pull/3243#) or in prep for stablization (e.g. https://github.com/rust-lang/cargo/issues/8415#issuecomment-1112618913)? They'd need to link out to a test plan (defining what you are looking, link to how to use the feature, link to how to use it with nightly, where to apply feedback, etc).

This week's Crate of the Week is preferences which does the right thing to your program's preferences on all common operating systems.

Interesting PRs:

https://github.com/rust-lang/rust/pull/32055 no more private imports in rustdoc https://github.com/rust-lang/rust/pull/32039 rustc will catch missing fields in pattern matches again https://github.com/rust-lang/rust/pull/32032 regression fix for LLVM type errors with bools https://github.com/rust-lang/rust/pull/32012 Vecs and VecDeques now drop faster ;-) https://github.com/rust-lang/rust/pull/32007 compiletest gets some more capabilities https://github.com/rust-lang/rust/pull/31999 slice.as_ptr generates simpler LLVM IR https://github.com/rust-lang/rust/pull/31996 libc update https://github.com/rust-lang/rust/pull/31989 Patterns can now be pointers-to-pointers to str with different lifetimes https://github.com/rust-lang/rust/pull/31985 libstd can now be compiled with emscripten https://github.com/rust-lang/rust/pull/31962 One less internal compiler error with trait consts https://github.com/rust-lang/rust/pull/31945 implement RFC 1461 https://github.com/rust-lang/rust/pull/31928 Stabilized APIs for 1.8 https://github.com/rust-lang/rust/pull/31937 Positional fields are now named starting from "0", "1", .. https://github.com/rust-lang/rust/pull/31797 vec![..] no longer copies from the stack https://github.com/rust-lang/rust/pull/31430 zeroing on drop https://github.com/rust-lang/rust/pull/31335 AsciiExt::in_ascii_{lower, upper}case https://github.com/rust-lang/rust/pull/30884 Implement inclusive ranges

This is a first draft, for review/comments/etc. Fixes #2378.

This script checks for malformed and duplicated links. The goal would be to run it in CI to save the editors from the job of noticing that a link isn't formatted correctly, or was submitted multiple times.

Some notes:

• I wasn't sure where in the tree to put this new python script. For the moment, I just created a subdirectory tools.
• The general strategy is to use the python markdown module to format each .md file, and then use bs4 to parse the resulting html and extract links.
• Some parts of the document always contain duplicate links, so right now the script also parses html heading tags and only scans the links within specific "sections". This is a little fragile because it requires the list in this script to match what's actually in the issues. Alternatively, it could have a list of URLs that are always ignored?
• Sometimes identical links don't look identical because they have tracking metadata attached (e.g. ?utm_source=reddit, etc.) so I strip those. That's also a little fragile, and requires an allowlist of sites that need http parameters (e.g. youtube). Maybe this was a dumb idea to begin with, and it would have been simpler to just leave the links alone.
• At present it will report issues on all inspected files. If we don't want to go back in time and fix those issues, we may need some date-threshold that allows errors in old files to not be reported.

For anyone who's curious how often duplicate links occur, here is the output of the script against the last 40 issues:

possible duplicate link adventures.michaelfbryan.com/posts/ffi-safe-polymorphism-in-rust/ in file content/2020-12-16-this-week-in-rust.md (also found in content/2020-12-16-this-week-in-rust.md
possible duplicate link www.abetterinternet.org/post/memory-safe-tls-apache/ in file content/2021-02-10-this-week-in-rust.md (also found in content/2021-02-03-this-week-in-rust.md
possible duplicate link blog.logrocket.com/macros-in-rust-a-tutorial-with-examples/ in file content/2021-02-24-this-week-in-rust.md (also found in content/2021-02-03-this-week-in-rust.md
possible duplicate link blog.stephenmarz.com/2021/02/22/writing-pong-in-rust/ in file content/2021-03-17-this-week-in-rust.md (also found in content/2021-03-10-this-week-in-rust.md
possible duplicate link jduchniewicz.com/posts/2021/02/c-to-rust-or-how-to-render-your-mindset/ in file content/2021-03-17-this-week-in-rust.md (also found in content/2021-03-03-this-week-in-rust.md
possible duplicate link youtube.com/playlist?list=PLfllocyHVgsRwLkTAhG0E-2QxCf-ozBkk in file content/2021-04-07-this-week-in-rust.md (also found in content/2021-02-24-this-week-in-rust.md
possible duplicate link blog.jetbrains.com/rust/2021/04/08/intellij-rust-updates-for-2021-1/ in file content/2021-04-14-this-week-in-rust.md (also found in content/2021-04-07-this-week-in-rust.md
possible duplicate link blainehansen.me/post/red-blue-functions-are-actually-good/ in file content/2021-04-28-this-week-in-rust.md (also found in content/2021-04-21-this-week-in-rust.md
possible duplicate link ferrous-systems.com/blog/gdb-and-defmt/ in file content/2021-05-05-this-week-in-rust.md (also found in content/2021-05-05-this-week-in-rust.md
possible duplicate link blog.knoldus.com/why-rust-for-embedded-development/ in file content/2021-05-19-this-week-in-rust.md (also found in content/2021-05-12-this-week-in-rust.md
possible duplicate link youtu.be/Ys7ma3au5m0 in file content/2021-05-19-this-week-in-rust.md (also found in content/2021-05-12-this-week-in-rust.md
possible duplicate link redpoll.ai/blog/imm-with-rv-12/ in file content/2021-05-26-this-week-in-rust.md (also found in content/2021-05-19-this-week-in-rust.md
possible duplicate link plume.benboeckel.net/~/JustAnotherBlog/designing-rust-bindings-for-rest-ap-is in file content/2021-06-09-this-week-in-rust.md (also found in content/2021-06-02-this-week-in-rust.md
possible duplicate link adventures.michaelfbryan.com/posts/deserializing-binary-data-files/ in file content/2021-06-30-this-week-in-rust.md (also found in content/2021-06-23-this-week-in-rust.md
possible duplicate link www.cmyr.net/blog/keypaths.html in file content/2021-06-30-this-week-in-rust.md (also found in content/2021-06-23-this-week-in-rust.md
possible duplicate link oswalt.dev/2021/06/polymorphism-in-rust/ in file content/2021-06-30-this-week-in-rust.md (also found in content/2021-06-23-this-week-in-rust.md
possible duplicate link cprimozic.net/blog/speeding-up-webcola-with-webassembly/ in file content/2021-07-07-this-week-in-rust.md (also found in content/2021-06-16-this-week-in-rust.md
possible duplicate link jbarszczewski.com/rust-tauri-svelte-tutorial in file content/2021-07-21-this-week-in-rust.md (also found in content/2021-07-14-this-week-in-rust.md
possible duplicate link dev.to/mapoulos/rust-first-thoughts-7l0 in file content/2021-08-04-this-week-in-rust.md (also found in content/2021-07-28-this-week-in-rust.md
possible duplicate link blog.jetbrains.com/rust/2021/08/04/what-s-new-in-intellij-rust-for-the-2021-2-release-cycle/ in file content/2021-08-10-this-week-in-rust.md (also found in content/2021-08-04-this-week-in-rust.md
possible duplicate link blog.guillaume-gomez.fr/articles/2021-07-29+Interacting+with+data+from+FFI+in+Rust in file content/2021-08-10-this-week-in-rust.md (also found in content/2021-08-04-this-week-in-rust.md
possible duplicate link owengage.com/writing/ in file content/2021-08-18-this-week-in-rust.md (also found in content/2021-07-28-this-week-in-rust.md

Thank you for the amazing newsletter 🧡

On the website, it could be nice to have:

• selectable light vs dark mode, with a simple button for picking the active theme, e.g. dark-mode-toggle or similar
• possibly autodetect the user-preferred style with prefers-color-scheme css media query (also supported by above JS snippet and others)
• possibly even support the variety of themes that e.g. rustdoc and mdbook supports (Light, Rust, Coal, Navy, Ayu)

Thanks for this awesome resource! I have a suggestion to make:

I'd like to recommend against using such a light font for all body items on "TWIR". It makes things very difficult to read sometimes.

I could be wrong, but this looks like Helvetica or Arial with a very light weight. I would suggest at least bumping up the weight to 400, or even changing the font to something more legible in general (like Lato, InterUI, etc.)

@brson @llogiq I've added a new section "Notable changes" where I plan to document well... "notable changes" in Rust core. However, of all the 79 PRs merged, it is hard for me to pick "notable" ones, and someone who is more involved in the Rust core can certainly help me out here. For this week, I've picked two PRs, however I'm not very sure about them. Please pay a closer attention to this section while reviewing my drafts, at least for next few weeks while I get more and more familiar with Rust progress flow.

Fixes #2274 (if merged)

Hello! Saw this on TWiR and thought I'd give it a go; I have no experience with frontend work so I'm completely OK with scrapping this PR too.

This sets dark mode for users who have dark color schemes preferred. I tried replicating a similar color scheme to docs.rs' Dark theme because I thought it'd look nice. I'm also down to change the color scheme, but I kind of agree about not liking straight white-on-black, which is discussed in a previous attempt to bring a dark mode (https://github.com/rust-lang/this-week-in-rust/pull/1089#issuecomment-565978373).

Preview:

I understand that this doesn't give users the option to change between themes. If that prevents a merge, I'll try and spend additional time to implement some tri-state widget as mentioned by @flying-sheep.

I also added a tiny commit that's unrelated to dark mode that fixes a typo (developments in Rust community -> developments in THE Rust Community). In addition, I added margins to make it look nicer and aligned with the other components like the input and header text. Without the margins:

With margins and fixed typo:

Adding margins is kind of a subjective choice, and my choice in color scheme is also just my preference, so please let me know what you all think!

I didn't found any principle of TWIR regard to the contribution content. Since I often see some non-English articles, I believe the TWIR is open to all languages around the world. I sincerely appreciate this. However, I don't know whether we have native speakers in the team to take seriously review those non-English articles. If not yet, I propose we should.

As a native speaker of Chinese, I'm pretty disappointed with the recent Chinese articles in the TWIR, especially for a website called budshome.com (mostly from those PRs). Here are my reasons:

• budshome.com is a kind of SEO website which is full of a lot of ads and promotion links. Here is the google site search result.
• The quality of articles from budshome.com is quite bad. Mostly are the beginner or introductory level. (I'm not opposed to the beginner-level articles, I'm opposed to those SEO sites with low-quality articles.)
• The author submits his articles to TWIR seems like aimed to boost the traffic of his websites. Clearly, an utilitarian.

Closes: #2688

Changes coloring of clicked links from a darker blue, to a dark purple. Several websites use this color distinction (e.g. here), and I believe it will make it easier to tell which links have been visited already in light mode

The example below shows the same page containing several clicked links, with the image on the right showing the newer color choice.

With the addition of a dark mode for the website, the only way for readers to change theme would be to change their OS preferences.

It would be nice to be able to change the color theme directly on the site. Proposed ideas include a tri-state switch or button (maybe like the MDN docs?), but optimally it would be nice to have a setting for choosing dark, light, or the OS default.

See more discussion about this here.

The 0.15.0 release of cargo-semver-checks contains a massive number of improvements. I would like to get your thoughts on whether including the release notes in the "Project/Tooling Updates" section would be an appropriate way to communicate this to the TWIR readers, or if there's something else you'd recommend instead.

Thanks again for all the awesome work you're doing!

The title image and header of the email are not breaking correctly in the generated HTML code for the TwiR email issue.

The break should be placed after the "This Week in Rust" title image. Instead, the line is currently breaking after the "This" in the text header.

The email code is being generated by the optimize-email Makefile job, which uses the website code (via the make build && make generate-website && make host-content command) to create an email using juice.

<td style="font-family: 'Helvetica Neue', Helvetica, sans-serif;">
  <img class="wrapper-image " src="https://this-week-in-rust.org/images/logo32.png" alt="This Week in Rust" style="width: 30px; vertical-align: bottom; max-width: 100%;" width="30">
  <span class="wrapper-header-01" style="line-height: 27px; font-size: 23px; font-weight: bold; color: #444444;">This Week in Rust</span>
</td>

Narrow window:

Wide window:

The Pelican publishing script used by the Makefile command optimize-email is not picking up TWIR_NEWSLETTER_THEME setting and defaulting to a CSS style that does not match our most recent issues (e.g. 454).

Currently, the workaround for this has been to change pelicanconf.py from:

if '1' == os.environ.get('TWIR_NEWSLETTER_THEME'):
    THEME = 'themes/newsletter'
else:
    THEME = 'themes/rusted'

to:

THEME = 'themes/newsletter'