
Rust's 2019 Roadmap - steveklabnik
https://blog.rust-lang.org/2019/04/23/roadmap.html
======
whatshisface
One of my biggest concerns about the Rust project is that their governance is
getting more and more complicated. Every language so far that I like was
orchestrated by a BDFL, and the ones that aren't so well-designed (C++, Java)
also happen to be elaborately governed. How can the Rust project be sure that
it isn't going to smother itself with working groups to decide the color of
the bikeshed that committee members park their bikes in on the way to meet
about the code of conduct?

~~~
woah
JavaScript went from being a bad language designed by a BDFL to a good
language designed by a very large committee.

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.

~~~
whatshisface
> _The last part of your comment hints that your objections to Rust’s
> governance may be more political than language design related._

I checked the code of conduct and it didn't seem too political to me, internet
forums have had those kinds of rules for decades. What it is, though, is an
example of an administrative artifact, too many of which will suck energy away
as top level people spend more and more of their time not thinking about the
end product.

------
oaiey
I happily read that rustc is split into a incremental parsing frontend and a
supporting backend. This capability is key in modern compilers and editors. I
read about this like 8 years ago in the C# Roslyn compiler project. Roslyn
also aimed in supporting IDEs (here the language server) using the compiler
frontend.

My question is: are there any compiler which predate Roslyn in this aspect?
Anders Heijlsberg said in a video once, that this is modern compiler
architecture (compared to the outdated Dragon and Tiger) but did not mention
that the Roslyn team invented it.

~~~
raphlinus
I'm not super-expert, but know of some background. I think Rosyln grew very
much out of Delphi, and Anders Hejlsberg is the common thread to both. Before
that, he did Turbo Pascal, which might have been incremental in some ways (it
certainly was very fast).

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.

~~~
lostmsu
I thought the main technology behind Roslyn is some researched or customly
engineered parser/semantic analyzer that came out of MSR. The original C#
parser was quite typical.

