Rust is een programmeertaal bedacht door Graydon Hoare en oorspronkelijk ontwikkeld door Mozilla. Het is deels geïnspireerd op de programmeertaal C, maar kent syntactische en semantische verschillen. Het focust op veiligheid en beoogt moderne computersystemen efficiënter te benutten. Het wordt ingezet door onder ander Cloudflare, OVH, Mozilla, Deliveroo, Coursera, AppSignal en Threema. Versie 1.30 is onlangs uitgebracht met de volgende aankondiging: Announcing Rust 1.30 The Rust team is happy to announce a new version of Rust, 1.30.0. Rust is a systems programming language focused on safety, speed, and concurrency. If you have a previous version of Rust installed via rustup, getting Rust 1.30.0 is as easy as: $ rustup update stable If you don?t have it already, you can get rustup from the appropriate page on our website, and check out the detailed release notes for 1.30.0 on GitHub. What?s in 1.30.0 stable Rust 1.30 is an exciting release with a number of features. On Monday, expect another blog post asking you to check out Rust 1.31?s beta; Rust 1.31 will be the first release of ?Rust 2018.? For more on that concept, please see our previous post ?What is Rust 2018?. Procedural Macros Way back in Rust 1.15, we announced the ability to define ?custom derives.? For example, with serde_derive, you could #[derive(Serialize, Deserialize, Debug)] struct Pet { name: String, } And convert a Pet to and from JSON using serde_json because serde_derive defined Serialize and Deserialize in a procedural macro. Rust 1.30 expands on this by adding the ability to define two other kinds of advanced macros, ?attribute-like procedural macros? and ?function-like procedural macros.? Attribute-like macros are similar to custom derive macros, but instead of generating code for only the #[derive] attribute, they allow you to create new, custom attributes of your own. They?re also more flexible: derive only works for structs and enums, but attributes can go on other places, like functions. As an example of using an attribute-like macro, you might have something like this when using a web application framework: #[route(GET, “/”)] fn index() { This #[route] attribute would be defined by the framework itself, as a procedural macro. Its signature would look like this: #[proc_macro_attribute] pub fn route(attr: TokenStream, item: TokenStream) -> TokenStream { Here, we have two input TokenStreams: the first is for the contents of the attribute itself, that is, the GET, “/” stuff. The second is the body of the thing the attribute is attached to, in this case, fn index() {} and the rest of the function?s body. Function-like macros define macros that look like function calls. For example, an sql! macro: let sql = sql!(SELECT * FROM posts WHERE id=1); This macro would parse the SQL statement inside of it and check that it?s syntactically correct. This macro would be defined like this: #[proc_macro] pub fn sql(input: TokenStream) -> TokenStream { This is similar to the derive macro?s signature: we get the tokens that are inside of the parentheses and return the code we want to generate. use and macros You can now bring macros into scope with the use keyword. For example, to use serde-json?s json macro, you used to write: #[macro_use] extern crate serde_json; let john = json!({ “name”: “John Doe”, “age”: 43, “phones”: [ “+44 1234567”, “+44 2345678” ] }); But now, you?d write extern crate serde_json; use serde_json::json; let john = json!({ “name”: “John Doe”, “age”: 43, “phones”: [ “+44 1234567”, “+44 2345678” ] }); This brings macros more in line with other items and removes the need for macro_use annotations. Finally, the proc_macro crate is made stable, which gives you the needed APIs to write these sorts of macros. It also has significantly improved the APIs for errors, and crates like syn and quote are already using them. For example, before: #[derive(Serialize)] struct Demo { ok: String, bad: std::thread::Thread, } used to give this error: error[E0277]: the trait bound `std::thread::Thread: _IMPL_SERIALIZE_FOR_Demo::_serde::Serialize` is not satisfied –> src/main.rs:3:10 | 3 | #[derive(Serialize)] | ^^^^^^^^^ the trait `_IMPL_SERIALIZE_FOR_Demo::_serde::Serialize` is not implemented for `std::thread::Thread` Now it will give this one: error[E0277]: the trait bound `std::thread::Thread: serde::Serialize` is not satisfied –> src/main.rs:7:5 | 7 | bad: std::thread::Thread, | ^^^ the trait `serde::Serialize` is not implemented for `std::thread::Thread` Module system improvements The module system has long been a pain point of new Rustaceans; several of its rules felt awkward in practice. These changes are the first steps we?re taking to make the module system feel more straightforward. There?s two changes to use in addition to the aforementioned change for macros. The first is that external crates are now in the prelude, that is: // old let json = ::serde_json::from_str(“…”); // new let json = serde_json::from_str(“…”); The trick here is that the ?old? style wasn?t always needed, due to the way Rust?s module system worked: extern crate serde_json; fn main() { // this works just fine; we’re in the crate root, so `serde_json` is in // scope here let json = serde_json::from_str(“…”); } mod foo { fn bar() { // this doesn’t work; we’re inside the `foo` namespace, and `serde_json` // isn’t declared there let json = serde_json::from_str(“…”); } // one option is to `use` it inside the module use serde_json; fn baz() { // the other option is to use `::serde_json`, so we’re using an absolute path // rather than a relative one let json = ::serde_json::from_str(“…”); } } Moving a function to a submodule and having some of your code break was not a great experience. Now, it will check the first part of the path and see if it?s an extern crate, and if it is, use it regardless of where you?re at in the module hierarchy. Finally, use also supports bringing items into scope with paths starting with crate: mod foo { pub fn bar() { // … } } // old use ::foo::bar; // or use foo::bar; // new use crate::foo::bar; The crate keyword at the start of the path indicates that you would like the path to start at your crate root. Previously, paths specified after use would always start at the crate root, but paths referring to items directly would start at the local path, meaning the behavior of paths was inconsistent: mod foo { pub fn bar() { // … } } mod baz { pub fn qux() { // old ::foo::bar(); // does not work, which is different than with `use`: // foo::bar(); // new crate::foo::bar(); } } Once this style becomes widely used, this will hopefully make absolute paths a bit more clear and remove some of the ugliness of leading ::. All of these changes combined lead to a more straightforward understanding of how paths resolve. Wherever you see a path like a::b::c someplace other than a use statement, you can ask:
