Rust's 2019 Roadmap

We have the core team to provide overall oversight over all of these teams to ensure things are coherent.

It’s not the best language ever, but it is better at this point than similar languages such as Python or Ruby (good async, good type system, good module system, no decades-long versioning crisis).

The last part of your comment hints that your objections to Rust’s governance may be more political than language design related.

Another earlier example of successful incremental technology was the Java compiler in Eclipse.

I'm sure there are academic efforts as well, but don't know as much about these.

Note that “incremental parsing” is a nice to have, but is not required for IDEs. What is required are lazy name resolution and lazy type inference.

A few exceptions are that async/await was not finished, but that is not for lack of trying (from what I gather), so this is excusable. The 2018 roadmap did correctly indicate what would be worked on throughout most of 2018, even if some things took longer than expected.

I think a roadmap is only a failure if it gets ignored and none of the stuff mentioned in the roadmap gets worked on at all. I've been at some dysfunctional startups like this, for a time the company tries to rally the developers, a roadmap is made, people feel good, the next week the CEO decides to go in a completely different direction and then things are back to being dysfunctional, and nobody ever thinks about the roadmap again.

It does seem like "macros 2.0" might have fallen through the cracks? As far as I know they were never finished and I haven't heard much about their progress.

Out of the stuff called out there, everything other than async/await shipped, most in total, some in part. Custom allocators didn't fully ship, only the global custom allocators did so far. Hygene didn't ship for macros 2.0, but the non-hygenic ones did.

https://github.com/rust-lang/rfcs/blob/master/text/2657-road...

I'm curious what makes you think that? Culturally, I feel like there's been some general backlash to the gratuitous IoT-ification of every aspect of our lives, from a privacy perspective, a fragility perspective, and a "using apps to control everything isn't actually convenient" perspective: https://twitter.com/internetofshit

For those interested, check out Jorge Aparicio's (japaric) RTFM2 series:

http://blog.japaric.io/rtfm-v2/

(in particular the sections titled "Preemption" and "Critical sections and Threshold")

It is not obvious to me what more can the Rust team do here; it would seem like the ball is in the vendors court (or whoever counts as "major player"). Plenty of the groundwork has been already accomplished, and the embed-wg continues on their good work but they can't just conjure vendor support out of thin air

There is a documentation team, I am the lead, and I tend to write the posts on the blog. This one was significantly written by Niko as well.

It's well known and long standing problem. Rust the Language allows proper enum, but Rust the Compiler cannot pack enum into single value, as in C.

Example:

  #[repr(C)]
  #[repr(i32)]
  #[derive(Debug)]
  #[allow(dead_code)]
  enum E {
    A,
    B,
    C,
    Unlabeled(i32),
  }

  fn main() {
    {
        let v: E = unsafe { std::mem::transmute::<(i32,i32), E>((0,0)) };
        println!("v = {:?}", v)
    }
    {
        let v: E = unsafe { std::mem::transmute::<(i32,i32), E>((1,1)) };
        println!("v = {:?}", v)
    }
    {
        let v: E = unsafe { std::mem::transmute::<(i32,i32), E>((2,2)) };
        println!("v = {:?}", v)
    }
    {
        let v: E = unsafe { std::mem::transmute::<(i32,i32), E>((3,3)) };
        println!("v = {:?}", v)
    }
    {
        let v: E = unsafe { std::mem::transmute::<(i32,i32), E>((3,55)) };
        println!("v = {:?}", v)
    }
    {
        let v: E = unsafe { std::mem::transmute::<(i32,i32), E>((55,55)) };
        println!("v = {:?}", v)
    }
  }

  v = A
  v = B
  v = C
  v = Unlabeled(3)
  v = Unlabeled(55)
  v = A

Also, this doesn't have anything to do with Windows support that I can see.

I must say, this is a rather dramatized way to frame the discussion in the linked PR, which, indeed, hasn't been closed and is still ongoing.

IMO those corporate environments are reaping what they sow. We shouldn't be so quick to disable TLS. Who would be to blame if those corporate environments found rustup as an attack channel for getting trojans? My guess is that rust would be a convenient scapegoat in that case.

Also, I believe that some of them may create intercept exceptions for 'legitimate' software distribution channels (like pip/npm/etc). Maybe they just need one for crates.io.

also, there are now alternative crate registering.