~~~
pjmlp
Phoenix, it was a kind of LLVM (search for "Frameworks for Research in Code
Generation and Execution").

------
dfabulich
How many of the language improvements called out in the 2018 roadmap
[https://blog.rust-lang.org/2018/03/12/roadmap.html](https://blog.rust-
lang.org/2018/03/12/roadmap.html) are done? Seems like async/await still
isn't.

~~~
Buttons840
It looks to me like the 2018 roadmap was followed pretty well.

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.

~~~
steveklabnik
> 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.

We shipped the biggest part, which is "procedural macros," which shipped in
1.30. [https://blog.rust-
lang.org/2018/10/25/Rust-1.30.0.html#proce...](https://blog.rust-
lang.org/2018/10/25/Rust-1.30.0.html#procedural-macros)

As I said below, we didn't ship hygiene for them, so there's more work to be
done. There's also future work around "macros by example 2.0", but this item
on the roadmap was mostly talking about proc macros.

~~~
ksec
Async, Macros 2.0, const generics, most of the languages changes are already
well baked and could be ready to land in 2019. All the other improvements are
tooling and compilers.

So what other languages features are coming? Or could Rust enjoy a stable
period of little to no changes for a few years. After all Rust is modern
enough in almost all cases. Unlike other languages still trying to get
features in within their own constrain.

~~~
steveklabnik
The big ones being looked at are const generics, async/await, specialization,
and GATs. As you said, they're sort of all pre-baked, though to very different
degrees. And, while it's not "no changes", it's much fewer than in past years.

------
est31
In other Rusty news, two phase borrows just got enabled on nightly but stable
Rust in the 2015 edition: [https://github.com/rust-
lang/rust/pull/59114](https://github.com/rust-lang/rust/pull/59114). If not
backed out, it will most likely be part of the 1.36 release. This is a
milestone of maturity for the new borrow checker: they had a ticket with
multiple blocker bugs before they chose to enable it on the 2015 "stability"
edition as well: [https://github.com/rust-
lang/rust/issues/57804](https://github.com/rust-lang/rust/issues/57804)

~~~
atombender
Is there a document anywhere explaining what this change means in practice?

~~~
est31
The change was part of the 2018 edition already, so is covered in the 2018
book: [https://doc.rust-lang.org/edition-
guide/rust-2018/ownership-...](https://doc.rust-lang.org/edition-
guide/rust-2018/ownership-and-lifetimes/non-lexical-lifetimes.html)

As an experienced Rust developer I can usually deal with the borrow checker,
but sometimes I'm still annoyed by its limitations or hit them without
expecting to hit them. Most of the times this happens it's either because I
want to partially access a struct in a closure, or do something that's now
allowed by NLL. So this is a big deal.

------
integricho
Off-topic, but I'll just ask, is the book Programming Rust: Fast, Safe Systems
Development 1st Edition [1] still relevant / worth reading (given the book is
based on an older, although stable? version of Rust)? If it isn't, does anyone
know maybe if a 2nd, updated edition can be expected?

[1] [https://www.amazon.com/Programming-Rust-Fast-Systems-
Develop...](https://www.amazon.com/Programming-Rust-Fast-Systems-
Development/dp/1491927283#)

~~~
steveklabnik
It covers Rust 1.17. It is almost entirely still accurate; you’d need to set
the edition back to 2015 in your Cargo.toml for some examples to work, but the
foundations are still very solid. You’d have to adjust some import paths to
get them to work in Rust 2018 thanks to the module system improvements. It
won’t tell you about new features, but the big picture is still fully
accurate, you might just need to tweak some details, and read some newer
release notes to learn about some new things. It’s still a great book.

~~~
integricho
Thanks, that's quite reassuring, I wasn't sure whether it's a good investment
of time or not.

~~~
kod
It's still probably the most well-written Rust book.

------
xvilka
Porting unique and omnipresent applications to Rust can help the adoption. For
example applications like ElasticSearch. There is an ongoing Toshi[1] project
to create an alternative. Creating analogs for IPython and LanguageTool can
add much more Rust users and developers without significant promotional
efforts.

[1] [https://github.com/toshi-search/Toshi](https://github.com/toshi-
search/Toshi)

------
SlowRobotAhead
CTRL-F embed

Nope, well... Maybe next year! I've been eyeing Rust for embedded but until
there are major players shipping IDEs that natively support it, it's just a
hobby thing.

Embedded and IoT is about to get a lot bigger - if I was them I'd be focusing
hard on it to make sure my language had a strong foothold for when there was a
new hottness that all the kids start raving about.

~~~
_bxg1
"Embedded and IoT is about to get a lot bigger"

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](https://twitter.com/internetofshit)

~~~
SlowRobotAhead
Microsoft just purchased TheeadX. Amazon purchased FreeRTOS. Intel, Nordic and
others are dumping time into Zepher.

Those are three RTOSes specifically being designed to run IoT endpoints. I’m
working with FreeRTOS and AWS IoT right now, and can tell you Amazon is taking
it pretty seriously.

I think 90% of IoT are devices that don’t need to be connected - no doubt. But
mine does and sometimes it’s there are pretty awesome use cases for it.

If Rust wants to make it to C-replacement, they should be bringing over
backwards to get away from DoItAllYourself IDEs and into commercial products
like Keil, IAR, Segger, Attolic, etc. I promise when E+++ or Swifterz or C% or
whatever crazy new hotness shows up, Rust will be the hardest hit language to
lose its enthusiasts.

~~~
steveklabnik
I don't know a bunch about it, but Azure IoT Edge (by Microsoft, as you'd
expect) has a significant amount of Rust. I'm not sure if it's something
that's directly comparable, but is at least somewhat similar.

~~~
pjmlp
Yet they decided to go with C for Azure Sphere, in spite of the whole security
history they are trying to sell around it.

[https://social.msdn.microsoft.com/Forums/en-
US/72ae0354-63eb...](https://social.msdn.microsoft.com/Forums/en-
US/72ae0354-63eb-478c-a16a-a8d8f745d2e9/secure-os-while-allowing-only-c-
missing-security-story?forum=azuresphere)

The pearl is the typical set of recomendations of how good C developers are
expected to write unsafe secure code.

When you read the marketing materials of Azure Sphere, it is all about
security everywhere.

Another proof that while we need safer languages, we also need to improve C's
security story, as this will keep on happening anyway.

------
ausjke
Never really got a chance to do serious c++ development but I am more and more
interested in Rust these days. It appears Rust might be a good alternatives.
My field is embedded products.

~~~
dorfsmay
What do you use today? C?

~~~
ausjke
Mostly C, some python. I spent more and more time on rust and golang these
days.

~~~
dorfsmay
Do you do embedded in golang as well? What has been your experience going from
C to Rust for embedded?

~~~
ausjke
yes but I am not using either heavily at this point in any real product, just
experimenting, so far golang is easier to pick up, binary size is a concern
still even with upx, security is the major selling point for both. golang is
not good for realtime due to its GC.

------
mjw1007
I'm pleased to see that improving the language reference is on there, but
mildly concerned by the core team thinking of this as a matter of "polish".

~~~
steveklabnik
It's more about how it fits into a general theme; it's not a comment on the
amount of work, just that it's a resource that already exists that needs
improvement. There's a ton of things that need to improve with it.

------
xvilka
Any updates and plans on Chalk[1][2] and Traits subsystem?

[1] [https://github.com/rust-lang/chalk](https://github.com/rust-lang/chalk)

[2] [https://github.com/rust-lang/rust-
roadmap-2017/issues/8](https://github.com/rust-lang/rust-
roadmap-2017/issues/8)

~~~
steveklabnik
That's required for several of the items under "long-standing requests".

------
hi41
The write ups from Rust team is so good! Do they have a documentation team or
is it written by a technical person?

~~~
steveklabnik
Thank you!

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.

~~~
lenocinor
Sounds like you're still significantly involved with the docs, then. Are you
currently working on transitioning away those responsibilities?

~~~
steveklabnik
I am planning on staying significantly involved in Rust overall. We're
currently discussing some stuff within the docs team, as the roadmap says.
We'll see :)

------
v_lisivka
One long-standing problem is the incompatibility of Rust enum with C enum. In
C, enum's are just labels for integers, similar to const int values in Rust,
so C enum { A=0, B=1, C=2 } is more like Rust's enum E { A=0, B=1, C=2,
Unlabeled(3..MAX_INT32), } . This slight incompatibility forces writing of
converters between C enums and Rust enums.

See [https://github.com/rust-lang/rust-
bindgen/issues/667](https://github.com/rust-lang/rust-bindgen/issues/667)

~~~
v_lisivka
Can anybody explain the downvotes? It looks suspicious.

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)
        }
      }
    
    

Output:

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

~~~
pleasecalllater
> Can anybody explain the downvotes? It looks suspicious.

I can. This is a long tradition here. If someone criticizes something loved by
people with little knowledge (aka fangirls and fanboys) then they downvote it.

The truth doesn't matter, the hurt feelings do. And it's downvoted without any
explanation.

I had this many times, I'm thinking about not posting at all. It's not worth
it. There is no discussion, just downvotes.

I'm sure this will be downvoted too :)

------
Tomte
The MITM proxy issue makes Rust a non-starter in many corporate environments.

Unfortunately, when someone tried to make a first step, he was treated very
poorly and his work was sabotaged.

I don't have much hope that it will be addressed again soon:
[https://github.com/rust-
lang/rustup.rs/pull/1624#pullrequest...](https://github.com/rust-
lang/rustup.rs/pull/1624#pullrequestreview-201321423)

It's really sad, because Rust started with the same good idea as Golang: treat
Windows users as first-class citizens.

~~~
steveklabnik
We've made other moves toward this kind of thing; for example, you can run
your own crates.io instance. This is something we care about, but it's also
something we want to make sure we do right. We'll get there. (Note also that
that PR is not yet closed.)

~~~
Tomte
Thanks for working on it!

But I still think someone "official" should have weighed in and reined in the
"what about security?" people.

That was pure ignorance. The security angle has been discussed, and "I don't
know much about it, so let's kill it" is a really bad precedent.

~~~
staticassertion
> and "I don't know much about it, so let's kill it" is a really bad
> precedent.

I feel the opposite. Where user safety is concerned, if a problem is not
understood the solution should not be implemented.

In an example where it's "disable security feature X", and the developers
don't know the implication, would you really want them to just say "well
whatever, I don't understand the implications, but let's push forward" ?

~~~
Tomte
It's fine to say "let's clear this question up" and proceed to clear it up.

It's not fine to use security as the big hammer that cannot be argued with,
and then – nothing happens. At least not publically. Note that there wasn't
even a word where it might be discussed.

I actually went looking for Rust development mailing lists, but found no
discussion.

~~~
Manishearth
It's not the big hammer that can't be argued with. There's a path forward
there: bring in security experts to weigh in on this. This hasn't happened. It
could, and when it does there may be progress.

Rust doesn't quite have a team for this yet (there's a security WG slowly
spinning up though) which probably explains why it's kinda stalled.

Ultimately there's no obligation here for the team to do the legwork for this
PR anyway. It's blocked on something, and while that's resolvable you can't
blame the team for not pushing on it.

(I did just ping someone knowledgeable in security matters about this, let's
see what they say)

