Credits for the animated ferris/header image goes to http://www.rustacean.net/.
👇 is how i feel using rust in 2018 ! 😂 Dancing Ferris

Cool; So finally got time to write this !

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 confidence in using Rust for safety-critical applications:

The efforts being made such as tokio, futures, and wasm backend in rust ecosystem for servers and the web is greatly appreciated; But the real use case where rust is really needed is in IOT/Embedded space.
A point i would like to make on why is it so: Today the embedded space is mostly dominated by C. Now with C compilers’ assumptive behaviour and the various undefined behaviour that you can cause with it, organizations have 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 so those standards are not really needed (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 is already 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 session 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 all these 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 spec; 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 lang team progresses towards a standard specification of the language, similar to ECMA standard, ISO C++ standard.

On Async IO

I would also like to see async-await sugars to be usable on stable rust this year. Also a cookbook for 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 note given by compiler should be the other way around i.e, It should report that: the expected type is (), but found type is bool. It’s easy to figure out on your own in simpler cases like this, but becomes uneasy to understand when complex return types are involved. Also the verbose representation of composed futures type in “type mismatch ...” statement above here can be shortened; I dont’t know, maybe by compiler plugins. For a new comer these errors becomes 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![] already provided by standard library, other container types can also benefit from macros like map!{}, bmap!{}, set!{}. There are already macro crates for doing this but the stdlib can already provide them just like it has for vec![]. Often people create their own similar macro for their projects and later these become harder to maintain. These are small things but can greatly improve coding experience.

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

String template literals: It becomes really verbose to use format!(“Foo{}”,“Bar”) everytime when we want interpolated strings. Something like `Foo{bar}` will be awesome if possible. There have been discussion on this https://mail.mozilla.org/pipermail/rust-dev/2012-February/001346.html and also an issue #1250. Also slice patterns like let &[a,b,_,_,_] = &[1,2,3,4,5] should be stable.

Default argument methods - Method 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 stdlib and helps to cross compile rust crates to other platforms. xargo’s functionality can be just 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 lang. 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 containers 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 a person 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.

So yeah thats about it, stay rusty and wish you all a happy new year ! :)

PS: Please correct by commenting if any mistakes/updates.

comments powered by Disqus