Rust 2019 wish list

As with any wish list, it started short and then grew a bit.

There are three sections Community, Technical and Ethics and I hope it is not too lengthy.

Rust 2019 wish list

Community

Rust Family

Have a discussion towards the goals of a Rust Family group. What it should do and not do.

One goal could be to reduce the load of the people organizing the conferences. How would we do that?

Maybe we can have enough people organizing so that one single person has to organize one conference per year and can visit another one in the same time. During that time one would be available to help others on small tasks on short notice.

Small Winter or Spring Retreat

In the RustFest team we were talking about having a physical meet after the last conference. If you were interested please email (@dns2utf8 at this domain) me so we can do an event with maybe 20 to 30 people.

If this hits a nerve we could grow it into an annual event that maybe also travels around or is run in parallel. As soon as it is run in parallel we can then start thinking about stuff like having a video synchronized wall to virtually connect two or more spaces.

Camp in Summer

I would love to have a place to meet other Rust developers and talk in a impl days like format.

One possibility is to attend CCC Camp see the 2015 wiki.

Another would be to have our own event. This way would have the advantage that we could offer a SOS-Stage (self organized sessions) that we could fill with bands in the evening.

Survey and Engagement

On of the pain points that people told me at 35c3 was this. They felt very far away from the development of the language and at the same time did not feel the need to be included very much. When I told them about the annual user survey the echo of 50% of people attending the workshop "Rust in the year 2025" was: What survey? I would like to give it more attention in the following months.

There were many good points, see the protocol here. My personal favorites are the following:

  • Keep Rust focused
    • Set non-goals
    • limit scope and keep it learn-able to new users
  • General feedback is hard
    • RFCs
      • if known: too time consuming
      • not known: to new people, this may not be a problem
    • Surveys - not known to more than 50%
  • Variadic tuples
  • Const generics and functions

Technical

recognize loop breaking return

The compiler should learn about the case where an early return prevents use after move.

fn ask_user<T>(query: &str, fallback: Option<T>) -> T
        where T: std::fmt::Debug + std::str::FromStr
            , T::Err: std::fmt::Debug {
    let query = if let Some(fallback) = &fallback {
        format!("{} [default: {:?}]: ", query, fallback)
    } else {
        format!("{}: ", query)
    };
    let mut input = String::new();
    loop {
        print!("{}", query);
        std::io::stdout().flush().expect("unable to flush stdout");
        input.clear();
        std::io::stdin().read_line(&mut input).expect("unable to read from stdin");
        let input = input.trim();
        if let Some(fallback) = &fallback {
            if input == "" {
                return *fallback;
            }
        }
        match input.parse() {
            Ok(r) => { return r; }
            Err(e) => {
                println!("    (EE) input error {:?}", e);
            }
        }
    }
}

Currently the error message points to rustc --explain E0507. The explanation talks about RefCell and it's usage, not loops and returns.

After talking to Mutabah on IRC we found the problem: the unconditional move. So flipping the checks if input == "" and if let Some(fallback) = fallback solves the use after move problem.

fn ask_user<T>(query: &str, fallback: Option<T>) -> T
        where T: std::fmt::Debug + std::str::FromStr
            , T::Err: std::fmt::Debug {
    let query = if let Some(fallback) = &fallback {
        format!("{} [default: {:?}]: ", query, fallback)
    } else {
        format!("{}: ", query)
    };
    let mut input = String::new();
    loop {
        print!("{}", query);
        std::io::stdout().flush().expect("unable to flush stdout");
        input.clear();
        std::io::stdin().read_line(&mut input).expect("unable to read from stdin");
        let input = input.trim();
        if input == "" {
            if let Some(fallback) = fallback {
                return fallback;
            }
        }
        match input.parse() {
            Ok(r) => { return r; }
            Err(e) => {
                println!("    (EE) input error {:?}", e);
            }
        }
    }
}

Offline Support

Have a documented cargo flag to run offline.

As a bonus, cargo could ask the operating system or it's services like NetworkManager if there is a connection at all.

A Grammar

Find the time to implement a complete grammar for rust and test it with rustc.

Ethics

To make it short. There are ethics in the field of Rust.

Rust like any technology is sometimes good and sometimes bad. We should start thinking about the idea of areas. Areas where we do not want to contribute to progress and others where we see a need for progress that we are currently unable to work on.

I wish for next year to have more majored ideas than “This is interesting so I will spend a weekend on it” or “I really need this right now so I will mix up something quick”.

Documentation as Enlightenment

Make more crates usable and accessible by keeping everything documented on this high level or higher.

I wish for more people to lift others onto the shoulders of giants.

Summary

Rust enables us to do more with computers with less overhead and therefore less energy. It would be a shame if we lost these energy savings to the rebound effect.

In that regard I wish for the ability to have automatic fallbacks in crates or the compiler if the running machine does not support more recent feature.

To summarize there is a lot to do. And we should celebrate milestones or kilometer-stones as we will say in the future. Prepare something for Rust's fourth birthday.

links

social