---
source: src/feeds/atom.rs
expression: result
---
[
    Post {
        id: -1,
        unique_id: "https://blog.rust-lang.org/2019/09/26/Rust-1.38.0.html",
        link: "https://blog.rust-lang.org/2019/09/26/Rust-1.38.0.html",
        title: "Announcing Rust 1.38.0",
        date: 2019-09-26T00:00:00Z,
        summary: None,
        content: Some(
            "<p>The Rust team is happy to announce a new version of Rust, 1.38.0. Rust is a programming language that is empowering everyone to build reliable and efficient software.</p>\n<p>If you have a previous version of Rust installed via rustup, getting Rust 1.38.0 is as easy as:</p>\n<pre><code>rustup update stable\n</code></pre>\n<p>If you don\'t have it already, you can <a href=\"https://www.rust-lang.org/install.html\" rel=\"noopener noreferrer\">get <code>rustup</code></a> from the appropriate page on our website.</p>\n<h2><a href=\"https://blog.rust-lang.org/2019/09/26/Rust-1.38.0.html#whats-in-1.38.0-stable\" rel=\"noopener noreferrer\"></a>What\'s in 1.38.0 stable</h2>\n<p>The highlight of this release is pipelined compilation.</p>\n<h3><a href=\"https://blog.rust-lang.org/2019/09/26/Rust-1.38.0.html#pipelined-compilation\" rel=\"noopener noreferrer\"></a>Pipelined compilation</h3>\n<p>To compile a crate, the compiler doesn\'t need the dependencies to be fully built. Instead, it just needs their \"metadata\" (i.e. the list of types, dependencies, exports...). This metadata is produced early in the compilation process. Starting with Rust 1.38.0, Cargo will take advantage of this by automatically starting to build dependent crates as soon as metadata is ready.</p>\n<p>While the change doesn\'t have any effect on builds for a single crate, during testing <a href=\"https://internals.rust-lang.org/t/evaluating-pipelined-rustc-compilation/10199\" rel=\"noopener noreferrer\">we got reports</a> of 10-20% compilation speed increases for optimized, clean builds of some crate graphs. Other ones did not improve much, and the speedup depends on the hardware running the build, so your mileage might vary. No code changes are needed to benefit from this.</p>\n<h3><a href=\"https://blog.rust-lang.org/2019/09/26/Rust-1.38.0.html#linting-some-incorrect-uses-of-mem:{uninitialized,-zeroed}\" rel=\"noopener noreferrer\"></a>Linting some incorrect uses of <code>mem::{uninitialized, zeroed}</code></h3>\n<p>As <a href=\"https://blog.rust-lang.org/2019/07/04/Rust-1.36.0.html#maybeuninitt%3E-instead-of-mem::uninitialized\" rel=\"noopener noreferrer\">previously announced</a>, <code>std::mem::uninitialized</code> is essentially impossible to use safely. Instead, <code>MaybeUninit&lt;T&gt;</code> should be used.</p>\n<p>We have not yet deprecated <code>mem::uninitialized</code>; this will be done in a future release. Starting in 1.38.0, however, <code>rustc</code> will provide a lint for a narrow class of incorrect initializations using <code>mem::uninitialized</code> or <code>mem::zeroed</code>.</p>\n<p>It is undefined behavior for some types, such as <code>&amp;T</code> and <code>Box&lt;T&gt;</code>, to ever contain an all-<code>0</code> bit pattern, because they represent pointer-like objects that cannot be <code>null</code>. It is therefore an error to use <code>mem::uninitialized</code> or <code>mem::zeroed</code> to initialize one of these types, so the new lint will attempt to warn whenever one of those functions is used to initialize one of them, either directly or as a member of a larger <code>struct</code>. The check is recursive, so the following code will emit a warning:</p>\n<pre><code>struct Wrap&lt;T&gt;(T);\nstruct Outer(Wrap&lt;Wrap&lt;Wrap&lt;Box&lt;i32&gt;&gt;&gt;&gt;);\nstruct CannotBeZero {\n    outer: Outer,\n    foo: i32,\n    bar: f32\n}\n\n...\n\nlet bad_value: CannotBeZero = unsafe { std::mem::uninitialized() };\n</code></pre>\n<p>Astute readers may note that Rust has more types that cannot be zero, notably <code>NonNull&lt;T&gt;</code> and <code>NonZero&lt;T&gt;</code>. For now, initialization of these structs with <code>mem::uninitialized</code> or <code>mem::zeroed</code> is <em>not</em> linted against.</p>\n<p>These checks do not cover all cases of unsound use of <code>mem::uninitialized</code> or <code>mem::zeroed</code>, they merely help identify code that is definitely wrong. All code should still be moved to use <code>MaybeUninit</code> instead.</p>\n<h3><a href=\"https://blog.rust-lang.org/2019/09/26/Rust-1.38.0.html#[deprecated]-macros\" rel=\"noopener noreferrer\"></a><code>#[deprecated]</code> macros</h3>\n<p>The <code>#[deprecated]</code> attribute, first introduced in Rust 1.9.0, allows crate authors to notify their users an item of their crate is deprecated and will be removed in a future release. Rust 1.38.0 extends the attribute, allowing it to be applied to macros as well.</p>\n<h3><a href=\"https://blog.rust-lang.org/2019/09/26/Rust-1.38.0.html#std:any::type_name\" rel=\"noopener noreferrer\"></a><code>std::any::type_name</code></h3>\n<p>For debugging, it is sometimes useful to get the name of a type. For instance, in generic code, you may want to see, at run-time, what concrete types a function\'s type parameters has been instantiated with. This can now be done using <code>std::any::type_name</code>:</p>\n<pre><code>fn gen_value&lt;T: Default&gt;() -&gt; T {\n    println!(\"Initializing an instance of {}\", std::any::type_name::&lt;T&gt;());\n    Default::default()\n}\n\nfn main() {\n    let _: i32 = gen_value();\n    let _: String = gen_value();\n}\n</code></pre>\n<p>This prints:</p>\n<pre><code>Initializing an instance of i32\nInitializing an instance of alloc::string::String\n</code></pre>\n<p>Like all standard library functions intended only for debugging, the exact contents and format of the string are not guaranteed. The value returned is only a best-effort description of the type; multiple types may share the same <code>type_name</code> value, and the value may change in future compiler releases.</p>\n<h3><a href=\"https://blog.rust-lang.org/2019/09/26/Rust-1.38.0.html#library-changes\" rel=\"noopener noreferrer\"></a>Library changes</h3>\n<ul>\n<li><a href=\"https://github.com/rust-lang/rust/pull/62528/\" rel=\"noopener noreferrer\"><code>slice::{concat, connect, join}</code> now accepts <code>&amp;[T]</code> in addition to <code>&amp;T</code>.</a></li>\n<li><a href=\"https://github.com/rust-lang/rust/pull/62583/\" rel=\"noopener noreferrer\"><code>*const T</code> and <code>*mut T</code> now implement <code>marker::Unpin</code>.</a></li>\n<li><a href=\"https://github.com/rust-lang/rust/pull/61953/\" rel=\"noopener noreferrer\"><code>Arc&lt;[T]&gt;</code> and <code>Rc&lt;[T]&gt;</code> now implement <code>FromIterator&lt;T&gt;</code>.</a></li>\n<li><a href=\"https://github.com/rust-lang/rust/pull/61457/\" rel=\"noopener noreferrer\"><code>iter::{StepBy, Peekable, Take}</code> now implement <code>DoubleEndedIterator</code>.</a></li>\n</ul>\n<p>Additionally, these functions have been stabilized:</p>\n<ul>\n<li><a href=\"https://doc.rust-lang.org/std/primitive.pointer.html#method.cast\" rel=\"noopener noreferrer\"><code>&lt;*const T&gt;::cast</code></a> and <a href=\"https://doc.rust-lang.org/std/primitive.pointer.html#method.cast-1\" rel=\"noopener noreferrer\"><code>&lt;*mut T&gt;::cast</code></a></li>\n<li><a href=\"https://doc.rust-lang.org/std/time/struct.Duration.html#method.as_secs_f32\" rel=\"noopener noreferrer\"><code>Duration::as_secs_f32</code></a> and <a href=\"https://doc.rust-lang.org/std/time/struct.Duration.html#method.as_secs_f64\" rel=\"noopener noreferrer\"><code>Duration::as_secs_f64</code></a></li>\n<li><a href=\"https://doc.rust-lang.org/std/time/struct.Duration.html#method.div_f32\" rel=\"noopener noreferrer\"><code>Duration::div_f32</code></a> and <a href=\"https://doc.rust-lang.org/std/time/struct.Duration.html#method.div_f64\" rel=\"noopener noreferrer\"><code>Duration::div_f64</code></a></li>\n<li><a href=\"https://doc.rust-lang.org/std/time/struct.Duration.html#method.from_secs_f32\" rel=\"noopener noreferrer\"><code>Duration::from_secs_f32</code></a> and <a href=\"https://doc.rust-lang.org/std/time/struct.Duration.html#method.from_secs_f64\" rel=\"noopener noreferrer\"><code>Duration::from_secs_f64</code></a></li>\n<li><a href=\"https://doc.rust-lang.org/std/time/struct.Duration.html#method.mul_f32\" rel=\"noopener noreferrer\"><code>Duration::mul_f32</code></a> and <a href=\"https://doc.rust-lang.org/std/time/struct.Duration.html#method.mul_f64\" rel=\"noopener noreferrer\"><code>Duration::mul_f64</code></a></li>\n<li>Euclidean remainder and division operations -- <a href=\"https://doc.rust-lang.org/std/primitive.i32.html#method.div_euclid\" rel=\"noopener noreferrer\"><code>div_euclid</code></a>,\n<a href=\"https://doc.rust-lang.org/std/primitive.i32.html#method.rem_euclid\" rel=\"noopener noreferrer\"><code>rem_euclid</code></a> -- for all integer primitives. <code>checked</code>,\n<code>overflowing</code>, and <code>wrapping</code> versions are also available.</li>\n</ul>\n<h3><a href=\"https://blog.rust-lang.org/2019/09/26/Rust-1.38.0.html#other-changes\" rel=\"noopener noreferrer\"></a>Other changes</h3>\n<p>There are other changes in the Rust 1.38 release: check out what changed in <a href=\"https://github.com/rust-lang/rust/blob/master/RELEASES.md#version-1380-2019-09-26\" rel=\"noopener noreferrer\">Rust</a>, <a href=\"https://github.com/rust-lang/cargo/blob/master/CHANGELOG.md#cargo-138-2019-09-26\" rel=\"noopener noreferrer\">Cargo</a>, and <a href=\"https://github.com/rust-lang/rust-clippy/blob/master/CHANGELOG.md#rust-138\" rel=\"noopener noreferrer\">Clippy</a>.</p>\n<h3><a href=\"https://blog.rust-lang.org/2019/09/26/Rust-1.38.0.html#corrections\" rel=\"noopener noreferrer\"></a>Corrections</h3>\n<p>A Previous version of this post mistakenly marked these functions as stable. They are not yet stable.\n<a href=\"https://doc.rust-lang.org/std/time/struct.Duration.html#method.div_duration_f32\" rel=\"noopener noreferrer\"><code>Duration::div_duration_f32</code></a> and <a href=\"https://doc.rust-lang.org/std/time/struct.Duration.html#method.div_duration_f64\" rel=\"noopener noreferrer\"><code>Duration::div_duration_f64</code></a>.</p>\n<h2><a href=\"https://blog.rust-lang.org/2019/09/26/Rust-1.38.0.html#contributors-to-138.0\" rel=\"noopener noreferrer\"></a>Contributors to 1.38.0</h2>\n<p>Many people came together to create Rust 1.38.0. We couldn\'t have done it\nwithout all of you. <a href=\"https://thanks.rust-lang.org/rust/1.38.0/\" rel=\"noopener noreferrer\">Thanks!</a></p>\n",
        ),
        media_type: None,
        media_link: None,
        comments_link: None,
    },
    Post {
        id: -1,
        unique_id: "https://blog.rust-lang.org/2019/09/30/Async-await-hits-beta.html",
        link: "https://blog.rust-lang.org/2019/09/30/Async-await-hits-beta.html",
        title: "Async-await hits beta!",
        date: 2019-09-30T00:00:00Z,
        summary: None,
        content: Some(
            "<p>Big news! As of this writing, <strong>syntactic support for async-await is\navailable in the Rust beta channel!</strong> It will be available in the 1.39\nrelease, which is expected to be released on <strong>November 7th, 2019</strong>.\nOnce async-await hits stable, that will mark the culmination of a\n<strong>multi-year effort to enable efficient and ergonomic asynchronous I/O\nin Rust</strong>. It will not, however, mark the end of the road: there is\nstill more work to do, both in terms of polish (some of the error\nmessages we get today are, um, <a href=\"https://github.com/rust-lang/rust/issues/64130\" rel=\"noopener noreferrer\">not great</a>) and in terms of feature\nset (<a href=\"https://github.com/dtolnay/async-trait\" rel=\"noopener noreferrer\">async fn in traits</a>, anyone?).</p>\n<p>(If you\'re not familiar with what async-await is, don\'t despair!\nThere\'s a primer and other details later on in this post!)</p>\n<h3><a href=\"https://blog.rust-lang.org/2019/09/30/Async-await-hits-beta.html#async-await-support-in-the-ecosystem-growing-rapidly\" rel=\"noopener noreferrer\"></a>Async-await support in the ecosystem growing rapidly</h3>\n<p>But async-await has never been the entire story. To make good use of\nasync-await, you also need strong libraries and a vibrant ecosystem.\n<strong>Fortunately, you\'ve got a lot of good choices, and they keep getting\nbetter:</strong></p>\n<ul>\n<li>the async runtime <a href=\"https://tokio.rs/\" rel=\"noopener noreferrer\">tokio</a>, for example, recently announced an <a href=\"https://tokio.rs/blog/2019-08-alphas/\" rel=\"noopener noreferrer\">alpha\nrelease</a> based on async-await;</li>\n<li>the <a href=\"https://async.rs/blog/announcing-async-std/\" rel=\"noopener noreferrer\">recently announced</a> <a href=\"https://async.rs/\" rel=\"noopener noreferrer\">async-std</a> library was built from the\nstart on the new async-await syntax;</li>\n<li>using <a href=\"https://docs.rs/crate/wasm-bindgen-futures/0.2.16\" rel=\"noopener noreferrer\">wasm-bindgen-futures</a>, you can even bridge Rust Futures with\n<a href=\"https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Using_promises\" rel=\"noopener noreferrer\">JavaScript promises</a>;</li>\n<li>the <a href=\"https://hyper.rs/\" rel=\"noopener noreferrer\">hyper library</a> has <a href=\"https://github.com/hyperium/hyper/issues/1805\" rel=\"noopener noreferrer\">migrated</a> to adopt standard Rust futures;</li>\n<li>the 0.3.0 version of the <a href=\"https://crates.io/crates/futures-preview\" rel=\"noopener noreferrer\">futures-rs library</a> will support\nasync-await and will be released by the time async-await hits stable\n(you can use the <a href=\"https://rust-lang-nursery.github.io/futures-rs/blog/2018/07/19/futures-0.3.0-alpha.1.html\" rel=\"noopener noreferrer\">0.3.0-alpha</a> releases now);</li>\n<li>finally, async-await support is starting to become available in higher-level\n<a href=\"https://www.arewewebyet.org/topics/frameworks/\" rel=\"noopener noreferrer\">web frameworks</a> as well.</li>\n</ul>\n<h3><a href=\"https://blog.rust-lang.org/2019/09/30/Async-await-hits-beta.html#restructuring-async-io-in-the-rust-org\" rel=\"noopener noreferrer\"></a>Restructuring Async I/O in the Rust org</h3>\n<p>Now that async-await is approaching stable, we are taking the\nopportunity to make some changes to our Rust team structure. The\ncurrent structure includes two working groups: the <a href=\"https://rust-lang.github.io/compiler-team/working-groups/async-await/\" rel=\"noopener noreferrer\">Async Foundations\nWG</a>, focused on building up core language support, and the <a href=\"https://github.com/rustasync/team\" rel=\"noopener noreferrer\">Async\nEcosystem WG</a>, focused on supporting the ecosystem develop.</p>\n<p><strong>In light of all the activity going on in the ecosystem, however,\nthere it not as much need for the <a href=\"https://github.com/rustasync/team\" rel=\"noopener noreferrer\">Async Ecosystem WG</a>, and as such\nwe\'ve decided to spin it down.</strong> We\'ll be deprecating the <a href=\"https://github.com/rustasync/\" rel=\"noopener noreferrer\">rustasync\ngithub org</a>. The <a href=\"https://areweasyncyet.rs/\" rel=\"noopener noreferrer\">areweasyncyet.rs</a> and <a href=\"https://www.arewewebyet.org/\" rel=\"noopener noreferrer\">arewewebyet.org</a> websites\nwill move to the main <a href=\"https://github.com/rust-lang/\" rel=\"noopener noreferrer\">rust-lang org</a>, but the fate of the other\nprojects will be decided by the people who built them. A few will\nlikely be deprecated, and the remainder will be moving out to be\nmaintained independently.</p>\n<p><strong>The <a href=\"https://rust-lang.github.io/compiler-team/working-groups/async-await/\" rel=\"noopener noreferrer\">Async Foundations WG</a>, meanwhile, will continue, but with a\nshift in focus.</strong> Now that async-await is en route to stabilization,\nthe focus will be on polish, such as improving diagnostics, fixing\nsmaller bugs, and improving documentation such as the <a href=\"https://github.com/rust-lang/async-book\" rel=\"noopener noreferrer\">async\nbook</a>. Once progress is made on that, we\'ll be considering what\nfeatures to implement next.</p>\n<p>(An aside: this is the first time that we\'ve ever opted to spin <em>down</em>\na working group, and we realized that we don\'t have a formal policy\nfor that. We\'ve <a href=\"https://github.com/rust-lang/wg-governance/issues/25\" rel=\"noopener noreferrer\">created an issue</a> with the <a href=\"https://github.com/rust-lang/wg-governance/\" rel=\"noopener noreferrer\">governance working\ngroup</a> to look into that for the future.)</p>\n<h3><a href=\"https://blog.rust-lang.org/2019/09/30/Async-await-hits-beta.html#async-await-a-quick-primer\" rel=\"noopener noreferrer\"></a>Async await: a quick primer</h3>\n<p>So, what is async await? Async-await is a way to write functions that\ncan \"pause\", return control to the runtime, and then pick up from\nwhere they left off.  Typically those pauses are to wait for I/O, but\nthere can be any number of uses.</p>\n<p>You may be familiar with the async-await from other languages, such as\nJavaScript or C#. Rust\'s version of the feature is similar, but with a\nfew key differences.</p>\n<p>To use async-await, you start by writing <code>async fn</code> instead of <code>fn</code>:</p>\n<pre><code>async fn first_function() -&gt; u32 { .. }\n</code></pre>\n<p>Unlike a regular function, calling an <code>async fn</code> doesn\'t do anything\nto start -- instead, it returns a <code>Future</code>. This is a suspended\ncomputation that is waiting to be executed. To actually <em>execute</em>\nthe future, you have to use the <code>.await</code> operator:</p>\n<pre><code>async fn another_function() {\n    // Create the future:\n    let future = first_function();\n    \n    // Await the future, which will execute it (and suspend\n    // this function if we encounter a need to wait for I/O): \n    let result: u32 = future.await;\n    ...\n}\n</code></pre>\n<p>This example shows the first difference between Rust and other\nlanguages: we write <code>future.await</code> instead of <code>await future</code>. This\nsyntax integrates better with Rust\'s <code>?</code> operator for propagating\nerrors (which, after all, are very common in I/O). One can simply\nwrite <code>future.await?</code> to await the result of a future and propagate\nerrors. It also has the advantage of making method chaining painless.</p>\n<h3><a href=\"https://blog.rust-lang.org/2019/09/30/Async-await-hits-beta.html#zero-cost-futures\" rel=\"noopener noreferrer\"></a>Zero-cost futures</h3>\n<p>The other difference between Rust futures and futures in other\nlanguages is that they are based on a \"poll\" model, which makes them\n<strong>zero cost</strong>. In other languages, invoking an async function\nimmediately creates a future and schedules it for execution: awaiting\nthe future isn\'t really necessary for it to execute. But this implies\nsome overhead for each future that is created.</p>\n<p>In contrast, in Rust, calling an async function does not do any\nscheduling in and of itself, which means that we can compose a complex\nnest of futures without incurring a per-future cost. As an end-user,\nthough, the main thing you\'ll notice is that <strong>futures feel \"lazy\"</strong>:\nthey don\'t do anything until you await them.</p>\n<p>If you\'d like a closer look at how futures work under the hood, take a\nlook at <a href=\"https://rust-lang.github.io/async-book/02_execution/04_executor.html\" rel=\"noopener noreferrer\">the executor section</a> of the <a href=\"https://github.com/rust-lang/async-book\" rel=\"noopener noreferrer\">async book</a>, or watch the\n<a href=\"https://www.youtube.com/watch?v=skos4B5x7qE\" rel=\"noopener noreferrer\">excellent talk</a> that <a href=\"https://github.com/withoutboats\" rel=\"noopener noreferrer\">withoutboats</a> gave at <a href=\"https://rustlatam.org/\" rel=\"noopener noreferrer\">Rust LATAM 2019</a>\non the topic.</p>\n<h3><a href=\"https://blog.rust-lang.org/2019/09/30/Async-await-hits-beta.html#summary\" rel=\"noopener noreferrer\"></a>Summary</h3>\n<p>In summary, if you\'ve an interest in using Async I/O in Rust, this is\na very exciting time! With async-await syntax hitting stable in\nNovember, it\'s going to be easier than ever to write futures (in\nparticular, if you tried using the combinator-based futures in the\npast, you\'ll find <a href=\"http://aturon.github.io/tech/2018/04/24/async-borrowing/\" rel=\"noopener noreferrer\">async-await integrates much better with Rust\'s\nborrowing system</a>). Moreover, there are now a number of great\nruntimes and other libraries available in the ecosystem to work with.\nSo get out there and build stuff!</p>\n<p>(Oh, yeah, and please file bugs when you hit confusing or surprising\nproblems, so we can improve the user experience!)</p>\n",
        ),
        media_type: None,
        media_link: None,
        comments_link: None,
    },
    Post {
        id: -1,
        unique_id: "https://blog.rust-lang.org/2019/09/30/Security-advisory-for-cargo.html",
        link: "https://blog.rust-lang.org/2019/09/30/Security-advisory-for-cargo.html",
        title: "Security advisory for Cargo",
        date: 2019-09-30T00:00:00Z,
        summary: None,
        content: Some(
            "<blockquote>\n<p><strong>Note</strong>: This is a cross-post of the <a href=\"https://groups.google.com/forum/#!topic/rustlang-security-announcements/rVQ5e3TDnpQ\" rel=\"noopener noreferrer\">official security advisory</a>. The official\npost contains a signed version with our PGP key, as well.</p>\n</blockquote>\n<p>The Rust team was recently notified of a security concern when using older versions of Cargo to build crates which use the package rename feature added in newer versions of Cargo. If you\'re using Rust 1.26.0, released on 2018-05-10, or later you\'re not affected.</p>\n<p>The CVE for this vulnerability is <a href=\"https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-16760\" rel=\"noopener noreferrer\">CVE-2019-16760</a>.</p>\n<h2><a href=\"https://blog.rust-lang.org/2019/09/30/Security-advisory-for-cargo.html#overview\" rel=\"noopener noreferrer\"></a>Overview</h2>\n<p>Cargo can be configured through <code>Cargo.toml</code> and the <code>[dependencies]</code> section to depend on different crates, such as those from crates.io. There are multiple ways to configure how you depend on crates as well, for example if you depend on <code>serde</code> and enable the <code>derive</code> feature it would look like:</p>\n<pre><code>serde = { version = \"1.0\", features = [\'derive\'] }\n</code></pre>\n<p>Rust 1.31.0 <a href=\"https://blog.rust-lang.org/2018/12/06/Rust-1.31-and-rust-2018.html#cargo-features\" rel=\"noopener noreferrer\">introduced a new feature of Cargo</a> where one of the optional keys you can specify in this map is <code>package</code>, a way to <a href=\"https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#renaming-dependencies-in-cargotoml\" rel=\"noopener noreferrer\">rename a crate locally</a>. For example if you preferred to use <code>serde1</code> locally instead of <code>serde</code>, you could write:</p>\n<pre><code>serde1 = { version = \"1.0\", features = [\'derive\'], package = \"serde\" }\n</code></pre>\n<p>It\'s the addition of the <code>package</code> key that causes Cargo to compile the crate differently. This feature was <a href=\"https://github.com/rust-lang/cargo/pull/4953\" rel=\"noopener noreferrer\">first implemented</a> in Rust 1.26.0, but it was unstable at the time. For Rust 1.25.0 and prior, however, Cargo would ignore the <code>package</code> key and and interpret the dependency line as if it were:</p>\n<pre><code>serde1 = { version = \"1.0\", features = [\'derive\'] }\n</code></pre>\n<p>This means when compiled with Rust 1.25.0 and prior then it would attempt to download the <code>serde1</code> crate. A malicious user could squat the <code>serde1</code> name on crates.io to look like <code>serde 1.0.0</code> but instead act maliciously when built.</p>\n<p>In summary, usage of the <code>package</code> key to rename dependencies in <code>Cargo.toml</code> is ignored in Rust 1.25.0 and prior. When Rust 1.25.0 and prior is used Cargo will ignore <code>package</code> and download the wrong dependency, which could be squatted on crates.io to be a malicious package. This not only affects manifests that you write locally yourself, but also manifests published to crates.io. If you published a crate, for example, that depends on <code>serde1</code> to crates.io then users who depend on you may also be vulnerable if they use Rust 1.25.0 and prior.</p>\n<h2><a href=\"https://blog.rust-lang.org/2019/09/30/Security-advisory-for-cargo.html#affected-versions\" rel=\"noopener noreferrer\"></a>Affected Versions</h2>\n<p>Rust 1.0.0 through Rust 1.25.0 is affected by this advisory because Cargo will ignore the <code>package</code> key in manifests. Rust 1.26.0 through Rust 1.30.0 are not affected and typically will emit an error because the <code>package</code> key is unstable. Rust 1.31.0 and after are not affected because Cargo understands the <code>package</code> key.</p>\n<p>In terms of Cargo versions, this affects Cargo up through Cargo 0.26.0. All future versions of Cargo are unaffected.</p>\n<h2><a href=\"https://blog.rust-lang.org/2019/09/30/Security-advisory-for-cargo.html#mitigations\" rel=\"noopener noreferrer\"></a>Mitigations</h2>\n<p>We strongly recommend that users of the affected versions update their compiler to the latest available one. Preventing this issue from happening requires updating your compiler to either Rust 1.26.0 or newer.</p>\n<p>We will not be issuing a patch release for Rust versions prior to 1.26.0. Users of Rust 1.19.0 to Rust 1.25.0 can instead apply <a href=\"https://gist.github.com/pietroalbini/0d293b24a44babbeb6187e06eebd4992\" rel=\"noopener noreferrer\">the provided patches</a> to mitigate the issue.</p>\n<p>An audit of existing crates published to crates.io using the <code>package</code> key has been performed and there is no evidence that this vulnerability has been exploited in the wild. Our audit only covers the crates currently published on crates.io: if you notice crates exploiting this vulnerability in the future please don\'t hesitate to email security@rust-lang.org in accordance with <a href=\"https://www.rust-lang.org/policies/security\" rel=\"noopener noreferrer\">our security policy</a>.</p>\n<h2><a href=\"https://blog.rust-lang.org/2019/09/30/Security-advisory-for-cargo.html#timeline-of-events\" rel=\"noopener noreferrer\"></a>Timeline of events</h2>\n<ul>\n<li>Wed, Sep 18, 2019 at 13:54 UTC - Bug reported to security@rust-lang.org</li>\n<li>Wed, Sep 18, 2019 at 15:35 UTC - Response confirming the report</li>\n<li>Wed, Sep 18, 2019 - Cargo, Core, and crates.io teams confer on how best to handle this</li>\n<li>Thu, Sep 19, 2019 - Confirmed with Elichai plan of action and continued to audit existing crates</li>\n<li>Mon, Sep 23, 2019 - Advisory drafted, patches developed, audit completed</li>\n<li>Mon, Sep 30, 2019 - Advisory published, security list informed of this issue</li>\n</ul>\n<h2><a href=\"https://blog.rust-lang.org/2019/09/30/Security-advisory-for-cargo.html#acknowledgments\" rel=\"noopener noreferrer\"></a>Acknowledgments</h2>\n<p>Thanks to Elichai Turkel, who found this bug and reported it to us in accordance\nwith our <a href=\"https://www.rust-lang.org/policies/security\" rel=\"noopener noreferrer\">security policy</a>.</p>\n",
        ),
        media_type: None,
        media_link: None,
        comments_link: None,
    },
    Post {
        id: -1,
        unique_id: "https://blog.rust-lang.org/2019/10/03/inside-rust-blog.html",
        link: "https://blog.rust-lang.org/2019/10/03/inside-rust-blog.html",
        title: "Announcing the Inside Rust blog",
        date: 2019-10-03T00:00:00Z,
        summary: None,
        content: Some(
            "<p>Today we\'re happy to announce that we\'re starting a second blog, the\n<a href=\"https://blog.rust-lang.org/inside-rust/index.html\" rel=\"noopener noreferrer\"><strong>Inside Rust</strong> blog</a>. This blog will be used to post regular\nupdates by the various Rust teams and working groups. If you\'re\ninterested in following along with the \"nitty gritty\" of Rust\ndevelopment, then you should take a look!</p>\n",
        ),
        media_type: None,
        media_link: None,
        comments_link: None,
    },
    Post {
        id: -1,
        unique_id: "https://blog.rust-lang.org/2019/10/15/Rustup-1.20.0.html",
        link: "https://blog.rust-lang.org/2019/10/15/Rustup-1.20.0.html",
        title: "Announcing Rustup 1.20.0",
        date: 2019-10-15T00:00:00Z,
        summary: None,
        content: Some(
            "<p>The rustup working group is happy to announce the release of rustup version 1.20.0. <a href=\"https://rustup.rs/\" rel=\"noopener noreferrer\">Rustup</a> is the recommended tool to install <a href=\"https://www.rust-lang.org/\" rel=\"noopener noreferrer\">Rust</a>, a programming language that is empowering everyone to build reliable and efficient software.</p>\n<p>If you have a previous version of rustup installed, getting rustup 1.20.0 is as easy as:</p>\n<pre><code>rustup self update\n</code></pre>\n<p>Rustup will also automatically update itself at the end of a normal toolchain update:</p>\n<pre><code>rustup update\n</code></pre>\n<p>If you don\'t have it already, you can <a href=\"https://rustup.rs/\" rel=\"noopener noreferrer\">get rustup</a> from the appropriate page on our website.</p>\n<h2><a href=\"https://blog.rust-lang.org/2019/10/15/Rustup-1.20.0.html#whats-new-in-rustup-1.20.0\" rel=\"noopener noreferrer\"></a>What\'s new in rustup 1.20.0</h2>\n<p>The highlights of this release are profiles support, the ability to get the latest available nightly with all the components you need, and improvements to the <code>rustup doc</code> command. You can also check out <a href=\"https://github.com/rust-lang/rustup.rs/blob/master/CHANGELOG.md\" rel=\"noopener noreferrer\">the changelog</a> for a list of all the changes included in this release.</p>\n<h3><a href=\"https://blog.rust-lang.org/2019/10/15/Rustup-1.20.0.html#profiles\" rel=\"noopener noreferrer\"></a>Profiles</h3>\n<p>Previous versions of rustup installed a few components by default along with each toolchain: the compiler (<code>rustc</code>), the package manager (<code>cargo</code>), the standard library (<code>rust-std</code>), and offline documentation (<code>rust-docs</code>). While this approach is fine while developing software locally, some of the components (like <code>rust-docs</code>) slowed down the installation, either because they\'re not used on build servers, or on Windows due to the large amount of installed files.</p>\n<p>To address this problem, rustup 1.20.0 introduces the concept of \"profiles\". They are groups of components you can choose to download while installing a new Rust toolchain. The profiles available at this time are <code>minimal</code>, <code>default</code>, and <code>complete</code>:</p>\n<ul>\n<li>The <strong>minimal</strong> profile includes as few components as possible to get a working compiler (<code>rustc</code>, <code>rust-std</code>, and <code>cargo</code>). It\'s recommended to use this component on Windows systems if you don\'t use local documentation, and in CI.</li>\n<li>The <strong>default</strong> profile includes all the components previously installed by default (<code>rustc</code>, <code>rust-std</code>, <code>cargo</code>, and <code>rust-docs</code>) plus <code>rustfmt</code> and <code>clippy</code>. This profile will be used by rustup by default, and it\'s the one recommended for general use.</li>\n<li>The <strong>complete</strong> profile includes all the components available through rustup, including <code>miri</code> and IDE integration tools (<code>rls</code> and <code>rust-analysis</code>).</li>\n</ul>\n<p>To change the rustup profile you can use the <code>rustup set profile</code> command. For example, to select the minimal profile you can use:</p>\n<pre><code>rustup set profile minimal\n</code></pre>\n<p>It\'s also possible to choose the profile when installing rustup for the first time, either interactively by choosing the \"Customize installation\" option or programmaticaly by passing the <code>--profile=&lt;name&gt;</code> flag. Profiles will only affect newly installed toolchains: as usual it will be possible to install individual components later with: <code>rustup component add</code>.</p>\n<h3><a href=\"https://blog.rust-lang.org/2019/10/15/Rustup-1.20.0.html#installing-the-latest-compatible-nightly\" rel=\"noopener noreferrer\"></a>Installing the latest compatible nightly</h3>\n<p>While most components are guaranteed to be present on stable releases of <a href=\"https://forge.rust-lang.org/release/platform-support.html\" rel=\"noopener noreferrer\">tier 1 platforms</a>, the same guarantee doesn\'t apply to nightly builds. Frequently, tools such as <code>rustfmt</code>, <code>clippy</code>, or <code>rls</code> are missing in the latest nightly. If you depend on these tools, that makes updating nighties hard, as rustup will prevent the upgrade if a component you previously installed is missing.</p>\n<p>Starting from rustup 1.20.0, if a component you previously installed is missing in the latest nightly, <code>rustup update</code> will walk backwards in time to find the most recent release with all the components you need. If there are no new nightlies with all the components you need you\'ll either need to wait or remove some of them.</p>\n<p>Along with this change, rustup 1.20.0 introduces the <code>--component</code>/<code>-c</code> and <code>--target</code>/<code>-t</code> options to the <code>rustup toolchain install</code> command, allowing you to add components and targets as the toolchain is installed. These flags will also search past nightlies if the current one does not feature all the requested components.</p>\n<h3><a href=\"https://blog.rust-lang.org/2019/10/15/Rustup-1.20.0.html#improvements-to-rustup-doc\" rel=\"noopener noreferrer\"></a>Improvements to <code>rustup doc</code></h3>\n<p>The <code>rustup doc</code> command opens the locally installed documentation on your browser, without any Internet connection required. rustup 1.20.0 enhances the command allowing you to open directly the API documentation of a specific item. For example to look at the documentation of <a href=\"https://doc.rust-lang.org/std/iter/trait.Iterator.html\" rel=\"noopener noreferrer\"><code>Iterator</code></a> you can use:</p>\n<pre><code>rustup doc std::iter::Iterator\n</code></pre>\n<p>This works for traits, structs/enums, macros, and modules, and can take you to the <code>std</code>, <code>alloc</code>, and <code>core</code> crates. Note, however, that this functionality will only work if you have the <code>rust-docs</code> component installed in your toolchain. We will be improving the command\'s UX over time, so if you have ideas, please do let us know!</p>\n<h2><a href=\"https://blog.rust-lang.org/2019/10/15/Rustup-1.20.0.html#thanks\" rel=\"noopener noreferrer\"></a>Thanks</h2>\n<p>Thanks to all the contributors who made rustup 1.20.0 possible!</p>\n<ul>\n<li>Andy McCaffrey</li>\n<li>Artem Borisovskiy</li>\n<li>Benjamin Chen</li>\n<li>Daniel Silverstone</li>\n<li>Jon Gjengset</li>\n<li>Lzu Tao</li>\n<li>Matt Kantor</li>\n<li>Mitchell Hynes</li>\n<li>Nick Cameron</li>\n<li>PicoJr</li>\n<li>Pietro Albini</li>\n</ul>\n",
        ),
        media_type: None,
        media_link: None,
        comments_link: None,
    },
    Post {
        id: -1,
        unique_id: "https://blog.rust-lang.org/2019/10/29/A-call-for-blogs-2020.html",
        link: "https://blog.rust-lang.org/2019/10/29/A-call-for-blogs-2020.html",
        title: "A call for blogs 2020",
        date: 2019-10-29T00:00:00Z,
        summary: None,
        content: Some(
            "<p>What will Rust development look like in 2020? That\'s partially up to you! Here\'s how it works:</p>\n<ul>\n<li>Anyone and everyone in the Rust community writes a blog post about what they\'d like Rust development to be like in 2020.</li>\n<li>The core team reads all the posts, and writes up a \"Roadmap RFC\" to make a formal proposal.</li>\n<li>The RFC is reviewed by everyone, comments are made, adjustments are made, and eventually it is accepted.</li>\n<li>This RFC is a guide to either accept or postpone RFCs for 2020. If a proposal fits into the themes of what we want to accomplish, we\'ll take it, but if it doesn\'t, we\'ll put it off until the next year.</li>\n</ul>\n<p>This process takes time, and it won\'t <em>quite</em> be complete before 2020 starts.</p>\n<ul>\n<li>We\'ll review the posts December 1. That gives you a month to think about Rust in 2020 and write something up.</li>\n<li>We\'ll aim to produce the RFC draft in the week or two after</li>\n<li>Depending on how many comments the RFC gets, we may not end up accepting it until early January.</li>\n</ul>\n<h2><a href=\"https://blog.rust-lang.org/2019/10/29/A-call-for-blogs-2020.html#what-were-looking-for\" rel=\"noopener noreferrer\"></a>What we\'re looking for</h2>\n<p>We are accepting ideas about almost anything having to do with Rust: language features, tooling needs, community programs, ecosystem needs... if it\'s related to Rust, we want to hear about it.</p>\n<p>One big question for this year: will there be a Rust 2021 edition? If so, 2020 would be the year to do a lot of associated work and plan the details. What would the edition\'s theme be?</p>\n<ul>\n<li>Rust 2015: Stability</li>\n<li>Rust 2018: Productivity</li>\n<li>Rust 2021: ?</li>\n</ul>\n<p>Let us know what you think!</p>\n<h2><a href=\"https://blog.rust-lang.org/2019/10/29/A-call-for-blogs-2020.html#please-share-these-posts-with-us\" rel=\"noopener noreferrer\"></a>Please share these posts with us</h2>\n<p>You can write up these posts and email them to community@rust-lang.org or tweet them with the hashtag #rust2020. If you\'d prefer to not participate publicly, emailing something to community@rust-lang.org is fine as well.</p>\n<p>Thanks for helping make Rust awesome! We are looking forward to doing amazing things in 2020.</p>\n",
        ),
        media_type: None,
        media_link: None,
        comments_link: None,
    },
    Post {
        id: -1,
        unique_id: "https://blog.rust-lang.org/2019/11/01/nll-hard-errors.html",
        link: "https://blog.rust-lang.org/2019/11/01/nll-hard-errors.html",
        title: "Completing the transition to the new borrow checker",
        date: 2019-11-01T00:00:00Z,
        summary: None,
        content: Some(
            "<p>For most of 2018, we\'ve been issuing warnings about various bugs in the\nborrow checker that we plan to fix -- about two months ago, in the\ncurrent Rust nightly, those warnings became <strong>hard errors</strong>. In about\ntwo weeks, when the nightly branches to become beta, those hard errors\nwill be in the beta build, and they will eventually hit stable on\nDecember 19th, as part of Rust 1.40.0. <strong>If you\'re testing with\nNightly, you should be all set -- but otherwise, you may want to go\nand check to make sure your code still builds. If not, we have advice\nfor fixing common problems below.</strong></p>\n<h3><a href=\"https://blog.rust-lang.org/2019/11/01/nll-hard-errors.html#background-the-non-lexical-lifetime-transition\" rel=\"noopener noreferrer\"></a>Background: the non-lexical lifetime transition</h3>\n<p>When we <a href=\"https://blog.rust-lang.org/2018/12/06/Rust-1.31-and-rust-2018.html\" rel=\"noopener noreferrer\">released Rust 2018 in Rust 1.31</a>, it included a new\nversion of the borrow checker, one that implemented <a href=\"https://blog.rust-lang.org/2018/12/06/Rust-1.31-and-rust-2018.html#non-lexical-lifetimes\" rel=\"noopener noreferrer\">\"non-lexical\nlifetimes\"</a>. This new borrow checker did a much more precise\nanalysis than the original, allowing us to eliminate a lot of\nunnecessary errors and make Rust easier to use. I think most everyone\nwho was using Rust 2015 can attest that this shift was a big\nimprovement.</p>\n<h3><a href=\"https://blog.rust-lang.org/2019/11/01/nll-hard-errors.html#the-new-borrow-checker-also-fixed-a-lot-of-bugs\" rel=\"noopener noreferrer\"></a>The new borrow checker also fixed a lot of bugs</h3>\n<p>What is perhaps less well understood is that the new borrow checker\nimplementation <em>also</em> fixed a lot of bugs. In other words, the new\nborrow checker did not just accept more programs -- <strong>it also rejected\nsome programs that were only accepted in the first place due to memory\nunsafety bugs in the old borrow checker!</strong></p>\n<h3><a href=\"https://blog.rust-lang.org/2019/11/01/nll-hard-errors.html#until-recently-those-fixed-bugs-produced-warnings,-not-errors\" rel=\"noopener noreferrer\"></a>Until recently, those fixed bugs produced warnings, not errors</h3>\n<p>Obviously, we don\'t want to accept programs that could undermine\nRust\'s safety guarantees. At the same time, as part of our commitment\nto stability, we try to avoid making sudden bug fixes that will affect\na lot of code. Whenever possible, we prefer to \"phase in\" those\nchanges gradually. We usually begin with \"Future Compatibility\nWarnings\", for example, before moving those warnings to hard errors\n(sometimes a small bit at a time). Since the bug fixes to the borrow\nchecker affected a lot of crates, we knew we needed a warning period\nbefore we could make them into hard errors.</p>\n<p>To implement this warning period, we kept two copies of the borrow\nchecker around (this is a trick we use quite frequently, actually).\nThe new checker ran first. If it found errors, we didn\'t report them\ndirectly: instead, we ran the old checker in order to see if the crate\n<em>used</em> to compile before. If so, we reported the errors as Future\nCompatibility Warnings, since we were changing something that used to\ncompile into errors.</p>\n<h3><a href=\"https://blog.rust-lang.org/2019/11/01/nll-hard-errors.html#all-good-things-must-come-to-an-end-and-bad-ones,-too\" rel=\"noopener noreferrer\"></a>All good things must come to an end; and bad ones, too</h3>\n<p>Over time we have been slowly transitioning those future compatibility\nwarnings into errors, a bit at a time. About two months ago, we\ndecided that the time had come to finish the job. So, over the course\nof two PRs, we <a href=\"https://github.com/rust-lang/rust/pull/63565\" rel=\"noopener noreferrer\">converted all remaining warnings to errors</a> and\nthen <a href=\"https://github.com/rust-lang/rust/pull/64790\" rel=\"noopener noreferrer\">removed the old borrow checker implementation</a>.</p>\n<h3><a href=\"https://blog.rust-lang.org/2019/11/01/nll-hard-errors.html#what-this-means-for-you\" rel=\"noopener noreferrer\"></a>What this means for you</h3>\n<p><strong>If you are testing your package with nightly, then you should be\nfine.</strong> In fact, even if you build on stable, we always recommend that\nyou test your builds in CI with the nightly build, so that you can\nidentify upcoming issues early and report them to us.</p>\n<p><strong>Otherwise, you may want to check your dependencies.</strong> When we\ndecided to remove the old borrow checker, we also analyzed which\ncrates would stop compiling. For anything that seemed to be widely\nused, we made sure that there were newer versions of that crate\navailable that <em>do</em> compile (for the most part, this had all already\nhappened during the warning period). But if you have those older\nversions in your <code>Cargo.lock</code> file, and you are only using stable\nbuilds, then you may find that your code no longer builds once 1.40.0\nis released -- you will have to upgrade the dependency.</p>\n<p>The most common crates that were affected are the following:</p>\n<ul>\n<li><code>url</code> version 1.7.0 -- you can upgrade to 1.7.2, though you\'d be better off upgrading to 2.1.0</li>\n<li><code>nalgebra</code> version 0.16.13 -- you can upgrade to 0.16.14, though you\'d be better off upgrading to 0.19.0</li>\n<li><code>rusttype</code> version 0.2.0 to 0.2.3 -- you can upgrade to 0.2.4, though you\'d be better upgrading to 0.8.1</li>\n</ul>\n<p>You can find out which crates you rely upon using the <a href=\"https://crates.io/crates/cargo-tree\" rel=\"noopener noreferrer\">cargo-tree</a> command. If you find\nthat you <em>do</em> rely (say) on <code>url</code> 1.7.0, you can upgrade to 1.7.2 by executing:</p>\n<pre><code>cargo update --package url --precise 1.7.2\n</code></pre>\n<h3><a href=\"https://blog.rust-lang.org/2019/11/01/nll-hard-errors.html#want-to-learn-more\" rel=\"noopener noreferrer\"></a>Want to learn more?</h3>\n<p>If you\'d like to learn more about the kinds of bugs that were fixed --\nor if you are seeing errors in your code that you need to fix -- take\na look at this <a href=\"http://blog.pnkfx.org/blog/2019/06/26/breaking-news-non-lexical-lifetimes-arrives-for-everyone/\" rel=\"noopener noreferrer\">excellent blog post by Felix Klock</a>, which\ngoes into great detail.</p>\n",
        ),
        media_type: None,
        media_link: None,
        comments_link: None,
    },
    Post {
        id: -1,
        unique_id: "https://blog.rust-lang.org/2019/11/07/Async-await-stable.html",
        link: "https://blog.rust-lang.org/2019/11/07/Async-await-stable.html",
        title: "Async-await on stable Rust!",
        date: 2019-11-07T00:00:00Z,
        summary: None,
        content: Some(
            "<p><strong>On this coming Thursday, November 7, async-await syntax hits stable\nRust, as part of the 1.39.0 release.</strong> This work has been a long time\nin development -- the key ideas for zero-cost futures, for example,\nwere <a href=\"https://aturon.github.io/blog/2016/08/11/futures/\" rel=\"noopener noreferrer\">first proposed by Aaron Turon and Alex Crichton in\n2016</a>! -- and we are very proud of the end result. We believe\nthat Async I/O is going to be an increasingly important part of Rust\'s\nstory.</p>\n<p>While this first release of \"async-await\" is a momentous event, it\'s\nalso only the beginning. The current support for async-await marks a\nkind of \"Minimum Viable Product\" (MVP). We expect to be polishing,\nimproving, and extending it for some time.</p>\n<p>Already, in the time since <a href=\"https://blog.rust-lang.org/2019/09/30/Async-await-hits-beta.html\" rel=\"noopener noreferrer\">async-await hit beta</a>, we\'ve made\na lot of great progress, including making some <a href=\"https://blog.rust-lang.org/inside-rust/2019/10/11/AsyncAwait-Not-Send-Error-Improvements.html\" rel=\"noopener noreferrer\">key diagnostic\nimprovements</a> that help to make async-await errors far more\napproachable. To get involved in that work, check out\nthe <a href=\"https://rust-lang.github.io/compiler-team/working-groups/async-await/\" rel=\"noopener noreferrer\">Async Foundations Working Group</a>; if nothing else, you can\nhelp us by filing bugs about polish issues or by <a href=\"https://rust-lang.github.io/compiler-team/working-groups/async-await/#nominating-issues\" rel=\"noopener noreferrer\">nominating those\nbugs that are bothering you the most</a>, to help direct our\nefforts.</p>\n<p>Many thanks are due to the people who made async-await a reality. The\nimplementation and design would never have happened without the\nleadership of cramertj and withoutboats, the implementation and polish\nwork from the compiler side (davidtwco, tmandry, gilescope, csmoe),\nthe core generator support that futures builds on (Zoxc), the\nfoundational work on <code>Future</code> and the <code>Pin</code> APIs (aturon,\nalexcrichton, RalfJ, pythonesque), and of course the input provided by\nso many community members on RFC threads and discussions.</p>\n<h1><a href=\"https://blog.rust-lang.org/2019/11/07/Async-await-stable.html#major-developments-in-the-async-ecosystem\" rel=\"noopener noreferrer\"></a>Major developments in the async ecosystem</h1>\n<p>Now that async-await is approaching stabilization, all the major Async\nI/O runtimes are at work adding and extending their support for the\nnew syntax:</p>\n<ul>\n<li>the <a href=\"https://tokio.rs/\" rel=\"noopener noreferrer\">tokio</a> runtime <a href=\"https://tokio.rs/blog/2019-10-scheduler/\" rel=\"noopener noreferrer\">recently announced a number of scheduler\nimprovements</a>, and they are planning a stable release\nin November that supports async-await syntax;</li>\n<li>the <a href=\"https://async.rs/\" rel=\"noopener noreferrer\">async-std</a> runtime <a href=\"https://github.com/async-rs/async-std/releases\" rel=\"noopener noreferrer\">has been putting out weekly releases for the past few months</a>, and plans to make their\n1.0 release shortly after async-await hits stable;</li>\n<li>using <a href=\"https://docs.rs/crate/wasm-bindgen-futures/0.2.16\" rel=\"noopener noreferrer\">wasm-bindgen-futures</a>, you can even bridge Rust Futures with\n<a href=\"https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Using_promises\" rel=\"noopener noreferrer\">JavaScript promises</a>;</li>\n<li>the <a href=\"https://hyper.rs/\" rel=\"noopener noreferrer\">hyper library</a> has <a href=\"https://github.com/hyperium/hyper/issues/1805\" rel=\"noopener noreferrer\">migrated</a> to adopt standard Rust futures;</li>\n<li>the newly released 0.3.0 version of the <a href=\"https://crates.io/crates/futures\" rel=\"noopener noreferrer\">futures-rs library</a> includes support\nfor async-await;</li>\n<li>finally, async-await support is starting to become available in higher-level\n<a href=\"https://www.arewewebyet.org/topics/frameworks/\" rel=\"noopener noreferrer\">web frameworks</a> as well, as well as other interesting applications such\nas the <a href=\"https://docs.rs/futures-intrusive/0.2.0/futures_intrusive/\" rel=\"noopener noreferrer\"><code>futures_intrusive</code></a>\ncrate.</li>\n</ul>\n<h3><a href=\"https://blog.rust-lang.org/2019/11/07/Async-await-stable.html#async-await-a-quick-primer\" rel=\"noopener noreferrer\"></a>Async-await: a quick primer</h3>\n<p><em>(This section and the next are reproduced from the <a href=\"https://blog.rust-lang.org/2019/09/30/Async-await-hits-beta.html\" rel=\"noopener noreferrer\">\"Async-await hits\nbeta!\"</a> post.)</em></p>\n<p>So, what is async await? Async-await is a way to write functions that\ncan \"pause\", return control to the runtime, and then pick up from\nwhere they left off.  Typically those pauses are to wait for I/O, but\nthere can be any number of uses.</p>\n<p>You may be familiar with the async-await from JavaScript or C#. Rust\'s\nversion of the feature is similar, but with a few key differences.</p>\n<p>To use async-await, you start by writing <code>async fn</code> instead of <code>fn</code>:</p>\n<pre><code>async fn first_function() -&gt; u32 { .. }\n</code></pre>\n<p>Unlike a regular function, calling an <code>async fn</code> doesn\'t have any\nimmediate effect. Instead, it returns a <code>Future</code>. This is a suspended\ncomputation that is waiting to be executed. To actually <em>execute</em> the\nfuture, use the <code>.await</code> operator:</p>\n<pre><code>async fn another_function() {\n    // Create the future:\n    let future = first_function();\n    \n    // Await the future, which will execute it (and suspend\n    // this function if we encounter a need to wait for I/O): \n    let result: u32 = future.await;\n    ...\n}\n</code></pre>\n<p>This example shows the first difference between Rust and other\nlanguages: we write <code>future.await</code> instead of <code>await future</code>. This\nsyntax integrates better with Rust\'s <code>?</code> operator for propagating\nerrors (which, after all, are very common in I/O). You can simply\nwrite <code>future.await?</code> to await the result of a future and propagate\nerrors. It also has the advantage of making method chaining painless.</p>\n<h3><a href=\"https://blog.rust-lang.org/2019/11/07/Async-await-stable.html#zero-cost-futures\" rel=\"noopener noreferrer\"></a>Zero-cost futures</h3>\n<p>The other difference between Rust futures and futures in JS and C# is\nthat they are based on a \"poll\" model, which makes them <strong>zero\ncost</strong>. In other languages, invoking an async function immediately\ncreates a future and schedules it for execution: awaiting the future\nisn\'t necessary for it to execute. But this implies some overhead for\neach future that is created.</p>\n<p>In contrast, in Rust, calling an async function does not do any\nscheduling in and of itself, which means that we can compose a complex\nnest of futures without incurring a per-future cost. As an end-user,\nthough, the main thing you\'ll notice is that <strong>futures feel \"lazy\"</strong>:\nthey don\'t do anything until you await them.</p>\n<p>If you\'d like a closer look at how futures work under the hood, take a\nlook at <a href=\"https://rust-lang.github.io/async-book/02_execution/04_executor.html\" rel=\"noopener noreferrer\">the executor section</a> of the <a href=\"https://github.com/rust-lang/async-book\" rel=\"noopener noreferrer\">async book</a>, or watch the\n<a href=\"https://www.youtube.com/watch?v=skos4B5x7qE\" rel=\"noopener noreferrer\">excellent talk</a> that <a href=\"https://github.com/withoutboats\" rel=\"noopener noreferrer\">withoutboats</a> gave at <a href=\"https://rustlatam.org/\" rel=\"noopener noreferrer\">Rust LATAM 2019</a>\non the topic.</p>\n<h3><a href=\"https://blog.rust-lang.org/2019/11/07/Async-await-stable.html#summary\" rel=\"noopener noreferrer\"></a>Summary</h3>\n<p>We believe that having async-await on stable Rust is going to be a key\nenabler for a lot of new and exciting developments in Rust. If you\'ve\ntried Async I/O in Rust in the past and had problems -- particularly\nif you tried the combinator-based futures of the past -- you\'ll find\n<a href=\"http://aturon.github.io/tech/2018/04/24/async-borrowing/\" rel=\"noopener noreferrer\">async-await integrates much better with Rust\'s borrowing\nsystem</a>. Moreover, there are now a number of great runtimes and\nother libraries available in the ecosystem to work with.  So get out\nthere and build stuff!</p>\n",
        ),
        media_type: None,
        media_link: None,
        comments_link: None,
    },
    Post {
        id: -1,
        unique_id: "https://blog.rust-lang.org/2019/11/07/Rust-1.39.0.html",
        link: "https://blog.rust-lang.org/2019/11/07/Rust-1.39.0.html",
        title: "Announcing Rust 1.39.0",
        date: 2019-11-07T00:00:00Z,
        summary: None,
        content: Some(
            "<p>The Rust team is happy to announce a new version of Rust, 1.39.0. Rust is a programming language that is empowering everyone to build reliable and efficient software.</p>\n<p>If you have a previous version of Rust installed via rustup, getting Rust 1.39.0 is as easy as:</p>\n<pre><code>rustup update stable\n</code></pre>\n<p>If you don\'t have it already, you can <a href=\"https://www.rust-lang.org/install.html\" rel=\"noopener noreferrer\">get <code>rustup</code></a> from the appropriate page on our website, and check out the <a href=\"https://github.com/rust-lang/rust/blob/stable/RELEASES.md#version-1390-2019-11-07\" rel=\"noopener noreferrer\">detailed release notes for 1.39.0</a> on GitHub.</p>\n<h2><a href=\"https://blog.rust-lang.org/2019/11/07/Rust-1.39.0.html#whats-in-1.39.0-stable\" rel=\"noopener noreferrer\"></a>What\'s in 1.39.0 stable</h2>\n<p>The highlights of Rust 1.39.0 include <code>async</code>/<code>.await</code>, shared references to by-move bindings in <code>match</code> guards, and attributes on function parameters. Also, see the <a href=\"https://github.com/rust-lang/rust/blob/stable/RELEASES.md#version-1390-2019-11-07\" rel=\"noopener noreferrer\">detailed release notes</a> for additional information.</p>\n<h3><a href=\"https://blog.rust-lang.org/2019/11/07/Rust-1.39.0.html#the-await-is-over,-async-fns-are-here\" rel=\"noopener noreferrer\"></a>The <code>.await</code> is over, <code>async fn</code>s are here</h3>\n<p>Previously in Rust 1.36.0, <a href=\"https://blog.rust-lang.org/2019/07/04/Rust-1.36.0.html#the-future-is-here\" rel=\"noopener noreferrer\">we announced</a> that the <a href=\"https://doc.rust-lang.org/nightly/std/future/trait.Future.html\" rel=\"noopener noreferrer\"><code>Future</code></a> trait is here. Back then, we noted that:</p>\n<blockquote>\n<p>With this stabilization, we hope to give important crates, libraries, and the ecosystem time to prepare for <code>async</code> / <code>.await</code>, which we\'ll tell you more about in the future.</p>\n</blockquote>\n<p>A promise made is a promise kept. So in Rust 1.39.0, we are pleased to announce that <code>async</code> / <code>.await</code> is stabilized! Concretely, this means that you can define <code>async</code> functions and blocks and <code>.await</code> them.</p>\n<p>An <code>async</code> function, which you can introduce by writing <code>async fn</code> instead of <code>fn</code>, does nothing other than to return a <code>Future</code> when called. This <code>Future</code> is a suspended computation which you can drive to completion by <code>.await</code>ing it. Besides <code>async fn</code>, <code>async { ... }</code> and <code>async move { ... }</code> blocks, which act like closures, can be used to define \"async literals\".</p>\n<p>For more on the release of <code>async</code> / <code>.await</code>, read <a href=\"https://blog.rust-lang.org/2019/11/07/Async-await-stable.html\" rel=\"noopener noreferrer\">Niko Matsakis\'s blog post</a>.</p>\n<h3><a href=\"https://blog.rust-lang.org/2019/11/07/Rust-1.39.0.html#references-to-by-move-bindings-in-match-guards\" rel=\"noopener noreferrer\"></a>References to by-move bindings in <code>match</code> guards</h3>\n<p>When pattern matching in Rust, a variable, also known as a \"binding\", can be bound in the following ways:</p>\n<ul>\n<li>\n<p>by-reference, either immutably or mutably. This can be achieved explicitly e.g. through <code>ref my_var</code> or <code>ref mut my_var</code> respectively. Most of the time though, the binding mode will be inferred automatically.</p>\n</li>\n<li>\n<p>by-value -- either by-copy, when the bound variable\'s type implements <code>Copy</code>, or otherwise <strong><em>by-move</em></strong>.</p>\n</li>\n</ul>\n<p>Previously, Rust would forbid taking shared references to <strong><em>by-move</em></strong> bindings in the <code>if</code> guards of <code>match</code> expressions. This meant that the following code would be rejected:</p>\n<pre><code>fn main() {\n    let array: Box&lt;[u8; 4]&gt; = Box::new([1, 2, 3, 4]);\n\n    match array {\n        nums\n//      ---- `nums` is bound by move.\n            if nums.iter().sum::&lt;u8&gt;() == 10\n//                 ^------ `.iter()` implicitly takes a reference to `nums`.\n        =&gt; {\n            drop(nums);\n//          ----------- `nums` was bound by move and so we have ownership.\n        }\n        _ =&gt; unreachable!(),\n    }\n}\n</code></pre>\n<p><a href=\"https://github.com/rust-lang/rust/pull/63118/#issuecomment-522823925\" rel=\"noopener noreferrer\">With Rust 1.39.0</a>, the snippet above is now accepted by the compiler. We hope that this will give a smoother and more consistent experience with <code>match</code> expressions overall.</p>\n<h3><a href=\"https://blog.rust-lang.org/2019/11/07/Rust-1.39.0.html#attributes-on-function-parameters\" rel=\"noopener noreferrer\"></a>Attributes on function parameters</h3>\n<p>With Rust 1.39.0, attributes are now allowed on parameters of functions, closures, and function pointers. Whereas before, you might have written:</p>\n<pre><code>#[cfg(windows)]\nfn len(slice: &amp;[u16]) -&gt; usize {\n    slice.len()\n}\n#[cfg(not(windows))] \nfn len(slice: &amp;[u8]) -&gt; usize {\n    slice.len()\n}\n</code></pre>\n<p>...<a href=\"https://github.com/rust-lang/rust/pull/64010/\" rel=\"noopener noreferrer\">you can now</a>, more succinctly, write:</p>\n<pre><code>fn len(\n    #[cfg(windows)] slice: &amp;[u16], // This parameter is used on Windows.\n    #[cfg(not(windows))] slice: &amp;[u8], // Elsewhere, this one is used.\n) -&gt; usize {\n    slice.len()\n}\n</code></pre>\n<p>The attributes you can use in this position include:</p>\n<ol>\n<li>\n<p>Conditional compilation: <code>cfg</code> and <code>cfg_attr</code></p>\n</li>\n<li>\n<p>Controlling lints: <code>allow</code>, <code>warn</code>, <code>deny</code>, and <code>forbid</code></p>\n</li>\n<li>\n<p>Helper attributes used by procedural macro attributes applied to items.</p>\n<p>Our hope is that this will be used to provide more readable and ergonomic macro-based DSLs throughout the ecosystem.</p>\n</li>\n</ol>\n<h3><a href=\"https://blog.rust-lang.org/2019/11/07/Rust-1.39.0.html#borrow-check-migration-warnings-are-hard-errors-in-rust-2018\" rel=\"noopener noreferrer\"></a>Borrow check migration warnings are hard errors in Rust 2018</h3>\n<p>In the 1.35.0 release, <a href=\"https://blog.rust-lang.org/2019/07/04/Rust-1.36.0.html#nll-for-rust-2015\" rel=\"noopener noreferrer\">we announced</a> that NLL had come to Rust 2015 after first being released for Rust 2018 in <a href=\"https://blog.rust-lang.org/2018/12/06/Rust-1.31-and-rust-2018.html#non-lexical-lifetimes\" rel=\"noopener noreferrer\">1.31</a>.</p>\n<p>As noted in the 1.35.0 release, the old borrow checker had some bugs which would allow memory unsafety. These bugs were fixed by the NLL borrow checker. As these fixes broke some stable code, we decided to gradually phase in the errors by checking if the old borrow checker would accept the program and the NLL checker would reject it. If so, the errors would instead become warnings.</p>\n<p>With Rust 1.39.0, these warnings are now <a href=\"https://github.com/rust-lang/rust/pull/63565\" rel=\"noopener noreferrer\">errors in Rust 2018</a>.\nIn the next release, Rust 1.40.0, <a href=\"https://github.com/rust-lang/rust/pull/64221\" rel=\"noopener noreferrer\">this will also apply to Rust 2015</a>, which will finally allow us to <a href=\"https://github.com/rust-lang/rust/pull/64790\" rel=\"noopener noreferrer\">remove the old borrow checker</a>, and keep the compiler clean.</p>\n<p>If you are affected, or want to hear more, read <a href=\"https://blog.rust-lang.org/2019/11/01/nll-hard-errors.html\" rel=\"noopener noreferrer\">Niko Matsakis\'s blog post</a>.</p>\n<h3><a href=\"https://blog.rust-lang.org/2019/11/07/Rust-1.39.0.html#more-const-fns-in-the-standard-library\" rel=\"noopener noreferrer\"></a>More <code>const fn</code>s in the standard library</h3>\n<p>With Rust 1.39.0, the following functions became <code>const fn</code>:</p>\n<ul>\n<li><a href=\"https://doc.rust-lang.org/std/vec/struct.Vec.html#method.new\" rel=\"noopener noreferrer\"><code>Vec::new</code></a>, <a href=\"https://doc.rust-lang.org/std/string/struct.String.html#method.new\" rel=\"noopener noreferrer\"><code>String::new</code></a>, and <a href=\"https://doc.rust-lang.org/std/collections/linked_list/struct.LinkedList.html#method.new\" rel=\"noopener noreferrer\"><code>LinkedList::new</code></a></li>\n<li><a href=\"https://doc.rust-lang.org/std/primitive.str.html#method.len\" rel=\"noopener noreferrer\"><code>str::len</code></a>, <a href=\"https://doc.rust-lang.org/std/primitive.slice.html#method.len\" rel=\"noopener noreferrer\"><code>[T]::len</code></a>, and <a href=\"https://doc.rust-lang.org/std/primitive.str.html#method.as_bytes\" rel=\"noopener noreferrer\"><code>str::as_bytes</code></a></li>\n<li><a href=\"https://doc.rust-lang.org/std/primitive.i8.html#method.abs\" rel=\"noopener noreferrer\"><code>abs</code></a>, <a href=\"https://doc.rust-lang.org/std/primitive.i8.html#method.wrapping_abs\" rel=\"noopener noreferrer\"><code>wrapping_abs</code></a>, and <a href=\"https://doc.rust-lang.org/std/primitive.i8.html#method.overflowing_abs\" rel=\"noopener noreferrer\"><code>overflowing_abs</code></a></li>\n</ul>\n<h3><a href=\"https://blog.rust-lang.org/2019/11/07/Rust-1.39.0.html#additions-to-the-standard-library\" rel=\"noopener noreferrer\"></a>Additions to the standard library</h3>\n<p>In Rust 1.39.0 the following functions were stabilized:</p>\n<ul>\n<li><a href=\"https://doc.rust-lang.org/std/pin/struct.Pin.html#method.into_inner\" rel=\"noopener noreferrer\"><code>Pin::into_inner</code></a></li>\n<li><a href=\"https://doc.rust-lang.org/std/time/struct.Instant.html#method.checked_duration_since\" rel=\"noopener noreferrer\"><code>Instant::checked_duration_since</code></a> and <a href=\"https://doc.rust-lang.org/std/time/struct.Instant.html#method.saturating_duration_since\" rel=\"noopener noreferrer\"><code>Instant::saturating_duration_since</code></a></li>\n</ul>\n<h3><a href=\"https://blog.rust-lang.org/2019/11/07/Rust-1.39.0.html#other-changes\" rel=\"noopener noreferrer\"></a>Other changes</h3>\n<p>There are other changes in the Rust 1.39.0 release: check out what changed in <a href=\"https://github.com/rust-lang/rust/blob/stable/RELEASES.md#version-1390-2019-11-07\" rel=\"noopener noreferrer\">Rust</a>, <a href=\"https://github.com/rust-lang/cargo/blob/master/CHANGELOG.md#cargo-139-2019-11-07\" rel=\"noopener noreferrer\">Cargo</a>, and <a href=\"https://github.com/rust-lang/rust-clippy/blob/master/CHANGELOG.md#rust-139\" rel=\"noopener noreferrer\">Clippy</a>.</p>\n<p>Please also see the <a href=\"https://github.com/rust-lang/rust/blob/stable/RELEASES.md#compatibility-notes\" rel=\"noopener noreferrer\">compatibility notes</a> to check if you\'re affected by those changes.</p>\n<h2><a href=\"https://blog.rust-lang.org/2019/11/07/Rust-1.39.0.html#contributors-to-139.0\" rel=\"noopener noreferrer\"></a>Contributors to 1.39.0</h2>\n<p>Many people came together to create Rust 1.39.0. We couldn\'t have done it\nwithout all of you. <a href=\"https://thanks.rust-lang.org/rust/1.39.0/\" rel=\"noopener noreferrer\">Thanks!</a></p>\n",
        ),
        media_type: None,
        media_link: None,
        comments_link: None,
    },
    Post {
        id: -1,
        unique_id: "https://blog.rust-lang.org/2019/12/03/survey-launch.html",
        link: "https://blog.rust-lang.org/2019/12/03/survey-launch.html",
        title: "Launching the 2019 State of Rust Survey",
        date: 2019-12-03T00:00:00Z,
        summary: None,
        content: Some(
            "<p>It\'s that time again! Time for us to take a look at how the Rust project is doing, and what we should plan for the future. The Rust Community Team is pleased to announce our <a href=\"https://docs.google.com/forms/d/1iGnf8Mmf4JRggOJ3E7iZlBLsgeLxIYzaI1caiFHQ6OQ/viewform\" rel=\"noopener noreferrer\">2019 State of Rust Survey</a>! Whether or not you use Rust today, we want to know your opinions. Your responses will help the project understand its strengths and weaknesses and establish development priorities for the future.</p>\n<p>Completing this survey should take about 10–15 minutes and is anonymous unless you choose to give us your contact information. We will be accepting submissions until December 16th, and we will write up our findings a month or so afterwards to <a href=\"https://blog.rust-lang.org/\" rel=\"noopener noreferrer\">blog.rust-lang.org</a>. You can also check out <a href=\"https://blog.rust-lang.org/2018/11/27/Rust-survey-2018.html\" rel=\"noopener noreferrer\">last year’s results</a>.</p>\n<ul>\n<li><a href=\"https://docs.google.com/forms/d/1iGnf8Mmf4JRggOJ3E7iZlBLsgeLxIYzaI1caiFHQ6OQ/viewform\" rel=\"noopener noreferrer\">English</a></li>\n<li><a href=\"https://wj.qq.com/s2/5080757/5237\" rel=\"noopener noreferrer\">Simplified Chinese</a></li>\n<li><a href=\"https://docs.google.com/forms/d/e/1FAIpQLSfMugzbkuwY_x2sKm1Jt2Y569ULG2mLE_hOzZFIUpjO1vXmzg/viewform?hl=zh-TW\" rel=\"noopener noreferrer\">Traditional Chinese</a></li>\n<li><a href=\"https://docs.google.com/forms/d/e/1FAIpQLSeiIlKDo-3PGS4yxAQ2PwIL1NmPSua0AnktgaaI2ZWa1iOC2g/viewform?hl=fr\" rel=\"noopener noreferrer\">French</a></li>\n<li><a href=\"https://docs.google.com/forms/d/e/1FAIpQLScjz_tD9UQQPbxeiQVMbD5RIHvoob5Du9VQp8yjatfcE6CuCw/viewform?hl=de\" rel=\"noopener noreferrer\">German</a></li>\n<li><a href=\"https://docs.google.com/forms/d/e/1FAIpQLSdtFimO_-WL8Ja7PdG0MgLJJKIau9qOtBZLLca9TeK1tiA19g/viewform?hl=it\" rel=\"noopener noreferrer\">Italian</a></li>\n<li><a href=\"https://docs.google.com/forms/d/e/1FAIpQLSe-AakTxBDKSBZUk1zTqvZ749M-wAPHUU45Pnj12-0-Y_Qxaw/viewform?hl=jp\" rel=\"noopener noreferrer\">Japanese</a></li>\n<li><a href=\"https://docs.google.com/forms/d/e/1FAIpQLScPqYek5LKDyLBnB3NM3X5YTLjLolIjc_j0SFewAzBgUZd5Wg/viewform?hl=ko\" rel=\"noopener noreferrer\">Korean</a></li>\n<li><a href=\"https://docs.google.com/forms/d/e/1FAIpQLSdyZ6Xg7d-VIJpRCdLaTocSYOWd1eDI6VryS954fl_ESJYx4Q/viewform?hl=pl\" rel=\"noopener noreferrer\">Polish</a></li>\n<li><a href=\"https://docs.google.com/forms/d/e/1FAIpQLScIZI8qtS1BMBaOIIirwp_NngKWgr_GTnow6Fp32M8_IySaPw/viewform?hl=pt\" rel=\"noopener noreferrer\">Portuguese</a></li>\n<li><a href=\"https://docs.google.com/forms/d/e/1FAIpQLSd6nhdpmopSM_3xikVEDnHAem1yKq76ymQx0nINUFHqkqC-LA/viewform?hl=ru\" rel=\"noopener noreferrer\">Russian</a></li>\n<li><a href=\"https://docs.google.com/forms/d/e/1FAIpQLSekNvJgid_RrixnHm2aOAqLf4sCFUVOVVakTh97ILLNyTsQSA/viewform?hl=es\" rel=\"noopener noreferrer\">Spanish</a></li>\n<li><a href=\"https://docs.google.com/forms/d/e/1FAIpQLSdw5T3chMuQi72QiMk_Nu6Kb44qSIRKrjxcHBQVVK6RpebpvQ/viewform?hl=sv\" rel=\"noopener noreferrer\">Swedish</a></li>\n<li><a href=\"https://docs.google.com/forms/d/e/1FAIpQLSe5eEQxuf38XQEKPUXjdCgsB8WinsnC2NpA17Bq1WyPkX8TXg/viewform?hl=vn\" rel=\"noopener noreferrer\">Vietnamese</a></li>\n</ul>\n<p>(If you speak multiple languages, please pick one)</p>\n<p>Please help us spread the word by sharing the survey link on your social network feeds, at meetups, around your office, and in other communities.</p>\n<p>If you have any questions, please see our <a href=\"https://forge.rust-lang.org/community/survey-faq.html\" rel=\"noopener noreferrer\">frequently asked questions</a> or email the Rust Community team at <a href=\"mailto:community-team@rust-lang.org\" rel=\"noopener noreferrer\">community-team@rust-lang.org</a>.</p>\n<p>Finally, we wanted to thank everyone who helped develop, polish, and test the survey. In particular we\'d like to thank <a href=\"https://isu.edu/cmp/faculty-and-staff/facultyandstaff/d-jasun-carr.html\" rel=\"noopener noreferrer\">Dr. Jasun Carr</a>, for providing their expertise in communication processes with helping to create this year\'s survey, and all of the volunteers who worked to provide all of the translations available this year.</p>\n",
        ),
        media_type: None,
        media_link: None,
        comments_link: None,
    },
]
