👇 Is how I feel using Rust in 2018! 😂

Credits for the animated ferris/header image goes to http://www.rustacean.net/

Rustaceans may already be familiar with Read Rust 2018. It's really awesome to see all blog posts by other people. I'm yet to finish reading all of them :P

Adding to the chain of wishlist and suggestions for Rust's roadmap for 2018, here's my wishlist:

Building trust in using Rust for safety-critical applications

The efforts on frameworks such as tokio, futures, and backend targets such as wasm is greatly appreciated. The real use case however, where Rust is really needed is in IOT/Embedded space.

Thoughts on why I think so:

The embedded systems domain is mostly dominated by C. Now with C compilers' assumptive behaviour and the various undefined behaviour that you can cause with it, organizations had to come up with coding standards like (MISRA_C in automotive industry) to ensure reliability/safety in such applications.

With Rust; those guidelines mentioned in these standards are mostly covered because of the guarantees provided by the type system (except the case when doing FFI). Rust would be way more valued in embedded world. In 2018, it is time that the community make efforts to curate good quality crates for embedded/IOT space.

Currenly few people are involved in progressing the story of Rust on microcontrollers. A big shout-out to japaric for his contributions in this space. Currently his focus are on ARM Cortex-M microcontrollers. There are already good quality crates embedded-hal, f3, cortex-m-quickstart; we need more like them for other platforms too. We need more people writing about using Rust for microcontrollers this year. To make people aware on current state of things in this space, meetups can organize hardware hacking sessions using Rust and encourage them to contribute to related crates. Rust should really be the recommended language for IOT based products and embedded systems. I would like to link the discussion thread for this made by japaric: Rust for embedded-dev, where are we and what's missing

Also, I don't know much about the current state of things in formal verification of the language; but would like to see activity/progress being made in that area too. There is one by Ralf Jung. It is also desired that the language team progresses towards a standard specification of the language, similar to standards like ECMA standard and C++ ISO standard.

On Async I/O

I would also like to see async-await sugars to be usable on stable Rust this year. Also a cookbook explaining future and tokio abstractions would be appreciated. I also feel that the futures crate could be improved on error messages. Having worked with it, I feel the error messages are unreadable and sometimes diametric. For example:

fn main() {
    let ok_future = ok::<_,()>(());
    let composed = ok_future.then(|e| {
        ok::<_,()>(true)
    });

    let mut core = Core::new().unwrap();
    let handle = core.handle();
    handle.spawn(composed);
}

reports error as :

type mismatch resolving `<futures::Join<futures::Then<futures::FutureResult<(), ()>, futures::FutureResult<bool, ()>, [closure@src/main.rs:14:35: 16:6]>, futures::FutureResult<u32, ()>> as futures::Future>::Item == ()`
  --> src/main.rs:21:12
   |
21 |     handle.spawn(joined);
   |            ^^^^^ expected bool, found ()
   |
   = note: expected type `bool`
              found type `()`

Ideally, the error message given by compiler should be the other way around i.e., It should report: the expected type is (), but found type is bool.

It's easy to figure out the issue on your own in trivial cases like above, but becomes difficul to reason about when complex return types are involved. Also the verbose representation of composed futures type in "type mismatch ..." statement above here can be shortened; I don't know, maybe by compiler plugins. For a new comer, these errors become overwhelming and gives an impression that the library is hard to work with. Also for returning futures we really need the impl trait RFC to land on stable as most of the time we need to return boxes of futures which adds overhead.

Syntax enhancements:

Small things: Similar to what we have for vec![] provided by the standard library, other container types can also benefit from shorthands implemented as macros like map!{}, bmap!{}, set!{}. There are already macro crates for doing this but the standard library can already provide them just like it has for vec![]. The fact that these crates exist outside the offical ecosystem means that there's a use case for it. These are small things but can greatly improve coding experience.

Idea of data structs/classes - This is taken from Kotlin's data classes, where you can prefix a class with data keyword and your class automatically gets a default all parameter constructors and getters and setters too. In Rust, this can translate to a #[derive(new, getter, setter)] or a #[derive(DataStruct)] on top of struct or enum declarations. There are times we just want to have bunch of fields together in a struct and just access or set them later. This abstraction can become really handy in minimizing boilerplate code.

String template literals: It becomes quite verbose to use format!("Foo{}","Bar") everytime we want to use interpolated strings. Something like \`Foo{bar}\ will be awesome if possible. There have been discussion on this and also an issue #1250. Also slice patterns like let &[a,b,_,_,_] = &[1,2,3,4,5] should be stable.

Default argument methods - Methods with default arguments eliminate the need to provide a seperate set method on structs. Relevant issue #323. There are many others and would possibly make this post long if I list here.

On tooling and infrastructure:

I want to talk about the cross compilation tooling. There is xargo which makes it easy to pull source of Rust's standard library and helps to cross compile crates to other platforms. xargo's functionality just be integrated within cargo itself. This will make cargo more versatile tool on the cross compilation space.

Guides for intermediate programmers

Last year the community made efforts for curating newbies to Rust. This year should be for intermediate rustaceans who want to upgrade their Rust skills. We want better examples/patterns/cookbook describing when lifetime annotations are really necessary in code. Guides on using the type systems well to encode semantics at compile time into the program. Tutorials on implementing non-trivial data structures and container types and how it compares to other languages. There is already a beautiful one by alexis but we need more like that.

Tooling for Benchmarking, profiling Rust programs

The profiling story also needs to improve this year. There have been good efforts to integrate existing tools within cargo such as cargo-profiler but they need to support Windows and macOS as well.

More macro guides

Macros are really useful but the complex ones are harder to write for newbies. To encourage more people to use it, I would like to see a dedicated book for macros for coding idioms and best practices/gotchas for intermediate programmers. These days crates seem to be using macros heavily (looking at rocket) and someone attempting to understand and contribute to the macro code has to patiently read the cryptic patterns or even experiment the macro code in isolation to make sense of what it is actually doing. Blog post like Julia's post are really appreciated.

Bringing more people to Rust compiler hacking

This post really got me excited. With such efforts Rust community is making great strides in democratizing the knowledge of systems programming topics such as compilers, operating systems, garbage collectors, and other low level concepts to the masses which before, was only limited to a few wizards. A big shoutout to niko and compiler team for progressing this in 2018.

Will close it here today, wish you all a happy new year! :)

Want to share feedback, or discuss further ideas? Feel free to leave a comment here! Please follow Rust's code of conduct. This comment thread directly maps to a discussion on GitHub, so you can also comment there if you prefer.