RFC: Roadmap for 2017 #1774

Merged
merged 10 commits into from Jan 5, 2017

Conversation

@aturon
Member

aturon commented Oct 21, 2016

This RFC proposes the 2017 Rust Roadmap, in accordance with RFC 1728. The goal of the roadmap is to lay out a vision for where the Rust project should be in a year's time. This year's focus is improving Rust's productivity, while retaining its emphasis on fast, reliable code. At a high level, by the end of 2017:

  • Rust should have a lower learning curve
  • Rust should have a pleasant edit-compile-debug cycle
  • Rust should provide a solid, but basic IDE experience
  • Rust should provide easy access to high quality crates
  • Rust should be well-equipped for writing robust, high-scale servers
  • Rust should have 1.0-level crates for essential tasks
  • Rust should integrate easily into large build systems
  • Rust's community should provide mentoring at all levels

In addition, we should make significant strides in exploring two areas where
we're not quite ready to set out specific goals:

  • Integration with other languages, running the gamut from C to JavaScript
  • Usage in resource-constrained environments

The proposal is based on the 2016 survey, systematic outreach, direct conversations with individual Rust users, and an extensive internals thread. Thanks to everyone who helped with this effort!

@aturon

This comment has been minimized.

Show comment
Hide comment

@aturon aturon added the T-core label Oct 21, 2016

@aturon aturon self-assigned this Oct 21, 2016

@aturon

This comment has been minimized.

Show comment
Hide comment
@aturon

aturon Oct 21, 2016

Member

One of the areas that didn't get a lot of discussion on the internals thread is the mentoring goal. I also think this is one of the most vital goals for sustaining and scaling up the project. I would love to flesh out the text for this goal a bit more!

Member

aturon commented Oct 21, 2016

One of the areas that didn't get a lot of discussion on the internals thread is the mentoring goal. I also think this is one of the most vital goals for sustaining and scaling up the project. I would love to flesh out the text for this goal a bit more!

text/0000-roadmap-2017.md
+At the moment, our most immediate adoption obstacles are mostly about blockers,
+rather than a lack of drivers: there are people who see potential value in Rust,
+but worry about issues like productivity, tooling, and maturity standing in the
+way of use at scale The roadmap proposes a set of goals largely angled at

This comment has been minimized.

@anp

anp Oct 21, 2016

Missing a period?

@anp

anp Oct 21, 2016

Missing a period?

@aturon

This comment has been minimized.

Show comment
Hide comment
@aturon

aturon Oct 21, 2016

Member

It's worth mentioning that this roadmap proposal was also the topic of the RustConf 2016 keynote, which might be a good complement to the RFC text.

Member

aturon commented Oct 21, 2016

It's worth mentioning that this roadmap proposal was also the topic of the RustConf 2016 keynote, which might be a good complement to the RFC text.

+- Personal investment
+- Professional investment
+
+We need to (1) provide "drivers", i.e. strong motivation to continue through the

This comment has been minimized.

@nagisa

nagisa Oct 22, 2016

Contributor

Nit: A list “hidden” as text in paragraph is still a list. It should be an enumeration proper.

@nagisa

nagisa Oct 22, 2016

Contributor

Nit: A list “hidden” as text in paragraph is still a list. It should be an enumeration proper.

text/0000-roadmap-2017.md
+course, part of the work of the roadmap is to allocate our limited resources,
+which fundamentally means not including some possible goals. Some of the most
+promising suggestions that didn't make it into the roadmap proposal itself are
+included at the end of the Goals section.

This comment has been minimized.

@nagisa

nagisa Oct 22, 2016

Contributor

Nit: An aside/footnote as a quote?

@nagisa

nagisa Oct 22, 2016

Contributor

Nit: An aside/footnote as a quote?

text/0000-roadmap-2017.md
+before hitting their stride with Rust. And that often comes on top of other
+aspects of Rust that may be less familiar. A common refrain is "the first couple
+of weeks are tough, but it's oh so worth it." How many people are bouncing off
+of Rust before they get through those first couple of weeks? How many team leads

This comment has been minimized.

@nagisa

nagisa Oct 22, 2016

Contributor

Was it supposed to be:

How many people are bouncing off of Rust before they cannot get through those first couple of weeks?

@nagisa

nagisa Oct 22, 2016

Contributor

Was it supposed to be:

How many people are bouncing off of Rust before they cannot get through those first couple of weeks?

This comment has been minimized.

@cramertj

cramertj Oct 22, 2016

Member

That edit doesn't make sense to me, but I agree the original phrasing is a tad confusing. Perhaps "How many people give up on learning Rust during those first couple weeks?"

@cramertj

cramertj Oct 22, 2016

Member

That edit doesn't make sense to me, but I agree the original phrasing is a tad confusing. Perhaps "How many people give up on learning Rust during those first couple weeks?"

+ formatting.
+
+Note that while some of this functionality is available in existing IDE/plugin
+efforts, a key part of this initiative is to (1) lay the foundation for plugins

This comment has been minimized.

@nagisa

nagisa Oct 22, 2016

Contributor

Nit: another list hiding inside a paragraph

@nagisa

nagisa Oct 22, 2016

Contributor

Nit: another list hiding inside a paragraph

text/0000-roadmap-2017.md
+headers (e.g., include! {myproject.hpp}) and have the extern declarations, glue
+code, and so forth get generated automatically. This means (eventually) full
+support for interfacing with C++ code that uses features like templates,
+overloading, classes and virtual calls, and so forth.

This comment has been minimized.

@nagisa

nagisa Oct 22, 2016

Contributor

I do not think this goal as written is actionable. Especially the “directly include” part. Without us becoming a C++ compiler, at least, and I doubt we want to get into the business of C++ compilers (within a year and with our resources).

@nagisa

nagisa Oct 22, 2016

Contributor

I do not think this goal as written is actionable. Especially the “directly include” part. Without us becoming a C++ compiler, at least, and I doubt we want to get into the business of C++ compilers (within a year and with our resources).

This comment has been minimized.

This comment has been minimized.

@withoutboats

withoutboats Oct 22, 2016

Contributor

I think this comment is inspired by the way that Swift works, but I don't know any of the details of it.

@withoutboats

withoutboats Oct 22, 2016

Contributor

I think this comment is inspired by the way that Swift works, but I don't know any of the details of it.

This comment has been minimized.

@aturon

aturon Oct 22, 2016

Member

cc @nikomatsakis and @jonathandturner, who helped craft this section.

I do think that easy (low-friction) integration is the right goal to be working toward, but it's entirely possible that the "zero friction" proposal here is not attainable on this timeframe.

@aturon

aturon Oct 22, 2016

Member

cc @nikomatsakis and @jonathandturner, who helped craft this section.

I do think that easy (low-friction) integration is the right goal to be working toward, but it's entirely possible that the "zero friction" proposal here is not attainable on this timeframe.

This comment has been minimized.

@comex

comex Oct 22, 2016

I imagine it would be done with the help of Clang rather than trying to implement C++ from scratch, but AFAIK supporting things like templates would still require extensive hacking on the Clang codebase... would be pretty amazing if it worked though.

@comex

comex Oct 22, 2016

I imagine it would be done with the help of Clang rather than trying to implement C++ from scratch, but AFAIK supporting things like templates would still require extensive hacking on the Clang codebase... would be pretty amazing if it worked though.

This comment has been minimized.

@nikomatsakis

nikomatsakis Oct 24, 2016

Contributor

Hmm. The text may be misleading in its emphasis. Let me explain my POV and see what people think. I think @jonathandturner may have a slightly different take, though I think we definitely agree on the end-points we're aiming for; @wycats also has a lot of well-informed opinions here. =)

In my opinion, both C and C++ are very important. I think we should emphasize steps that benefit both languages (I'll sketch out a possible plan below). But basically C++ is the only language that is not C that I think makes sense for the Rust teams themselves to pursue. C is certainly the "lingua franca", but there are plenty of big projects and libraries that use C++ too (off the top of my head: V8, LLVM if you want the full thing, Gecko). Anecdotally, I certainly get a lot of questions about C++ integration.

(To be clear, I definitely hope we will see work on integration with other languages, like Python etc. I just think that is best handled by other projects -- though if we find features that are needed, it'd be great to surface those as RFCs.)

Regarding C++ integration, I agree we're not going to implement a C++ compiler in the Rust compiler, and I don't think the roadmap should commit us to any such thing! =) What I do think is that we should work on reducing FFI boilerplate as much as we can. I think this starts just by taking a tool like bindgen and making it drop-dead simple to invoke (include! { ... }), perhaps leveraging progress on macros-1.1-style integration.

Once we have that, we can extend this include! macro to start filling in the gaps in our existing C integration. So for example dealing with macros properly is a big pain right now. Projects like Ruby using macros as inline functions, basically, so to properly bind to those you have to generate C shims that your Rust code can call. But wouldn't it be nice if include! could do this for you? (You'd probably have to direct it some, e.g. to tell it types involved.)

Finally, we can start to leverage some of the awesome work that @emilio has been doing in Servo project for supporting C++. He can speak more to the details, but from what I understand he has a branch of bindgen that can create layout-compatible Rust structs for the C++ used in Gecko, which is no mean feat. What it doesn't support are things like virtual calls and so forth (it just leaves opaque vtables in the Rust structs, as I understand).

Now the C++ ABI is famously undefined and we don't want to get too deeply involved there. But this looks (to me) like a place we can leverage shims. We can basically generate extern "C" wrappers for C++ things you'd like to call. Using said shims, at least initially, will probably still be tedious (e.g., instead of calling widget->draw(), you call widget_draw(widget)) but at least you don't have to write the shims by hand. Maybe you initially also specify template instantiations by hand.

If we got those steps, we'd be in a much better shape. You can now generate boilerplate code easily. From there, there seem to be many directions we could go:

  • generating more "ergonomic" wrappers, e.g. using Rust methods so you can call widget.draw();
  • improving efficiency by compiling the shims (using clang) to LLVM and then inlining them into Rust code;
  • integrate the bindgen tool more deeply with the compiler, so that the compiler can request template instantiations as it monomorphizes, for example, or generate shims on the fly that use the C++ compiler to resolve overloading.

Anyway, this is getting afield, and obviously nothing in the roadmap commits us to any part of this path. But I wanted to sketch out an incremental vision that nonetheless gets us to relatively easy and feature-complete state, while remaining fairly agnostic in the compiler itself.

@nikomatsakis

nikomatsakis Oct 24, 2016

Contributor

Hmm. The text may be misleading in its emphasis. Let me explain my POV and see what people think. I think @jonathandturner may have a slightly different take, though I think we definitely agree on the end-points we're aiming for; @wycats also has a lot of well-informed opinions here. =)

In my opinion, both C and C++ are very important. I think we should emphasize steps that benefit both languages (I'll sketch out a possible plan below). But basically C++ is the only language that is not C that I think makes sense for the Rust teams themselves to pursue. C is certainly the "lingua franca", but there are plenty of big projects and libraries that use C++ too (off the top of my head: V8, LLVM if you want the full thing, Gecko). Anecdotally, I certainly get a lot of questions about C++ integration.

(To be clear, I definitely hope we will see work on integration with other languages, like Python etc. I just think that is best handled by other projects -- though if we find features that are needed, it'd be great to surface those as RFCs.)

Regarding C++ integration, I agree we're not going to implement a C++ compiler in the Rust compiler, and I don't think the roadmap should commit us to any such thing! =) What I do think is that we should work on reducing FFI boilerplate as much as we can. I think this starts just by taking a tool like bindgen and making it drop-dead simple to invoke (include! { ... }), perhaps leveraging progress on macros-1.1-style integration.

Once we have that, we can extend this include! macro to start filling in the gaps in our existing C integration. So for example dealing with macros properly is a big pain right now. Projects like Ruby using macros as inline functions, basically, so to properly bind to those you have to generate C shims that your Rust code can call. But wouldn't it be nice if include! could do this for you? (You'd probably have to direct it some, e.g. to tell it types involved.)

Finally, we can start to leverage some of the awesome work that @emilio has been doing in Servo project for supporting C++. He can speak more to the details, but from what I understand he has a branch of bindgen that can create layout-compatible Rust structs for the C++ used in Gecko, which is no mean feat. What it doesn't support are things like virtual calls and so forth (it just leaves opaque vtables in the Rust structs, as I understand).

Now the C++ ABI is famously undefined and we don't want to get too deeply involved there. But this looks (to me) like a place we can leverage shims. We can basically generate extern "C" wrappers for C++ things you'd like to call. Using said shims, at least initially, will probably still be tedious (e.g., instead of calling widget->draw(), you call widget_draw(widget)) but at least you don't have to write the shims by hand. Maybe you initially also specify template instantiations by hand.

If we got those steps, we'd be in a much better shape. You can now generate boilerplate code easily. From there, there seem to be many directions we could go:

  • generating more "ergonomic" wrappers, e.g. using Rust methods so you can call widget.draw();
  • improving efficiency by compiling the shims (using clang) to LLVM and then inlining them into Rust code;
  • integrate the bindgen tool more deeply with the compiler, so that the compiler can request template instantiations as it monomorphizes, for example, or generate shims on the fly that use the C++ compiler to resolve overloading.

Anyway, this is getting afield, and obviously nothing in the roadmap commits us to any part of this path. But I wanted to sketch out an incremental vision that nonetheless gets us to relatively easy and feature-complete state, while remaining fairly agnostic in the compiler itself.

This comment has been minimized.

@nikomatsakis

nikomatsakis Nov 2, 2016

Contributor

@nagisa @mystor @nrc -- I'm curious whether you found the comments by @jonathandturner and I convincing or not. =) Seems like we addressed...mildly separate things. That is, him primarily some motivation for C++ specifically, me primarily some concrete steps we could take that would be helpful (and would benefit C too).

@nikomatsakis

nikomatsakis Nov 2, 2016

Contributor

@nagisa @mystor @nrc -- I'm curious whether you found the comments by @jonathandturner and I convincing or not. =) Seems like we addressed...mildly separate things. That is, him primarily some motivation for C++ specifically, me primarily some concrete steps we could take that would be helpful (and would benefit C too).

This comment has been minimized.

@nagisa

nagisa Nov 3, 2016

Contributor

Seems like we addressed...mildly separate things.

@jonathandturner explained why we want better C++ story in our roadmap. You yourself go into details as to how “lets shoot for a better C++ integration” could be implemented. Namely:

I think this starts just by taking a tool like bindgen and making it drop-dead simple to invoke (include! { ... })

The “why” should probably appear in the RFC text (esp. because its not a goal that has spawned from the survey), and the implementation vector/features/etc should not (even though the language used in the RFC does not commit us to anything).

The best way to resolve my concerns (I’m repeating myself, here) would be reword this section slightly from “The goal should be that using a C++ library in Rust is not much harder than using it in C++” to “FFI to C++ ought to have less friction in Rust!”.


As I was writing the last paragraph I realised why exactly that sentence bothers me so much. It’s worded as a goal that’s most likely gonna fail to be achieved; I’m very unlikely to be able to take this document on the 2018 new year eve and tick off this goal as achieved. probably because it feels too ambitious for the time-frame. Aiming for “less friction” makes it much more likely. Everything else being same, the paragraph could look like this instead:

Rust should aim to provide a lower friction C++ FFI. It should be possible to directly include process existing C++ headers (e.g., include! {myproject.hpp}) and have the extern declarations, glue code, and so forth get generated automatically. This means (eventually) full support for interfacing with C++ code that uses features like templates,
overloading, classes and virtual calls, and so forth.

@nagisa

nagisa Nov 3, 2016

Contributor

Seems like we addressed...mildly separate things.

@jonathandturner explained why we want better C++ story in our roadmap. You yourself go into details as to how “lets shoot for a better C++ integration” could be implemented. Namely:

I think this starts just by taking a tool like bindgen and making it drop-dead simple to invoke (include! { ... })

The “why” should probably appear in the RFC text (esp. because its not a goal that has spawned from the survey), and the implementation vector/features/etc should not (even though the language used in the RFC does not commit us to anything).

The best way to resolve my concerns (I’m repeating myself, here) would be reword this section slightly from “The goal should be that using a C++ library in Rust is not much harder than using it in C++” to “FFI to C++ ought to have less friction in Rust!”.


As I was writing the last paragraph I realised why exactly that sentence bothers me so much. It’s worded as a goal that’s most likely gonna fail to be achieved; I’m very unlikely to be able to take this document on the 2018 new year eve and tick off this goal as achieved. probably because it feels too ambitious for the time-frame. Aiming for “less friction” makes it much more likely. Everything else being same, the paragraph could look like this instead:

Rust should aim to provide a lower friction C++ FFI. It should be possible to directly include process existing C++ headers (e.g., include! {myproject.hpp}) and have the extern declarations, glue code, and so forth get generated automatically. This means (eventually) full support for interfacing with C++ code that uses features like templates,
overloading, classes and virtual calls, and so forth.

This comment has been minimized.

@mystor

mystor Nov 3, 2016

@nikomatsakis Your comments make sense, and bring a lot of clarity to the situation. I think that @nagisa is right in that we need to be careful to put down achievable goals which are abstract enough that we can figure out what the solution looks like over time.

It doesn't feel to me like anyone here has a clear enough idea of what the solution which we're aiming for is for is going to be to get much more specific than something along the lines of "We want to significantly reduce the friction for C/C++ interop to the point where the fact that the library you want to use is written in C++ and doesn't have rust bindings is not a significant reason to use C++ instead of rust."

@mystor

mystor Nov 3, 2016

@nikomatsakis Your comments make sense, and bring a lot of clarity to the situation. I think that @nagisa is right in that we need to be careful to put down achievable goals which are abstract enough that we can figure out what the solution looks like over time.

It doesn't feel to me like anyone here has a clear enough idea of what the solution which we're aiming for is for is going to be to get much more specific than something along the lines of "We want to significantly reduce the friction for C/C++ interop to the point where the fact that the library you want to use is written in C++ and doesn't have rust bindings is not a significant reason to use C++ instead of rust."

This comment has been minimized.

@nrc

nrc Nov 6, 2016

Member

@nikomatsakis

I'm curious whether you found the comments by @jonathandturner and I convincing or not.

Sort of. I definitely see the motivation and vision for delivery more clearly (thanks for the explanations), I'm still not convinced that this is the right goal for 2017. I'm finding it pretty difficult to weigh up the relative merits of focussing on C++ vs a more general FFI goal. Given the early stages of planning here, I'd prefer the latter, and be happy if it turned out that we focussed on C++.

@nrc

nrc Nov 6, 2016

Member

@nikomatsakis

I'm curious whether you found the comments by @jonathandturner and I convincing or not.

Sort of. I definitely see the motivation and vision for delivery more clearly (thanks for the explanations), I'm still not convinced that this is the right goal for 2017. I'm finding it pretty difficult to weigh up the relative merits of focussing on C++ vs a more general FFI goal. Given the early stages of planning here, I'd prefer the latter, and be happy if it turned out that we focussed on C++.

@hauleth

This comment has been minimized.

Show comment
Hide comment
@hauleth

hauleth Oct 22, 2016

Linters 1.1 similar in scope to Macros 1.1 would be awesome.

hauleth commented Oct 22, 2016

Linters 1.1 similar in scope to Macros 1.1 would be awesome.

@raindev

This comment has been minimized.

Show comment
Hide comment
@raindev

raindev Oct 22, 2016

It would be an important step to be able to use powerful libraries like Serde and Diesel with stable Rust. Given that @aturon mentioned Serde specifically during the keynote, I suppose it is the part of the "easy access to high quality crates" goal already.

raindev commented Oct 22, 2016

It would be an important step to be able to use powerful libraries like Serde and Diesel with stable Rust. Given that @aturon mentioned Serde specifically during the keynote, I suppose it is the part of the "easy access to high quality crates" goal already.

@hauleth

This comment has been minimized.

Show comment
Hide comment
@hauleth

hauleth Oct 22, 2016

@raindev what we need is stabilization of Macros 1.1 which seems in reach at the beginning of 2017.

hauleth commented Oct 22, 2016

@raindev what we need is stabilization of Macros 1.1 which seems in reach at the beginning of 2017.

@Ericson2314

This comment has been minimized.

Show comment
Hide comment
@Ericson2314

Ericson2314 Oct 22, 2016

Contributor

At the moment, though, it's far from clear what it will take to achieve significant production use in the embedded space. It would behoove us to try to get a clearer picture of this space in 2017.

Would @japaric's and my longstanding goal of a single cargo build, without extra tools, cross compiling everything down through core be a good and sufficiently high level goal? I'd even include the linker under the umbrella of external tools to be purged, if lld will get linker script support in time.

Contributor

Ericson2314 commented Oct 22, 2016

At the moment, though, it's far from clear what it will take to achieve significant production use in the embedded space. It would behoove us to try to get a clearer picture of this space in 2017.

Would @japaric's and my longstanding goal of a single cargo build, without extra tools, cross compiling everything down through core be a good and sufficiently high level goal? I'd even include the linker under the umbrella of external tools to be purged, if lld will get linker script support in time.

+The edit-compile-debug cycle in Rust takes too long, and it's one of the
+complaints we hear most often from production users. We've laid down a good
+foundation with [MIR] (now turned on by default) and [incremental compilation]
+(which recently hit alpha). But we need to continue pushing hard to actually

This comment has been minimized.

@chriskrycho

chriskrycho Oct 23, 2016

Contributor

This is getting rendered as a link; you need to escape the opening parenthesis for the Markdown parser to get it right: [incremental compilation] \(which recently hit alpha).

@chriskrycho

chriskrycho Oct 23, 2016

Contributor

This is getting rendered as a link; you need to escape the opening parenthesis for the Markdown parser to get it right: [incremental compilation] \(which recently hit alpha).

This comment has been minimized.

@porglezomp

porglezomp Dec 28, 2016

I think the idiomatic way to write this is [incremental compilation][] (which recently hit alpha), for example:

incremental compilation (which recently hit alpha).

@porglezomp

porglezomp Dec 28, 2016

I think the idiomatic way to write this is [incremental compilation][] (which recently hit alpha), for example:

incremental compilation (which recently hit alpha).

@gabomgp

This comment has been minimized.

Show comment
Hide comment
@gabomgp

gabomgp Oct 30, 2016

I think a key area to maximice the value of Rust is the writing of high perfomance network software using asynchronous state machines, but for this be widelly used and very productive, we need stackless coroutines support or something with the same level of ergonomics. That really would be great for the sucess of Rust.

gabomgp commented Oct 30, 2016

I think a key area to maximice the value of Rust is the writing of high perfomance network software using asynchronous state machines, but for this be widelly used and very productive, we need stackless coroutines support or something with the same level of ergonomics. That really would be great for the sucess of Rust.

@diwic

This comment has been minimized.

Show comment
Hide comment
@diwic

diwic Oct 31, 2016

Hi! To what degree is "fixing the remaining soundness issues, including the hard ones" part of the roadmap? It was not explicitly mentioned in the RFC and I'm not sure if it's implicit given phrases such as uncompromising reliability.

Keep up the great work anyhow :-)

diwic commented Oct 31, 2016

Hi! To what degree is "fixing the remaining soundness issues, including the hard ones" part of the roadmap? It was not explicitly mentioned in the RFC and I'm not sure if it's implicit given phrases such as uncompromising reliability.

Keep up the great work anyhow :-)

@burdges

This comment has been minimized.

Show comment
Hide comment
@burdges

burdges Oct 31, 2016

I suppose "well-equipped for writing robust, high-scale servers" means those of us interested in cryptography and/or data structures should get our asses in gear. ;)

burdges commented Oct 31, 2016

I suppose "well-equipped for writing robust, high-scale servers" means those of us interested in cryptography and/or data structures should get our asses in gear. ;)

@brson

This comment has been minimized.

Show comment
Hide comment
@brson

brson Nov 3, 2016

Contributor

It's a really well written RFC so I don't have much to pick at.

The sloganeering ("... pick three") makes me cringe. It's fairly on-the-nose marketing talk. I also like being involved in Rust branding.

I'm personally quite dedicated to tooling for platform compatibility, which basically means "embedded rust", which is only an area of support.

I don't mind if C++ is a focus, and agree that excellent interop could be a game-changer, but it's a massive task, among several we have in front of us, and I do care deeply about keeping the Rust spec firewalled from the C++ spec. It is not ok for Rust to become a superset of C++.

If we're doing a server focus, then interop with JavaScript or Ruby is both easier and more aligned with other goals than interop with C++. And we have support in the Ruby/Rails communities, whereas the authors of the C++ toolchains have no particular motivation to interop with Rust.

Contributor

brson commented Nov 3, 2016

It's a really well written RFC so I don't have much to pick at.

The sloganeering ("... pick three") makes me cringe. It's fairly on-the-nose marketing talk. I also like being involved in Rust branding.

I'm personally quite dedicated to tooling for platform compatibility, which basically means "embedded rust", which is only an area of support.

I don't mind if C++ is a focus, and agree that excellent interop could be a game-changer, but it's a massive task, among several we have in front of us, and I do care deeply about keeping the Rust spec firewalled from the C++ spec. It is not ok for Rust to become a superset of C++.

If we're doing a server focus, then interop with JavaScript or Ruby is both easier and more aligned with other goals than interop with C++. And we have support in the Ruby/Rails communities, whereas the authors of the C++ toolchains have no particular motivation to interop with Rust.

@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Nov 3, 2016

Member

Looking over this, the roadmap overall looks great to me! I'm quite excited to
see increased productivity so front-and-center. I agree that all of the goals
proposed here would have a high impact on Rust, but I'd like to talk about one
of them in more detail. There's been discussion
already
about
C++ interoperability being on the roadmap, but I also want to about the "area of
support" of embedded vs making is a first class goal. (as a result I'm moving
this comment to the RFC itself rather than the previous thread).

I was personally surprised to see specifically C++ interop so prominently
mentioned in the roadmap. I like how it would transitively encompass better C
interoperability at the same time, and I'd definitely love to have it, but I'm
less convinced that it pulls its weight as an overarching goal. I share
@nagisa's
concern that
it seems like a stretch to see this completely finished and fleshed out by the
end of 2017 (in the sense of the level of completeness other goals likely will
be). We've certainly got plenty of efforts pushing on the C++ integeration right
now, and they've helped discover a lot of problems we're going to have to tackle
to get this right. I'm worried, though, that the scale of the problems we're
talking about here for a butter-smooth story is more time consuming than we
might be anticipating. This, in turn, could possibly limit resources
available to other goals and hinder their "full completion".

Some concrete worries I have about the difficulty of C++ interoperability are:

  • Templates are hard. This is the bread-and-butter of many large C++ codebases,
    so it's not a problem we can punt on. Effectively this seems like it will
    require bundling a C++ compiler somehow to understand templates at all and
    generate shims.
  • Generating shims are also hard. Projects like
    rustcxx work through plugins but require
    explicitly listing captured variables and signatures, and otherwise doing this
    in a seamless fashion seems like it will require intrusive static analysis or
    intrusive hooks into trans itself (e.g. what monomorphizations were
    requested).
  • System C++ compilers are also hard. If we take the route of shelling out to a
    C++ compiler (which seems most likely, I believe?), then we open the can of
    worms related to finding the compiler, passing flags, ensuring it has all of
    its own include paths set up correctly, codegen options set, etc, etc.
  • Bindgen seems like it's still very much an open problem. This has problems of
    dealing with headers from the C++ standard library, C headers (e.g. the libc
    crate), conditional compilation, C macros not having types, etc.

These are all definitely surmountable problems, of course! And there's lots of
possible solutions to each. My fear, though, is that a "full" solution is so
involved for each of these that it's a mammoth task to put forth. Now that sort
of work is appropriate for the goals of an entire year, however! When contrasted
with other possible routes I feel like we may be able to get more bang for our
buck.

To clarify, as well, my mental model for this comment is to work under the
assumption that this goal for 2017 would make using C++ from Rust becomes a
butter smooth experience. It'll basically be as easy if I'm writing C++. Even if
this happens, though, it'd still be difficult to consume Rust from C++. That is,
the other half of integration would still be difficult. This arguably the right
balance (for an existing C++ codebase there's more C++ code than Rust,
obviously), but I'd just want to highlight that really nailing down one
direction of interop also isn't the whole story.

Ok, so with all that in mind, I'd like to make a case for embedded development
as well. The RFC points out that embedded has the possibility of being quite a
large area of impact for Rust, and I would claim that the groundwork we lay for
embedded support can as far reaching as C++ include! in its full glory.

Concretely, I'm thinking of two primary features falling under the embedded
umbrella I think we'd want to pursue to completion:

  • Std-aware cargo. This enables
    Cargo to seamlessly compile the standard library, libcore, etc, on stable
    Rust. This is crucial for new platforms to easily build core/std with new
    codegen options, patches applied (e.g. overriding), and bootstrapping without
    nightlies. Furthermore this also unlocks compilation profiles for the standard
    library itself: compiling with debuginfo, optimized with simd, true
    panic=abort, etc. I personally believe the benefits we'll reap will benefit
    almost everyone using Rust, not just embedded users (who it will primarily
    impact, however).
  • Scenarios in the standard
    library
    .
    This feature will be a boon to developing any kind of embedded crate. The idea
    is to make the standard libary very easily accessible to new platforms while
    also allowing you to quickly understand whether a crate works on a platform
    or not. The embedded case can use this to forbid float APIs, we could build up
    a failable collections API for "I'm in another application" embedded users, or
    otherwise just enabling easy compilation to emscripten/web assembly.

I feel like features like this share many features with the C++ interop story.
All of what they enable is possible today, but unduly difficult. That is, C++
interop is possible but hard. Compiling libstd/libcore is possible but xargo but
hard. Porting code is possible with #[cfg] but hard without strong guarantees.
Each of the features here are targeted at improving on what's already possible,
in other words making you more productive in each area.

To wrap up, I'd propose to reword C++ interop to replace it with the goal of:

Rust should easily support embedded development.

Here when I say "embedded" I mean simultaneously embedded architecture (e.g.
small ARM boards, weird platforms, etc) along with embedded libraries (e.g.
running inside of another application). The C++ features fit squarely within the
embedded library application side of things, with the features I mentioned above
fitting in embedded architectures.

I wonder, though, if this is perhaps too broad of a goal for 2017? It may be too
vauge to be able to meaningfully set goals for or evaluate how far we've come.
In terms of what it means, though, I prefer how it puts the embedded
architecture case on the same level of C++, which I personally feel like
pursuing either direction can have similar impact on Rust adoption as a whole.

So that's a bit of a long comment, but I'm curious what others think about this
as well!

Member

alexcrichton commented Nov 3, 2016

Looking over this, the roadmap overall looks great to me! I'm quite excited to
see increased productivity so front-and-center. I agree that all of the goals
proposed here would have a high impact on Rust, but I'd like to talk about one
of them in more detail. There's been discussion
already
about
C++ interoperability being on the roadmap, but I also want to about the "area of
support" of embedded vs making is a first class goal. (as a result I'm moving
this comment to the RFC itself rather than the previous thread).

I was personally surprised to see specifically C++ interop so prominently
mentioned in the roadmap. I like how it would transitively encompass better C
interoperability at the same time, and I'd definitely love to have it, but I'm
less convinced that it pulls its weight as an overarching goal. I share
@nagisa's
concern that
it seems like a stretch to see this completely finished and fleshed out by the
end of 2017 (in the sense of the level of completeness other goals likely will
be). We've certainly got plenty of efforts pushing on the C++ integeration right
now, and they've helped discover a lot of problems we're going to have to tackle
to get this right. I'm worried, though, that the scale of the problems we're
talking about here for a butter-smooth story is more time consuming than we
might be anticipating. This, in turn, could possibly limit resources
available to other goals and hinder their "full completion".

Some concrete worries I have about the difficulty of C++ interoperability are:

  • Templates are hard. This is the bread-and-butter of many large C++ codebases,
    so it's not a problem we can punt on. Effectively this seems like it will
    require bundling a C++ compiler somehow to understand templates at all and
    generate shims.
  • Generating shims are also hard. Projects like
    rustcxx work through plugins but require
    explicitly listing captured variables and signatures, and otherwise doing this
    in a seamless fashion seems like it will require intrusive static analysis or
    intrusive hooks into trans itself (e.g. what monomorphizations were
    requested).
  • System C++ compilers are also hard. If we take the route of shelling out to a
    C++ compiler (which seems most likely, I believe?), then we open the can of
    worms related to finding the compiler, passing flags, ensuring it has all of
    its own include paths set up correctly, codegen options set, etc, etc.
  • Bindgen seems like it's still very much an open problem. This has problems of
    dealing with headers from the C++ standard library, C headers (e.g. the libc
    crate), conditional compilation, C macros not having types, etc.

These are all definitely surmountable problems, of course! And there's lots of
possible solutions to each. My fear, though, is that a "full" solution is so
involved for each of these that it's a mammoth task to put forth. Now that sort
of work is appropriate for the goals of an entire year, however! When contrasted
with other possible routes I feel like we may be able to get more bang for our
buck.

To clarify, as well, my mental model for this comment is to work under the
assumption that this goal for 2017 would make using C++ from Rust becomes a
butter smooth experience. It'll basically be as easy if I'm writing C++. Even if
this happens, though, it'd still be difficult to consume Rust from C++. That is,
the other half of integration would still be difficult. This arguably the right
balance (for an existing C++ codebase there's more C++ code than Rust,
obviously), but I'd just want to highlight that really nailing down one
direction of interop also isn't the whole story.

Ok, so with all that in mind, I'd like to make a case for embedded development
as well. The RFC points out that embedded has the possibility of being quite a
large area of impact for Rust, and I would claim that the groundwork we lay for
embedded support can as far reaching as C++ include! in its full glory.

Concretely, I'm thinking of two primary features falling under the embedded
umbrella I think we'd want to pursue to completion:

  • Std-aware cargo. This enables
    Cargo to seamlessly compile the standard library, libcore, etc, on stable
    Rust. This is crucial for new platforms to easily build core/std with new
    codegen options, patches applied (e.g. overriding), and bootstrapping without
    nightlies. Furthermore this also unlocks compilation profiles for the standard
    library itself: compiling with debuginfo, optimized with simd, true
    panic=abort, etc. I personally believe the benefits we'll reap will benefit
    almost everyone using Rust, not just embedded users (who it will primarily
    impact, however).
  • Scenarios in the standard
    library
    .
    This feature will be a boon to developing any kind of embedded crate. The idea
    is to make the standard libary very easily accessible to new platforms while
    also allowing you to quickly understand whether a crate works on a platform
    or not. The embedded case can use this to forbid float APIs, we could build up
    a failable collections API for "I'm in another application" embedded users, or
    otherwise just enabling easy compilation to emscripten/web assembly.

I feel like features like this share many features with the C++ interop story.
All of what they enable is possible today, but unduly difficult. That is, C++
interop is possible but hard. Compiling libstd/libcore is possible but xargo but
hard. Porting code is possible with #[cfg] but hard without strong guarantees.
Each of the features here are targeted at improving on what's already possible,
in other words making you more productive in each area.

To wrap up, I'd propose to reword C++ interop to replace it with the goal of:

Rust should easily support embedded development.

Here when I say "embedded" I mean simultaneously embedded architecture (e.g.
small ARM boards, weird platforms, etc) along with embedded libraries (e.g.
running inside of another application). The C++ features fit squarely within the
embedded library application side of things, with the features I mentioned above
fitting in embedded architectures.

I wonder, though, if this is perhaps too broad of a goal for 2017? It may be too
vauge to be able to meaningfully set goals for or evaluate how far we've come.
In terms of what it means, though, I prefer how it puts the embedded
architecture case on the same level of C++, which I personally feel like
pursuing either direction can have similar impact on Rust adoption as a whole.

So that's a bit of a long comment, but I'm curious what others think about this
as well!

@nikomatsakis

This comment has been minimized.

Show comment
Hide comment
@nikomatsakis

nikomatsakis Nov 3, 2016

Contributor

@alexcrichton I personally find this reasoning fairly persuasive, at least on first read. I agree that there is a lot to be worked out with respect to code generation -- I've been wondering how we can find just the right set of people to get motivated and make it actually happen. =) (You'll note I talk big, but I'm not volunteering...) Given that there is more of an extant community around embedded computing, it seems likely that it will be more actionable. I am particularly interested in the ways that "embedded" might benefit things beyond embedded architectures.


@nagisa

Everything else being same, the paragraph could look like this instead: (reworded text follows)

That sounds good to me too.

Contributor

nikomatsakis commented Nov 3, 2016

@alexcrichton I personally find this reasoning fairly persuasive, at least on first read. I agree that there is a lot to be worked out with respect to code generation -- I've been wondering how we can find just the right set of people to get motivated and make it actually happen. =) (You'll note I talk big, but I'm not volunteering...) Given that there is more of an extant community around embedded computing, it seems likely that it will be more actionable. I am particularly interested in the ways that "embedded" might benefit things beyond embedded architectures.


@nagisa

Everything else being same, the paragraph could look like this instead: (reworded text follows)

That sounds good to me too.

@jonathandturner

This comment has been minimized.

Show comment
Hide comment
@jonathandturner

jonathandturner Nov 3, 2016

Contributor

Sorry it took so long - I just posted the commercial user survey results.

To @alexcrichton's points: while we definitely saw embedded systems and the need for C++ interop mentioned together, the need for better C++ interop came from a much broader audience. I think it's more fair to say that it went hand-in-hand with "resource constrained" fields, whether embedded, VR, professional video game dev, etc. That said, I definitely agree we should try to experiment first so we know exactly what we're signing up for, what's possible, and what is unreasonable to expect. For me, the big takeaway here was similar to the need for better IDE support. People got used to having good IDE support, so it felt like a step down to switch to Rust. If the switching cost is too high, people will stay with what they have.

Contributor

jonathandturner commented Nov 3, 2016

Sorry it took so long - I just posted the commercial user survey results.

To @alexcrichton's points: while we definitely saw embedded systems and the need for C++ interop mentioned together, the need for better C++ interop came from a much broader audience. I think it's more fair to say that it went hand-in-hand with "resource constrained" fields, whether embedded, VR, professional video game dev, etc. That said, I definitely agree we should try to experiment first so we know exactly what we're signing up for, what's possible, and what is unreasonable to expect. For me, the big takeaway here was similar to the need for better IDE support. People got used to having good IDE support, so it felt like a step down to switch to Rust. If the switching cost is too high, people will stay with what they have.

@chriskrycho

This comment has been minimized.

Show comment
Hide comment
@chriskrycho

chriskrycho Nov 3, 2016

Contributor

Following up on that from the just-a-user-and-enthusiast perspective: the progress that the IntelliJ-Rust team is making is quite impressive—and that's without a mature language server, as a spare-time kind of project. Speaking from experience, even just smart-tools-in-a-text-editor go a long way, but all of those I've tried so far have serious limitations and bugs. They crash, or they provide results sometimes but not others, or they end up being slow... you get used to working around all of those things, but 👍 times 💯 for making those things a real priority.

Contributor

chriskrycho commented Nov 3, 2016

Following up on that from the just-a-user-and-enthusiast perspective: the progress that the IntelliJ-Rust team is making is quite impressive—and that's without a mature language server, as a spare-time kind of project. Speaking from experience, even just smart-tools-in-a-text-editor go a long way, but all of those I've tried so far have serious limitations and bugs. They crash, or they provide results sometimes but not others, or they end up being slow... you get used to working around all of those things, but 👍 times 💯 for making those things a real priority.

@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Nov 4, 2016

Member

@jonathandturner yeah I was originally going to propose we move C++ to an "area of support" rather than a top-level goal, but I ended up deciding against that and instead thinking we should unify the goal for C++/embedded to the same goal.

That is, I definitely agree that we could capitalize quite a lot on better C++ interop, but I think we could also capitalize quite a bit on better embedded work. In that sense I didn't find it quite right that we claimed C++ as a goal but not embedded, but that's just my own personal thought!

Member

alexcrichton commented Nov 4, 2016

@jonathandturner yeah I was originally going to propose we move C++ to an "area of support" rather than a top-level goal, but I ended up deciding against that and instead thinking we should unify the goal for C++/embedded to the same goal.

That is, I definitely agree that we could capitalize quite a lot on better C++ interop, but I think we could also capitalize quite a bit on better embedded work. In that sense I didn't find it quite right that we claimed C++ as a goal but not embedded, but that's just my own personal thought!

@Ericson2314

This comment has been minimized.

Show comment
Hide comment
@Ericson2314

Ericson2314 Nov 4, 2016

Contributor

I'd like to point out that in many cases the methodology for C++ and embedded are opposite. @japaric's and my approach is focused on avoiding or rewriting legacy tools and libraries---overall simplicity via a clean slate, and simplicity that no one working in the embedded space has access to today. Working with C++ necessitates embracing legacy....everything, even if it doesn't infect the definition of Rust as others have pointed out.

Note, I do think that it's possible to do some C++ interopt without garbaging up Rust for everyone else, but I'm going to go out on a limb and say this is vastly more difficult and/or less rewarding than most survey respondents appreciate---we don't want union-level support for every C++ construct. Also while Python/Ruby/Java/Haskell/<insert higher-order gc'd langauge> is something you'd conceivably maybe want long term, C++ interopt is more strictly transitional as Rust aims to shine everywhere C++ is applicable.

Contributor

Ericson2314 commented Nov 4, 2016

I'd like to point out that in many cases the methodology for C++ and embedded are opposite. @japaric's and my approach is focused on avoiding or rewriting legacy tools and libraries---overall simplicity via a clean slate, and simplicity that no one working in the embedded space has access to today. Working with C++ necessitates embracing legacy....everything, even if it doesn't infect the definition of Rust as others have pointed out.

Note, I do think that it's possible to do some C++ interopt without garbaging up Rust for everyone else, but I'm going to go out on a limb and say this is vastly more difficult and/or less rewarding than most survey respondents appreciate---we don't want union-level support for every C++ construct. Also while Python/Ruby/Java/Haskell/<insert higher-order gc'd langauge> is something you'd conceivably maybe want long term, C++ interopt is more strictly transitional as Rust aims to shine everywhere C++ is applicable.

@glaebhoerl

This comment has been minimized.

Show comment
Hide comment
@glaebhoerl

glaebhoerl Nov 7, 2016

Contributor

Here's what I think the logic behind focusing specifically on C++ interoperability would be:

Rust's mission, implicitly or explicitly, the reason it was created, is to try to do something about the sorry current state of affairs where so much software is written in highly memory-unsafe low-level languages, and has lots and lots of avoidable security vulnerabilities as a consequence.

If we want Rust to be a remotely viable option not only for green-field projects, but for existing projects written in those languages to transition to, then Rust needs to interoperate really really well with those languages. (The whole "embrace, extend..." thing.)

Having code be written in Rust instead of in other, high-level, (largely-)memory-safe languages may also be nice, in as far as it gives Rust-the-project more momentum, and maybe that code will run faster, but it isn't as much a part of the "core mission" from my perspective.

I do agree that, given that interoperating really really well with C is sort of a prerequisite to, or at the very least also contributes to, interoperating really really with C++, it might make sense to focus more effort on that first half at first, because of the broader applicability and presumably smaller technical hurdles. (And interoperating really well with C tends to also be part of interoperating really well with all those other languages, due to its lowest common denominator status, so in that sense it contributes to both goals.)

(I also agree 100% with @brson and others that keeping the semantics and definition of Rust clean is a higher goal, and we should not let it become entangled with the semantics or definition of C++ while in pursuit of better interoperability with it. On the other hand, for mixed C++/Rust projects I can imagine linking with or shelling out to libclang or whatever we need to do to make it work smoothly. I... kind of feel like those are separate things?)

Contributor

glaebhoerl commented Nov 7, 2016

Here's what I think the logic behind focusing specifically on C++ interoperability would be:

Rust's mission, implicitly or explicitly, the reason it was created, is to try to do something about the sorry current state of affairs where so much software is written in highly memory-unsafe low-level languages, and has lots and lots of avoidable security vulnerabilities as a consequence.

If we want Rust to be a remotely viable option not only for green-field projects, but for existing projects written in those languages to transition to, then Rust needs to interoperate really really well with those languages. (The whole "embrace, extend..." thing.)

Having code be written in Rust instead of in other, high-level, (largely-)memory-safe languages may also be nice, in as far as it gives Rust-the-project more momentum, and maybe that code will run faster, but it isn't as much a part of the "core mission" from my perspective.

I do agree that, given that interoperating really really well with C is sort of a prerequisite to, or at the very least also contributes to, interoperating really really with C++, it might make sense to focus more effort on that first half at first, because of the broader applicability and presumably smaller technical hurdles. (And interoperating really well with C tends to also be part of interoperating really well with all those other languages, due to its lowest common denominator status, so in that sense it contributes to both goals.)

(I also agree 100% with @brson and others that keeping the semantics and definition of Rust clean is a higher goal, and we should not let it become entangled with the semantics or definition of C++ while in pursuit of better interoperability with it. On the other hand, for mixed C++/Rust projects I can imagine linking with or shelling out to libclang or whatever we need to do to make it work smoothly. I... kind of feel like those are separate things?)

@chriskrycho

This comment has been minimized.

Show comment
Hide comment
@chriskrycho

chriskrycho Nov 7, 2016

Contributor

I think @glaebhoerl's comment is largely on target, especially this:

I do agree that, given that interoperating really really well with C is sort of a prerequisite to, or at the very least also contributes to, interoperating really really with C++, it might make sense to focus more effort on that first half at first, because of the broader applicability and presumably smaller technical hurdles. (And interoperating really well with C tends to also be part of interoperating really well with all those other languages, due to its lowest common denominator status, so in that sense it contributes to both goals.)

That said, I do disagree a bit with this part:

Replacing code written in other, higher-level, (largely-)memory-safe languages with code written in Rust may also be nice, in as far as it gives Rust-the-project more momentum, and maybe that code will run faster, but it isn't as much a part of the "core mission" from my perspective.

Here's why:

  1. I think Rust's core mission should absolutely include being a good replacement for C and C++, and it should never compromise its ability to be that kind of replacement. However, I don't think that should define it or be its core mission. Safe, fast, and productive (whether adopted as official slogan or no) makes it an incredibly valuable tool in a lot of spaces.

    Given a choice, it's increasingly up in the air for me whether to write small tools in Rust or Python, because I get so much performance and reliability out of writing it in Rust, and that is increasingly worth it to me as I grow weary of the debugging cycles when writing Python/JS/etc. That goes even for little helper tools. That's a big part of what I come to Rust for, and I don't think Rust should compromise on that, either.

  2. Part and parcel with that: I think part of the way Rust begins to actively replace C (and to some extent C++) is precisely by being the tool of choice when people need to write native extensions for Ruby, JS, Python, Elixir/Erlang, etc. Don't underestimate how large that chunk of code in the world is. There are a lot of hot loops out there being unsafely optimized by C right now. Making Rust a really great option there means a lot of people will use it instead of C; but it also means that quite a few people will optimize those hot loops with native code instead of just not writing native code.

  3. One consequence of that: Rust "democratizing" the experience of writing systems-level code deeply changes the dynamics of adoption. Having a lot more people writing at that level—and thereby being enabled to contribute to projects which historically might have used C or C++ instead—makes Rust a replacement of a very different kind. It's not just "replace one super hard thing with another super hard thing, just shuffling around what's hard". It's actually making it far likelier that a lot more people will be writing reliable systems-level code at all.

    In the same way that it really didn't matter how big Windows was when mobile exploded, sometimes the way you supersede something isn't so much by replacing it directly, but rather by doing something that completely subsumes it.

It's important to be able to bridge this specific gap for corporate users, to be sure. We should definitely include C++ interop as one item to improve. Anywhere we can sand off edges for FFI in general, we should. But developer ergonomics, IDE support, general FFI improvements, etc. all seem like more important priorities than C++-specific interop from where I stand.

Contributor

chriskrycho commented Nov 7, 2016

I think @glaebhoerl's comment is largely on target, especially this:

I do agree that, given that interoperating really really well with C is sort of a prerequisite to, or at the very least also contributes to, interoperating really really with C++, it might make sense to focus more effort on that first half at first, because of the broader applicability and presumably smaller technical hurdles. (And interoperating really well with C tends to also be part of interoperating really well with all those other languages, due to its lowest common denominator status, so in that sense it contributes to both goals.)

That said, I do disagree a bit with this part:

Replacing code written in other, higher-level, (largely-)memory-safe languages with code written in Rust may also be nice, in as far as it gives Rust-the-project more momentum, and maybe that code will run faster, but it isn't as much a part of the "core mission" from my perspective.

Here's why:

  1. I think Rust's core mission should absolutely include being a good replacement for C and C++, and it should never compromise its ability to be that kind of replacement. However, I don't think that should define it or be its core mission. Safe, fast, and productive (whether adopted as official slogan or no) makes it an incredibly valuable tool in a lot of spaces.

    Given a choice, it's increasingly up in the air for me whether to write small tools in Rust or Python, because I get so much performance and reliability out of writing it in Rust, and that is increasingly worth it to me as I grow weary of the debugging cycles when writing Python/JS/etc. That goes even for little helper tools. That's a big part of what I come to Rust for, and I don't think Rust should compromise on that, either.

  2. Part and parcel with that: I think part of the way Rust begins to actively replace C (and to some extent C++) is precisely by being the tool of choice when people need to write native extensions for Ruby, JS, Python, Elixir/Erlang, etc. Don't underestimate how large that chunk of code in the world is. There are a lot of hot loops out there being unsafely optimized by C right now. Making Rust a really great option there means a lot of people will use it instead of C; but it also means that quite a few people will optimize those hot loops with native code instead of just not writing native code.

  3. One consequence of that: Rust "democratizing" the experience of writing systems-level code deeply changes the dynamics of adoption. Having a lot more people writing at that level—and thereby being enabled to contribute to projects which historically might have used C or C++ instead—makes Rust a replacement of a very different kind. It's not just "replace one super hard thing with another super hard thing, just shuffling around what's hard". It's actually making it far likelier that a lot more people will be writing reliable systems-level code at all.

    In the same way that it really didn't matter how big Windows was when mobile exploded, sometimes the way you supersede something isn't so much by replacing it directly, but rather by doing something that completely subsumes it.

It's important to be able to bridge this specific gap for corporate users, to be sure. We should definitely include C++ interop as one item to improve. Anywhere we can sand off edges for FFI in general, we should. But developer ergonomics, IDE support, general FFI improvements, etc. all seem like more important priorities than C++-specific interop from where I stand.

@hauleth

This comment has been minimized.

Show comment
Hide comment
@hauleth

hauleth Nov 7, 2016

I have a question about features that have been hanging from some time and some people still waits for them to hit mainline, especially associated constants. Are there any stabilization plans? It would be very handy in Octavo design.

hauleth commented Nov 7, 2016

I have a question about features that have been hanging from some time and some people still waits for them to hit mainline, especially associated constants. Are there any stabilization plans? It would be very handy in Octavo design.

@jonathandturner

This comment has been minimized.

Show comment
Hide comment
@jonathandturner

jonathandturner Nov 7, 2016

Contributor

I think @chriskrycho's comments bring a lot of stuff up in a really useful way. I'm having serious doubts that I'll be as eloquent as him :)

Doing this planning it feels like we're talking not just about focus, but also how we balance our energies across various opportunities. Our energy is limited, so we're making educated guess on just how to distribute it over the next year.

If we look at both surveys, some themes are clearly important. Learning curve is a must. Both surveys point it out. Same is true for better library support and IDE support. We know that improvements in these three areas help lots of users, and we should be spending our energy on them.

To me, where the two survey results differ is also interesting. Compile times were mentioned more often by commercial users than by the larger community. We as developers don't necessarily feel this pain, at least at first. Once our projects get big enough, we start to notice. Commercial users investing longer hours in Rust hit this sooner and feel it more as a pressing need.

FFI similarly was mentioned far more often by the commercial users than the larger community. To me, the theme here, like @glaebhoerl says, it's a sense of green-field vs integration. Commercial users are going to naturally do more of the latter.

Why C++ though? Because that's what people are specifically asking for. I suspect this might be like the compile time pain. If some of us haven't hit that yet, we don't see it as a sore spot. I went back and looked at the general survey raw data to see how often C++ interop was brought up when people asked for better FFI: of the 23 requests for better interop, 18 were people asking for better C++ interop. If we're going to spend time on FFI, improving C++ should be our primary goal, with our secondary goal being further improving broader FFI.

It comes back to taking educated guess. We have the survey data, we know that some industries are built on piles of C++ code, and we know we want Rust to be used in as many places as possible. I see it as a way for us to "stretch". A way we might be able to reach industries we aren't currently reaching.

Contributor

jonathandturner commented Nov 7, 2016

I think @chriskrycho's comments bring a lot of stuff up in a really useful way. I'm having serious doubts that I'll be as eloquent as him :)

Doing this planning it feels like we're talking not just about focus, but also how we balance our energies across various opportunities. Our energy is limited, so we're making educated guess on just how to distribute it over the next year.

If we look at both surveys, some themes are clearly important. Learning curve is a must. Both surveys point it out. Same is true for better library support and IDE support. We know that improvements in these three areas help lots of users, and we should be spending our energy on them.

To me, where the two survey results differ is also interesting. Compile times were mentioned more often by commercial users than by the larger community. We as developers don't necessarily feel this pain, at least at first. Once our projects get big enough, we start to notice. Commercial users investing longer hours in Rust hit this sooner and feel it more as a pressing need.

FFI similarly was mentioned far more often by the commercial users than the larger community. To me, the theme here, like @glaebhoerl says, it's a sense of green-field vs integration. Commercial users are going to naturally do more of the latter.

Why C++ though? Because that's what people are specifically asking for. I suspect this might be like the compile time pain. If some of us haven't hit that yet, we don't see it as a sore spot. I went back and looked at the general survey raw data to see how often C++ interop was brought up when people asked for better FFI: of the 23 requests for better interop, 18 were people asking for better C++ interop. If we're going to spend time on FFI, improving C++ should be our primary goal, with our secondary goal being further improving broader FFI.

It comes back to taking educated guess. We have the survey data, we know that some industries are built on piles of C++ code, and we know we want Rust to be used in as many places as possible. I see it as a way for us to "stretch". A way we might be able to reach industries we aren't currently reaching.

@steveklabnik

This comment has been minimized.

Show comment
Hide comment
@steveklabnik

steveklabnik Nov 7, 2016

Member

@hauleth in general, asking about it on the tracking threads for those features is the best bet; that's too in-the-weeds for this RFC's goals. rust-lang/rust#29646 for associated consts, specifically.

Member

steveklabnik commented Nov 7, 2016

@hauleth in general, asking about it on the tracking threads for those features is the best bet; that's too in-the-weeds for this RFC's goals. rust-lang/rust#29646 for associated consts, specifically.

@burdges

This comment has been minimized.

Show comment
Hide comment
@burdges

burdges Nov 7, 2016

I'd kinda imagine higher-level FFI features like improved C++ interoperability might be handled mostly externally to rustc itself by allowing rustc to export or import more. In any case, an FFI goes both ways, but maybe it's easier to export tools for linking to Rust than to import unsafe languages. An interesting project would be to compile Rust library code into a wrapper header file for C++. I'd think that'd be orthogonal enough to rustc itself, and well enough defined, that a commercial user might reasonably be willing to let their own people spend time doing it.

burdges commented Nov 7, 2016

I'd kinda imagine higher-level FFI features like improved C++ interoperability might be handled mostly externally to rustc itself by allowing rustc to export or import more. In any case, an FFI goes both ways, but maybe it's easier to export tools for linking to Rust than to import unsafe languages. An interesting project would be to compile Rust library code into a wrapper header file for C++. I'd think that'd be orthogonal enough to rustc itself, and well enough defined, that a commercial user might reasonably be willing to let their own people spend time doing it.

@Ericson2314

This comment has been minimized.

Show comment
Hide comment
@Ericson2314

Ericson2314 Nov 7, 2016

Contributor

@burdges So exporting Rust for C++ done right means C++-driven, on-demand monomorphization, and I don't see how to do this right other than making incremental rustc a clang plugin (or hacked up clang if there is no support for plugins in clang today). Maybe there's lower hanging fruit for 2017, but that there will take more than a year, or more full-time developers.

And that will be nicely reusable for Haskell, so yes its my favorite part of C++-but-not-C support :D.

Contributor

Ericson2314 commented Nov 7, 2016

@burdges So exporting Rust for C++ done right means C++-driven, on-demand monomorphization, and I don't see how to do this right other than making incremental rustc a clang plugin (or hacked up clang if there is no support for plugins in clang today). Maybe there's lower hanging fruit for 2017, but that there will take more than a year, or more full-time developers.

And that will be nicely reusable for Haskell, so yes its my favorite part of C++-but-not-C support :D.

@aturon

This comment has been minimized.

Show comment
Hide comment
@aturon

aturon Nov 9, 2016

Member

The recent discussion here has been outstanding; thanks everyone!

I'm going to try to summarize and respond to some of the major points below.

  • Based on our data and anecdotal experience, "C++ integration" is by far the most frequently-desired FFI scenario among both existing commercial users, and some of the very large organizations we've spoken to with interest in Rust.
    • Regarding @alexcrichton's point about distinguishing between using C++ from Rust and vice versa: in most cases the issue is that there's a vast existing C++ code base, so making it easy to use C++ from Rust is probably where we'd get the biggest bang for our buck.
  • At the same time, there are two other adoption vectors that are currently less emphasized in the roadmap:
    • Embedded devices. This was mentioned as an "area of support" but not one of the vision statements. The primary issue is that, while Rust is likely a good match for this area, we don't have a good handle on potential commercial users or avenue toward/obstacles for adoption. @alexcrichton mentions some work we may want to tackle that would clearly benefit the embedded space but it's not so obvious that this puts us on a track to real adoption. (This is in contrast to the server goal, where there's a relatively clear path toward what's needed for adoption in the niches where Rust would fit best.)
    • Interop with higher-level languages. @chriskrycho makes an eloquent argument that "native extensions" have massive potential as a growth market for Rust, and in particular an area where Rust can grow the overall pool of "systems programmers". It'd be worthwhile to dig in a little bit to what we could best do to support this use-case. One possibility is to invest effort in direct interop efforts, like those outlined as an area of support. But it's possible that work on making our C FFI story better would also provide across-the-board benefits here.
  • Several people have pointed out that work on C++ likely includes work on C as a prerequisite. One possibility would be to refocus the goal on C specifically, which (as mentioned above) may have more widespread benefits. The downside, of course, is that if we don't actually strengthen our C++ integration story, we haven't managed to serve those big commercial users mentioned at the outset.
  • It's also been noted that the C++ goal as stated is likely just plain too ambitious for a year's time.

Encouragingly, everything that's coming up in this discussion is featured somewhere in the roadmap! It's just a question of finding the right balance of focus.

For the roadmap to be effective, I think it's vital that it be focused -- which inevitably means saying "no" to some opportunities. My takeaway from the discussion so far is that we've probably gone too far on the C++ front, and not far enough on the current "areas of support".

What'd be most helpful to drive the discussion forward would be to start pitching some high-level "vision statements" along the lines of the current ones in the roadmap. @alexcrichton took one stab at this with "Rust should easily support embedded development", but as he suspected, I think this is a little bit too vague, and in particular relies on the ambiguity around the "embedded" term. The more crisp we can make the statements, the better. So, to take the examples @alexcrichton was giving, the vision statement might be something more like:

  • Rust should provide support for a wide and growing range of platforms, including resource-constrained ones.

Work like std-aware Cargo, scenarios, SIMD, OOM-handling, the std facade, and so on all fit under this rubric.

Can we iterate on some other possible vision statements that encompass work that's currently relegated to "areas of support"? And, similarly, a more realistic version of the goal around C/C++? Having a more concrete grasp on what's feasible in each area over the next year might put us in a better position to weigh the tradeoffs.

Member

aturon commented Nov 9, 2016

The recent discussion here has been outstanding; thanks everyone!

I'm going to try to summarize and respond to some of the major points below.

  • Based on our data and anecdotal experience, "C++ integration" is by far the most frequently-desired FFI scenario among both existing commercial users, and some of the very large organizations we've spoken to with interest in Rust.
    • Regarding @alexcrichton's point about distinguishing between using C++ from Rust and vice versa: in most cases the issue is that there's a vast existing C++ code base, so making it easy to use C++ from Rust is probably where we'd get the biggest bang for our buck.
  • At the same time, there are two other adoption vectors that are currently less emphasized in the roadmap:
    • Embedded devices. This was mentioned as an "area of support" but not one of the vision statements. The primary issue is that, while Rust is likely a good match for this area, we don't have a good handle on potential commercial users or avenue toward/obstacles for adoption. @alexcrichton mentions some work we may want to tackle that would clearly benefit the embedded space but it's not so obvious that this puts us on a track to real adoption. (This is in contrast to the server goal, where there's a relatively clear path toward what's needed for adoption in the niches where Rust would fit best.)
    • Interop with higher-level languages. @chriskrycho makes an eloquent argument that "native extensions" have massive potential as a growth market for Rust, and in particular an area where Rust can grow the overall pool of "systems programmers". It'd be worthwhile to dig in a little bit to what we could best do to support this use-case. One possibility is to invest effort in direct interop efforts, like those outlined as an area of support. But it's possible that work on making our C FFI story better would also provide across-the-board benefits here.
  • Several people have pointed out that work on C++ likely includes work on C as a prerequisite. One possibility would be to refocus the goal on C specifically, which (as mentioned above) may have more widespread benefits. The downside, of course, is that if we don't actually strengthen our C++ integration story, we haven't managed to serve those big commercial users mentioned at the outset.
  • It's also been noted that the C++ goal as stated is likely just plain too ambitious for a year's time.

Encouragingly, everything that's coming up in this discussion is featured somewhere in the roadmap! It's just a question of finding the right balance of focus.

For the roadmap to be effective, I think it's vital that it be focused -- which inevitably means saying "no" to some opportunities. My takeaway from the discussion so far is that we've probably gone too far on the C++ front, and not far enough on the current "areas of support".

What'd be most helpful to drive the discussion forward would be to start pitching some high-level "vision statements" along the lines of the current ones in the roadmap. @alexcrichton took one stab at this with "Rust should easily support embedded development", but as he suspected, I think this is a little bit too vague, and in particular relies on the ambiguity around the "embedded" term. The more crisp we can make the statements, the better. So, to take the examples @alexcrichton was giving, the vision statement might be something more like:

  • Rust should provide support for a wide and growing range of platforms, including resource-constrained ones.

Work like std-aware Cargo, scenarios, SIMD, OOM-handling, the std facade, and so on all fit under this rubric.

Can we iterate on some other possible vision statements that encompass work that's currently relegated to "areas of support"? And, similarly, a more realistic version of the goal around C/C++? Having a more concrete grasp on what's feasible in each area over the next year might put us in a better position to weigh the tradeoffs.

@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Nov 10, 2016

Member

@aturon

I think you've hit the nail on the head, this sounds spot on. I think one thing that may help me at least is to lay out some of the improvements I think are reasonable to expect in the next year's time in these areas. This is by no means a comprehensive list, and may not even be ambitious enough, but my thoughts are:

  • On the C++/C front, we should have crisp and clear guidelines of actually how to integrate Rust. Right now the story is: well I created a staticlib, now what? There's devilish details around build system integration, getting linker flags to work, doing this all in a cross platform fashion, and dealing with external native dependencies (e.g. libgit2, curl, etc). I feel like we could go a long way here just providing a massive amount of elbow grease to guidelines, guides, fixing papercuts, and just all around making it a smooth experience to actually getting Rust code running in your app (given that code exists).
  • On the running in other languages front, I think a lot of great work is happening on projects like neon and helix. I think they're the best start points for seeing how this goes, so if we're serious about integrating into other languages we'd start drawing attention and helping out these projects (specifically neon/helix). Over time we could learn from our experiences and see if a similar Python-like (or Lua, other scripting languages, etc) solution would emerge and we could have a common ground.
  • On the embedded devices front, as I mentioned before, I can see scenarios and std-aware Cargo having large impacts here.
  • Again on the C++ front, we could start helping out bindgen. Basically we could start helping out the project and put a lot of the polish and elbow grease in like mentioned above with "what to do after a staticlib". Fixes could include shipping precompiled binaries of libclang for easy installation, handling of standard headers with the libc crate itself, ensuring the cross-compilation story is solid, etc.
  • Furthermore on the embedded devices front we could see renewed effort behind rustup NDK support as well, creating the framework and then filling it out for all manner of (host, target) pairs to ensure as smooth an experience as possible when compiling for any target. This, combined with std-aware-cargo, could make everything "even more pushbutton".

Well those are some ideas of projects I'm thinking of at least. I think they're all at least individually quite attainable in the timespan of a year (given other goals as well), although perhaps tackling all of them isn't feasible.

I was hoping thinking about that would lead to an answer of how to fill in "Rust should ...", but unfortunately I'm still drawing a blank. I agree that my proposal above is too vague.


Ok, giving that a few more minutes of thought, how about this:

  • Rust should support push-button style embedding into other languages and runtimes.

That is, instead of focusing on C++, we start pushing more on the other runtimes front. This in turn will likely require better bindgen support which is what we wanted for C++ anyway, although perhaps not as far along the C++ track. My assumption though is that it would position us to relatively easily cross that finish line later. Additionally push-button style runtime support would put a lot of pressure on the sharp edges of linking Rust into other applications, again solving problems with integrating Rust into C++ (build system problems, linking problems, etc). Finally, we've got great starts on the language specific fronts with Ruby/JS so I think it's more than reasonable enough to expect a solid experience with at least one of them by the end of the year.

Thoughts about that? In essence it's just swapping the languages "area of support" with the C++ goal, but with one method of interpretation the C++ goals would fit in language support and the language support may be more attainable?

Member

alexcrichton commented Nov 10, 2016

@aturon

I think you've hit the nail on the head, this sounds spot on. I think one thing that may help me at least is to lay out some of the improvements I think are reasonable to expect in the next year's time in these areas. This is by no means a comprehensive list, and may not even be ambitious enough, but my thoughts are:

  • On the C++/C front, we should have crisp and clear guidelines of actually how to integrate Rust. Right now the story is: well I created a staticlib, now what? There's devilish details around build system integration, getting linker flags to work, doing this all in a cross platform fashion, and dealing with external native dependencies (e.g. libgit2, curl, etc). I feel like we could go a long way here just providing a massive amount of elbow grease to guidelines, guides, fixing papercuts, and just all around making it a smooth experience to actually getting Rust code running in your app (given that code exists).
  • On the running in other languages front, I think a lot of great work is happening on projects like neon and helix. I think they're the best start points for seeing how this goes, so if we're serious about integrating into other languages we'd start drawing attention and helping out these projects (specifically neon/helix). Over time we could learn from our experiences and see if a similar Python-like (or Lua, other scripting languages, etc) solution would emerge and we could have a common ground.
  • On the embedded devices front, as I mentioned before, I can see scenarios and std-aware Cargo having large impacts here.
  • Again on the C++ front, we could start helping out bindgen. Basically we could start helping out the project and put a lot of the polish and elbow grease in like mentioned above with "what to do after a staticlib". Fixes could include shipping precompiled binaries of libclang for easy installation, handling of standard headers with the libc crate itself, ensuring the cross-compilation story is solid, etc.
  • Furthermore on the embedded devices front we could see renewed effort behind rustup NDK support as well, creating the framework and then filling it out for all manner of (host, target) pairs to ensure as smooth an experience as possible when compiling for any target. This, combined with std-aware-cargo, could make everything "even more pushbutton".

Well those are some ideas of projects I'm thinking of at least. I think they're all at least individually quite attainable in the timespan of a year (given other goals as well), although perhaps tackling all of them isn't feasible.

I was hoping thinking about that would lead to an answer of how to fill in "Rust should ...", but unfortunately I'm still drawing a blank. I agree that my proposal above is too vague.


Ok, giving that a few more minutes of thought, how about this:

  • Rust should support push-button style embedding into other languages and runtimes.

That is, instead of focusing on C++, we start pushing more on the other runtimes front. This in turn will likely require better bindgen support which is what we wanted for C++ anyway, although perhaps not as far along the C++ track. My assumption though is that it would position us to relatively easily cross that finish line later. Additionally push-button style runtime support would put a lot of pressure on the sharp edges of linking Rust into other applications, again solving problems with integrating Rust into C++ (build system problems, linking problems, etc). Finally, we've got great starts on the language specific fronts with Ruby/JS so I think it's more than reasonable enough to expect a solid experience with at least one of them by the end of the year.

Thoughts about that? In essence it's just swapping the languages "area of support" with the C++ goal, but with one method of interpretation the C++ goals would fit in language support and the language support may be more attainable?

@nikomatsakis

This comment has been minimized.

Show comment
Hide comment
@nikomatsakis

nikomatsakis Nov 11, 2016

Contributor

@alexcrichton

Rust should support push-button style embedding into other languages and runtimes.

I think the primary reason we were picking C++ over broad language like this was a desire to be specific -- that is, a feeling that we have limited resources, and hence we should try and narrow down what we ought to focus on. As @aturon put it:

For the roadmap to be effective, I think it's vital that it be focused -- which inevitably means saying "no" to some opportunities. My takeaway from the discussion so far is that we've probably gone too far on the C++ front, and not far enough on the current "areas of support".

But in this case I tend to agree that focusing on C++ feels premature. There is lots to be done, and at least in the short term I think most of the progress here is going to happen in the realm of "areas of support". Moreover, I think it's a bit hard to predict what kinds of embedding are going to be most important -- for example, in the last few weeks, the possibility of working smoothly with GNOME has arisen, which doesn't exactly fit the C++ mold, but fits just fine into your more general formulation.

So I'd be up for broadening the focus. In any case, I tend to think that a lot of the energy and leadership here is going to come from outside the current set of "core Rust contributors" (this is the idea of areas of support, after all), but the point is that we are happy to entertain RFCs, library support, or language features, if they are needed to make this integration work. (I think the work that @japaric has been doing in pushing along the embedded space is a good example of this in action, not to mention neon and helix.)

All of that said, I still think that making bindgen integration smooth is very important, and we should look for opportunities to help with C++ binding, and not just C. This kind of support tends to be a prerequisite for most other embedding work (many languages use C, but many projects use C++ as well -- think of V8, for example).

Contributor

nikomatsakis commented Nov 11, 2016

@alexcrichton

Rust should support push-button style embedding into other languages and runtimes.

I think the primary reason we were picking C++ over broad language like this was a desire to be specific -- that is, a feeling that we have limited resources, and hence we should try and narrow down what we ought to focus on. As @aturon put it:

For the roadmap to be effective, I think it's vital that it be focused -- which inevitably means saying "no" to some opportunities. My takeaway from the discussion so far is that we've probably gone too far on the C++ front, and not far enough on the current "areas of support".

But in this case I tend to agree that focusing on C++ feels premature. There is lots to be done, and at least in the short term I think most of the progress here is going to happen in the realm of "areas of support". Moreover, I think it's a bit hard to predict what kinds of embedding are going to be most important -- for example, in the last few weeks, the possibility of working smoothly with GNOME has arisen, which doesn't exactly fit the C++ mold, but fits just fine into your more general formulation.

So I'd be up for broadening the focus. In any case, I tend to think that a lot of the energy and leadership here is going to come from outside the current set of "core Rust contributors" (this is the idea of areas of support, after all), but the point is that we are happy to entertain RFCs, library support, or language features, if they are needed to make this integration work. (I think the work that @japaric has been doing in pushing along the embedded space is a good example of this in action, not to mention neon and helix.)

All of that said, I still think that making bindgen integration smooth is very important, and we should look for opportunities to help with C++ binding, and not just C. This kind of support tends to be a prerequisite for most other embedding work (many languages use C, but many projects use C++ as well -- think of V8, for example).

@DenisKolodin

This comment has been minimized.

Show comment
Hide comment
@DenisKolodin

DenisKolodin Nov 12, 2016

I think we also need to dedicate some attention to educate about macros. Actually Rust developers spend 20% of their time writing macros, but this topic is on the sideline.

I think we also need to dedicate some attention to educate about macros. Actually Rust developers spend 20% of their time writing macros, but this topic is on the sideline.

@jonathandturner

This comment has been minimized.

Show comment
Hide comment
@jonathandturner

jonathandturner Nov 12, 2016

Contributor

@DenisKolodin - where did you get the information that "Actually Rust developers spend 20% of their time writing macros"? If someone is doing analysis of Rust developers' habits, I definitely want to read it :)

Contributor

jonathandturner commented Nov 12, 2016

@DenisKolodin - where did you get the information that "Actually Rust developers spend 20% of their time writing macros"? If someone is doing analysis of Rust developers' habits, I definitely want to read it :)

@ticki

This comment has been minimized.

Show comment
Hide comment
@ticki

ticki Nov 12, 2016

Contributor

20%?!?! That's definitely not a right number. It might be for new beginners, but for anyone beyond that, it is certainly not the case.

Contributor

ticki commented Nov 12, 2016

20%?!?! That's definitely not a right number. It might be for new beginners, but for anyone beyond that, it is certainly not the case.

@DenisKolodin

This comment has been minimized.

Show comment
Hide comment
@DenisKolodin

DenisKolodin Nov 12, 2016

No valid statistics, sorry ) I estimated it by share of time beginners spend to it. And there are a lot of duplications beginners do in their projects. It's subjective. Anyway, I mentioned it to attract to the problem. Macro is the first-class feature, but novices rare use it. We have a modest chapter in the book only. It simple to use, but hard to learn nowadays.

No valid statistics, sorry ) I estimated it by share of time beginners spend to it. And there are a lot of duplications beginners do in their projects. It's subjective. Anyway, I mentioned it to attract to the problem. Macro is the first-class feature, but novices rare use it. We have a modest chapter in the book only. It simple to use, but hard to learn nowadays.

@steveklabnik

This comment has been minimized.

Show comment
Hide comment
@steveklabnik

steveklabnik Nov 12, 2016

Member

Actually Rust developers spend 20% of their time writing macros, but this topic is on the sideline.

I have been writing Rust for almost four years now, and I've written exactly two macros, and they were both copy/paste/slightly edit ones.

More documentation would be great, though.

Member

steveklabnik commented Nov 12, 2016

Actually Rust developers spend 20% of their time writing macros, but this topic is on the sideline.

I have been writing Rust for almost four years now, and I've written exactly two macros, and they were both copy/paste/slightly edit ones.

More documentation would be great, though.

@eddyb

This comment has been minimized.

Show comment
Hide comment
@eddyb

eddyb Nov 12, 2016

Member

Paging @DanielKeep.

Member

eddyb commented Nov 12, 2016

Paging @DanielKeep.

@DanielKeep

This comment has been minimized.

Show comment
Hide comment
@DanielKeep

DanielKeep Nov 13, 2016

There's The Little Book of Rust Macros. It needs updating (Rust changes broke an entire chapter and I still haven't found a good replacement), but I'm not sure what it's lacking.

There's The Little Book of Rust Macros. It needs updating (Rust changes broke an entire chapter and I still haven't found a good replacement), but I'm not sure what it's lacking.

@phaazon

This comment has been minimized.

Show comment
Hide comment
@phaazon

phaazon Dec 21, 2016

Contributor

My reference for REPL is ghci, which is incredible, for all the points you mentionned and more: learning, discovering stuff, getting information on a type / kind / whatever, testing, debugging, live coding, doing the dishes and driving the kids to school. As I understand it, for now, the playpen is just something that compiles code on the fly and feeds the user output with the result of the program. A real REPL that could load a whole – several actually – crate(s) to let people explore them would be a very, very good adding to the ecosystem, because it would also help us to lower the learning curve by guiding people via interaction. I’m really into that. I think it’s more important than – for instance – IDE integration, but that’s only a subjective point of view.

A bit off topic – not sure though: is there a way to get one’s feet wet on rustc / cargo / anything Rust-like in our ecosystem? I’ve forked the project – rustc – and made some changes (no PR yet and not sure I’ll be able to make any) but it’s a very large and important piece of software. Is there any link to learn? Is there something planned for 2017 to enhance that and help new contributors to get aboard?

Contributor

phaazon commented Dec 21, 2016

My reference for REPL is ghci, which is incredible, for all the points you mentionned and more: learning, discovering stuff, getting information on a type / kind / whatever, testing, debugging, live coding, doing the dishes and driving the kids to school. As I understand it, for now, the playpen is just something that compiles code on the fly and feeds the user output with the result of the program. A real REPL that could load a whole – several actually – crate(s) to let people explore them would be a very, very good adding to the ecosystem, because it would also help us to lower the learning curve by guiding people via interaction. I’m really into that. I think it’s more important than – for instance – IDE integration, but that’s only a subjective point of view.

A bit off topic – not sure though: is there a way to get one’s feet wet on rustc / cargo / anything Rust-like in our ecosystem? I’ve forked the project – rustc – and made some changes (no PR yet and not sure I’ll be able to make any) but it’s a very large and important piece of software. Is there any link to learn? Is there something planned for 2017 to enhance that and help new contributors to get aboard?

@chriskrycho

This comment has been minimized.

Show comment
Hide comment
@chriskrycho

chriskrycho Dec 21, 2016

Contributor

@phaazon I'd add that much of the tooling that would enable a good REPL is probably shared with the kinds of things we need for a modern approach to IDEs, so it's a win-win.

On easy-jumping-in-points: see the E-Easy tag on rust proper, and similar on other repos.

Contributor

chriskrycho commented Dec 21, 2016

@phaazon I'd add that much of the tooling that would enable a good REPL is probably shared with the kinds of things we need for a modern approach to IDEs, so it's a win-win.

On easy-jumping-in-points: see the E-Easy tag on rust proper, and similar on other repos.

@mark-i-m

This comment has been minimized.

Show comment
Hide comment
@mark-i-m

mark-i-m Dec 22, 2016

Contributor

This is a really cool roadmap! It looks really exciting 😄

I am not sure if these points are too specific for the roadmap discussion (feel free to correct me), but with regards embedded and resource-constrained dev:

  • A year or so ago, I undertook a project to write a simple kernel in rust. I actually found that my greatest challenge was that rust is really dependent on the large standard library. In a kernel or embedded system, it is undesirable to have large libraries and binaries (sometimes its not possible at all). I ended up removing libstd (via #![nostd]) and implementing simple versions of data structures like Vec and String based on the standard library implementations. I like the scenarios idea a lot. But I would like it to go a lot further than simply unix and windows. It would be nice if we could choose an arbitrary subset of the std library to operate with, as the developer sees fitting or needful.

  • I am not sure if this is subsumed by "std-aware cargo", but there were some threads discussing factoring out platform dependent code into a separate portion of libstd (e.g. #1734). To my knowledge scenarios allow a developer to remove features from libstd, but there is currently no proposed way to replace small portions of libstd without just porting the whole thing. For example, in the toy kernel I mentioned above, it would be nice to be able to use the rust I/O libraries with a filesystem that is very un-unix-like and very un-windows-like. Most of the library doesn't really need to be ported, I just need to change some of the lower-level constructs that deal with the filesystem.

Finally, on the topic of C++ integration: I really believe that rust would make an ideal replacement for C++. It is a systems-level language. It compiles to native, optimized, safe binaries. These seem to be the main reasons (to my knowledge) that people use C++. Thus, IMHO, the motivation behind increased interoperability with C++ should not be interoperability itself, but simply making it easier for people to come to the rust community. This is also true of other languages too, but I see C++ developers as a target audience with specifically high potential.

Also, Merry Christmas everyone! And a happy New Year 🎆

Contributor

mark-i-m commented Dec 22, 2016

This is a really cool roadmap! It looks really exciting 😄

I am not sure if these points are too specific for the roadmap discussion (feel free to correct me), but with regards embedded and resource-constrained dev:

  • A year or so ago, I undertook a project to write a simple kernel in rust. I actually found that my greatest challenge was that rust is really dependent on the large standard library. In a kernel or embedded system, it is undesirable to have large libraries and binaries (sometimes its not possible at all). I ended up removing libstd (via #![nostd]) and implementing simple versions of data structures like Vec and String based on the standard library implementations. I like the scenarios idea a lot. But I would like it to go a lot further than simply unix and windows. It would be nice if we could choose an arbitrary subset of the std library to operate with, as the developer sees fitting or needful.

  • I am not sure if this is subsumed by "std-aware cargo", but there were some threads discussing factoring out platform dependent code into a separate portion of libstd (e.g. #1734). To my knowledge scenarios allow a developer to remove features from libstd, but there is currently no proposed way to replace small portions of libstd without just porting the whole thing. For example, in the toy kernel I mentioned above, it would be nice to be able to use the rust I/O libraries with a filesystem that is very un-unix-like and very un-windows-like. Most of the library doesn't really need to be ported, I just need to change some of the lower-level constructs that deal with the filesystem.

Finally, on the topic of C++ integration: I really believe that rust would make an ideal replacement for C++. It is a systems-level language. It compiles to native, optimized, safe binaries. These seem to be the main reasons (to my knowledge) that people use C++. Thus, IMHO, the motivation behind increased interoperability with C++ should not be interoperability itself, but simply making it easier for people to come to the rust community. This is also true of other languages too, but I see C++ developers as a target audience with specifically high potential.

Also, Merry Christmas everyone! And a happy New Year 🎆

@aturon

This comment has been minimized.

Show comment
Hide comment
@aturon

aturon Dec 23, 2016

Member

@chriskrycho

does the core team plan on turning this into a blog post for "kickoff"?

Yes, but I can't promise this will happen by Jan 1st, given some of the other things on our plate.

@liran-ringel

If rust could seamlessly use C++ code it would be a game changer that pushes it decades further. Many were really excited when saw it in the roadmap, and it is a real disappointment.

Yes, understood. But I think it was also clear that what we'd initially proposed is just not realistic to commit to in a year's timeframe. And do keep in mind that C++ integration remains a high priority in the current roadmap.

@mark-i-m

It would be nice if we could choose an arbitrary subset of the std library to operate with, as the developer sees fitting or needful.

This is a potential goal for the scenarios work, which will have an RFC in the near future. Alternatively, we might explore more work on the "std facade". In general, this kind of work falls into the area of exploration for embedded devices.

but there were some threads discussing factoring out platform dependent code into a separate portion of

You should take a look at the latest thinking, which is geared directly toward your goals.

Thus, IMHO, the motivation behind increased interoperability with C++ should not be interoperability itself, but simply making it easier for people to come to the rust community

Agreed. As the RFC itself says:

Rust adoption often depends on being able to start using it incrementally, and language integration is often a key to doing so -- an intuition substantiated by data from the survey and commercial outreach.

Member

aturon commented Dec 23, 2016

@chriskrycho

does the core team plan on turning this into a blog post for "kickoff"?

Yes, but I can't promise this will happen by Jan 1st, given some of the other things on our plate.

@liran-ringel

If rust could seamlessly use C++ code it would be a game changer that pushes it decades further. Many were really excited when saw it in the roadmap, and it is a real disappointment.

Yes, understood. But I think it was also clear that what we'd initially proposed is just not realistic to commit to in a year's timeframe. And do keep in mind that C++ integration remains a high priority in the current roadmap.

@mark-i-m

It would be nice if we could choose an arbitrary subset of the std library to operate with, as the developer sees fitting or needful.

This is a potential goal for the scenarios work, which will have an RFC in the near future. Alternatively, we might explore more work on the "std facade". In general, this kind of work falls into the area of exploration for embedded devices.

but there were some threads discussing factoring out platform dependent code into a separate portion of

You should take a look at the latest thinking, which is geared directly toward your goals.

Thus, IMHO, the motivation behind increased interoperability with C++ should not be interoperability itself, but simply making it easier for people to come to the rust community

Agreed. As the RFC itself says:

Rust adoption often depends on being able to start using it incrementally, and language integration is often a key to doing so -- an intuition substantiated by data from the survey and commercial outreach.

@JinShil

This comment has been minimized.

Show comment
Hide comment
@JinShil

JinShil Dec 24, 2016

Contributor

Rust should have a lower learning curve

I'm relatively new to Rust (been studying in my evenings and weekends for the past 3 months or so). I've been programming professionally in C, C++, and C# for the past 20+ years.

I have found learning Rust to be rather challenging, but I've had trouble putting my finger on why. The kind of work I'm doing right now in Rust is very low level. That is, I haven't had any need for ownership and borrowing...so it's not the borrow checker (it seems to often get the blame). Well, what is it, then?

I had somewhat of an epiphany this weekend while thinking about this. The problem isn't actually learning Rust. IMO the problem is that Rust's implementation is incomplete, compared to the languages I'm used to, so I'm forced to engineer other, odd ways of doing things to get around the limitations.

One such limitation is efficient code reuse; you all seem to know what I'm talking about. Without efficient code reuse, users have to engineer around it, and it's that re-engineering that's challenging; not learning the language.

Another limitation is syntax that should work, but doesn't, because noone's gotten around to implementing it yet (e.g. #1349, #322 (comment)).

When I encounter these things, I think I'm doing something wrong, or that I don't understand some fundamental concept, but actually, it's not me; it's just the fact that the feature I need or expect hasn't been implemented yet.

I understand that Rust is different, and we have to think a little differently when programming in Rust, but I haven't had much difficulty with that. More often than not, when I find myself struggling with a problem in Rust, I'll discover that the solution has already been proposed as an RFC(e.g. #1546, #1657), and had the RFC been approved and implemented already, I would't be struggling in the first place.

The point I'm hoping to make is that the solution to lowering the learning curve may not be documentation, tutorials, training, mentoring, error messages, etc..., but rather filling out the language with features that programmers expect to be there, so they don't have to "learn" workarounds. It is having to find alternate solutions within Rust's current limitations, while still trying to learn the language itself, that makes the learning curve so high.

Contributor

JinShil commented Dec 24, 2016

Rust should have a lower learning curve

I'm relatively new to Rust (been studying in my evenings and weekends for the past 3 months or so). I've been programming professionally in C, C++, and C# for the past 20+ years.

I have found learning Rust to be rather challenging, but I've had trouble putting my finger on why. The kind of work I'm doing right now in Rust is very low level. That is, I haven't had any need for ownership and borrowing...so it's not the borrow checker (it seems to often get the blame). Well, what is it, then?

I had somewhat of an epiphany this weekend while thinking about this. The problem isn't actually learning Rust. IMO the problem is that Rust's implementation is incomplete, compared to the languages I'm used to, so I'm forced to engineer other, odd ways of doing things to get around the limitations.

One such limitation is efficient code reuse; you all seem to know what I'm talking about. Without efficient code reuse, users have to engineer around it, and it's that re-engineering that's challenging; not learning the language.

Another limitation is syntax that should work, but doesn't, because noone's gotten around to implementing it yet (e.g. #1349, #322 (comment)).

When I encounter these things, I think I'm doing something wrong, or that I don't understand some fundamental concept, but actually, it's not me; it's just the fact that the feature I need or expect hasn't been implemented yet.

I understand that Rust is different, and we have to think a little differently when programming in Rust, but I haven't had much difficulty with that. More often than not, when I find myself struggling with a problem in Rust, I'll discover that the solution has already been proposed as an RFC(e.g. #1546, #1657), and had the RFC been approved and implemented already, I would't be struggling in the first place.

The point I'm hoping to make is that the solution to lowering the learning curve may not be documentation, tutorials, training, mentoring, error messages, etc..., but rather filling out the language with features that programmers expect to be there, so they don't have to "learn" workarounds. It is having to find alternate solutions within Rust's current limitations, while still trying to learn the language itself, that makes the learning curve so high.

@JinShil

This comment has been minimized.

Show comment
Hide comment
@JinShil

JinShil Dec 24, 2016

Contributor

One such limitation is efficient code reuse

In my original comment, I believe I may have misinterpreted what the author of #349 meant by "Efficient Code Reuse". I was thinking of efficiency in terms of programmer efficiency, not runtime efficiency. But, regardless of the interpretation, the issue does acknowlege a limitation, and any one of the the proposals that have attempted to address that issue would make it easier to model one's thoughts with less friction.

Contributor

JinShil commented Dec 24, 2016

One such limitation is efficient code reuse

In my original comment, I believe I may have misinterpreted what the author of #349 meant by "Efficient Code Reuse". I was thinking of efficiency in terms of programmer efficiency, not runtime efficiency. But, regardless of the interpretation, the issue does acknowlege a limitation, and any one of the the proposals that have attempted to address that issue would make it easier to model one's thoughts with less friction.

@mark-i-m

This comment has been minimized.

Show comment
Hide comment
@mark-i-m

mark-i-m Dec 24, 2016

Contributor

@JinShil
You raise a bunch of interesting points :D

One such limitation is efficient code reuse

I believe code reuse via inheritance mechanisms is discussed here. I think that would definitely go a long way towards intuitive and ergonomic code reuse. However, I would also argue that rust's type system (particularly generics) is an extremely powerful method of code reuse.

That is, I haven't had any need for ownership and borrowing...so it's not the borrow checker (it seems to often get the blame).

I actually have had the exact opposite experience! I also enjoy low-level programming. My first major project in rust was writing a kernel, and the primary obstacle I faced was that I was think too much like a C programmer. For example, I tried to force the compiler into allowing me to use global mutable variables sometimes or to pass pointers to everything everywhere. But this sort of programming is somewhat discouraged by the language.

I don't know about others, but I have found that my rust code is typically structured very differently from code I write in other languages (and frankly, IMHO, it tends to be more elegant). For example, I had a very preconceived notion of how to implement and interact with a linked list, and that preconception does not work in rust. (I found this book pretty useful). I was under the impression that this is actually on purpose -- the way the language was designed. I would be interested in hearing others' perspectives.

Contributor

mark-i-m commented Dec 24, 2016

@JinShil
You raise a bunch of interesting points :D

One such limitation is efficient code reuse

I believe code reuse via inheritance mechanisms is discussed here. I think that would definitely go a long way towards intuitive and ergonomic code reuse. However, I would also argue that rust's type system (particularly generics) is an extremely powerful method of code reuse.

That is, I haven't had any need for ownership and borrowing...so it's not the borrow checker (it seems to often get the blame).

I actually have had the exact opposite experience! I also enjoy low-level programming. My first major project in rust was writing a kernel, and the primary obstacle I faced was that I was think too much like a C programmer. For example, I tried to force the compiler into allowing me to use global mutable variables sometimes or to pass pointers to everything everywhere. But this sort of programming is somewhat discouraged by the language.

I don't know about others, but I have found that my rust code is typically structured very differently from code I write in other languages (and frankly, IMHO, it tends to be more elegant). For example, I had a very preconceived notion of how to implement and interact with a linked list, and that preconception does not work in rust. (I found this book pretty useful). I was under the impression that this is actually on purpose -- the way the language was designed. I would be interested in hearing others' perspectives.

@nathanaeljones

This comment has been minimized.

Show comment
Hide comment
@nathanaeljones

nathanaeljones Dec 27, 2016

With learning curve and productivity as key goals for 2017, shouldn't we prioritize making snippets, practical examples, and real (yet idiomatic) projects more discoverable, and curating them so that readers can trust they reflect current best practices?

This seems like a key strategy overlooked by the RFC, and one that (to be effective) would need to be communicated to the wider community and reflected in the ecosystem. Should this be included?

Concrete steps we could take towards this strategy.

(Please skip to Rationale if you need convincing).

  1. We could advise expanding coverage of example code to common real-world tasks

    Cons: This places a greater maintenance burden on maintainers and crate authors. The risks of under-maintained examples include popularization of sub-optimal patterns and increased fragility to breaking changes. TravisCI and the Reader are often using different crate and Rust versions.

    Mitigation: We could support authors with tooling and services. Background IDE doc testing. Something like Ruby's appraisal. PR bots for simplistic refactors (say try!(expr) -> expr?, etc.

  2. We could actively maintain lists of open-source projects whose patterns and API usage are idiomatic for the latest stable (and the latest nightly build of Rust we expect to see promoted to beta). Ideally this list should include the types of xplat applications we see as adoption drivers. We could start with 1 "high-scale server", 1 basic command-line tool, and 1 FFI sandwich (which nicely covers calling and exposing C APIs AND shows build scripts).

    Cons: Curation has a chance of being contentious. Could be burden on selected 'real' projects (Rustc version constraint & many style PRs, at best).

  3. We could expand the Playground to facilitate social snippet sharing and search, or integrate with an existing service. Git is too much - Gists are good, but aren't discoverable, and can't be ranked. Comments are important. If this already exists, let's make it more discoverable.

  4. We could make a concerted effort to update https://stackoverflow.com/questions/tagged/rust so that historical answers are useful (and add versioned tags so readers know). Filtering by view count might give us a managable number.

  5. We may want to reduce discoverability (perhaps via noindex meta tags or outright deletion) of pre-1.0 docs and deprecated crate versions, particularly those where the version number isn't highly visible to the reader. Many queries return pre-1.0 content (since those keywords were removed with 1.0).

  6. Let's send more PRs to rust-unoffical/patterns, then promote it.

My experience learning Rust

If Rust is targeting the high-scale server space, then I'm your target audience. I learned Rust in q3/q4 2016. I'm working full-time on an on-demand image processing server (AGPL + commercial exceptions) with a go-live date in February. It's replacing my previous product, which is currently deployed at several Fortune 500s in load-balanced clusters. I'm hoping to remove the soft ceiling of 80 million cached images via several kinds of distributed caches. I'm the only person at my "ramen-sustainable" company, so I've not yet taught Rust.

When I want to become productive in a new language, I read the spec, then lots of existing source code (typically from popular libraries or respected authors). Well-factored patterns for common tasks often hint at pitfalls or limitations docs might overlook.

Reading popular Rust crates left me with more questions than answers, and a suspicion that those patterns had not become well-factored enough to learn from yet.

I read the Book (several times), the Reference, the Rustonomicon (twice), and a large part of Rust by Example. Then I started reading RFCs, and they helped a lot, but my mental model still had a lot of holes. Rust was changing very fast, and too little was authoritative or even representative of the latest version.

I was 5kloc into a Rust project before (thanks to #rust) I discovered that owned types are 'static, and that I could actually use APIs with a 'static constraint without needing a literal static (keyword, not lifetime). My codebase immediately shrunk to 4kloc.

From then on I adopted a pattern of writing examples and counterexamples of every Rust feature before using it (the Playground was very handy for this). Eventually that tapered off somewhat and my productivity passed that of most other languages I use.

I've been productive with 14 languages or so (not concurrently) before starting Rust, but becoming productive with Rust required switching between trial-and-error, theoretical models of the compiler, documentation, and API source code at an unusually rapid cadence and for a long duration.

The depth of compiler knowledge I acquired was certainly not required for the task at hand, but - lacking examples - I thought it was.

The main friction I experienced was not in the docs, nor the error messages, nor IDE support, nor lang/stdlib functionality. It was that I could not effectively learn from existing source code.

Rationale

(for curating real-world projects)

Rust is a language of beautiful constraints. We are constrained with ownership, lifetimes, mutability, and in our code reuse strategies.

I love Rust for its constraints. I think they are well designed, even if numerous. I would rather maintain a codebase of Rust than one of any other language.

But to build skill through practice, one needs to create; accomplish; compile. — To explore how those constraints affect our design in an incremental and organic way.

Newcomers to Rust face a novel set of constraints on multiple design axes. Often these include data structure design, modularity, code reuse, and mutability.

I think we need to focus on helping them quickly develop a new mental model for patterns and software design that doesn't clash with Rust's constraints.

We don't know which axis they will struggle with - immutable-first could be a non-issue; or they could instinctively grasp lifetimes - or traits.

Instead of a tutorial, let's give experienced newcomers solved problems on a platter. I.e, open-source libraries and applications, curated for consistency, from which the intersection of Rust's constraints and software design can be (somewhat) understood; so that the theory we teach in the Book has a better initial frame of reference, and can stick.

Humans are good at inferring from patterns, but the crates ecosystem at large doesn't reflect much consistency in design, idioms, or patterns. Crates target wildly different minimum versions of Rust, and this alone is enough to prevent effective inference of Rust's constraints.

Let's curate some source code that we encourage newcomers to read, and soften that learning curve.

(for expanding use and scope of examples in API documentation and encouraging snippet proliferation)

As @JinShil said, it's true that there is some friction around 'incomplete' language features and APIs (take Path/PathBuf/OsString pain).

But examples go a long way to demonstrate pragmatic workarounds. They're excellent band-aids for imperfections - if we are willing to let imperfections be seen. As a library author, I am regularly guilty of avoiding the examples that highlight design flaws I've made, even if the example is for a common need. If I were to practice what I preach, I would create them, and annotate with "This API surface will be streamlined" (if true).

Examples are often the difference between hours of struggle and Ctrl+C,Ctrl+V. We may pretend those keys don't exist when we're writing production code, but they are an important part of the learning process for most developers. Experiments are important, and experimenting with changes to working code is more (directly) productive than starting from a blank file.

Let's embrace copy/paste as an essential part of incrementally learning Rust's quirks, and see how we can make that story better (cue the meme-turned-book). You want adoption, right?

With learning curve and productivity as key goals for 2017, shouldn't we prioritize making snippets, practical examples, and real (yet idiomatic) projects more discoverable, and curating them so that readers can trust they reflect current best practices?

This seems like a key strategy overlooked by the RFC, and one that (to be effective) would need to be communicated to the wider community and reflected in the ecosystem. Should this be included?

Concrete steps we could take towards this strategy.

(Please skip to Rationale if you need convincing).

  1. We could advise expanding coverage of example code to common real-world tasks

    Cons: This places a greater maintenance burden on maintainers and crate authors. The risks of under-maintained examples include popularization of sub-optimal patterns and increased fragility to breaking changes. TravisCI and the Reader are often using different crate and Rust versions.

    Mitigation: We could support authors with tooling and services. Background IDE doc testing. Something like Ruby's appraisal. PR bots for simplistic refactors (say try!(expr) -> expr?, etc.

  2. We could actively maintain lists of open-source projects whose patterns and API usage are idiomatic for the latest stable (and the latest nightly build of Rust we expect to see promoted to beta). Ideally this list should include the types of xplat applications we see as adoption drivers. We could start with 1 "high-scale server", 1 basic command-line tool, and 1 FFI sandwich (which nicely covers calling and exposing C APIs AND shows build scripts).

    Cons: Curation has a chance of being contentious. Could be burden on selected 'real' projects (Rustc version constraint & many style PRs, at best).

  3. We could expand the Playground to facilitate social snippet sharing and search, or integrate with an existing service. Git is too much - Gists are good, but aren't discoverable, and can't be ranked. Comments are important. If this already exists, let's make it more discoverable.

  4. We could make a concerted effort to update https://stackoverflow.com/questions/tagged/rust so that historical answers are useful (and add versioned tags so readers know). Filtering by view count might give us a managable number.

  5. We may want to reduce discoverability (perhaps via noindex meta tags or outright deletion) of pre-1.0 docs and deprecated crate versions, particularly those where the version number isn't highly visible to the reader. Many queries return pre-1.0 content (since those keywords were removed with 1.0).

  6. Let's send more PRs to rust-unoffical/patterns, then promote it.

My experience learning Rust

If Rust is targeting the high-scale server space, then I'm your target audience. I learned Rust in q3/q4 2016. I'm working full-time on an on-demand image processing server (AGPL + commercial exceptions) with a go-live date in February. It's replacing my previous product, which is currently deployed at several Fortune 500s in load-balanced clusters. I'm hoping to remove the soft ceiling of 80 million cached images via several kinds of distributed caches. I'm the only person at my "ramen-sustainable" company, so I've not yet taught Rust.

When I want to become productive in a new language, I read the spec, then lots of existing source code (typically from popular libraries or respected authors). Well-factored patterns for common tasks often hint at pitfalls or limitations docs might overlook.

Reading popular Rust crates left me with more questions than answers, and a suspicion that those patterns had not become well-factored enough to learn from yet.

I read the Book (several times), the Reference, the Rustonomicon (twice), and a large part of Rust by Example. Then I started reading RFCs, and they helped a lot, but my mental model still had a lot of holes. Rust was changing very fast, and too little was authoritative or even representative of the latest version.

I was 5kloc into a Rust project before (thanks to #rust) I discovered that owned types are 'static, and that I could actually use APIs with a 'static constraint without needing a literal static (keyword, not lifetime). My codebase immediately shrunk to 4kloc.

From then on I adopted a pattern of writing examples and counterexamples of every Rust feature before using it (the Playground was very handy for this). Eventually that tapered off somewhat and my productivity passed that of most other languages I use.

I've been productive with 14 languages or so (not concurrently) before starting Rust, but becoming productive with Rust required switching between trial-and-error, theoretical models of the compiler, documentation, and API source code at an unusually rapid cadence and for a long duration.

The depth of compiler knowledge I acquired was certainly not required for the task at hand, but - lacking examples - I thought it was.

The main friction I experienced was not in the docs, nor the error messages, nor IDE support, nor lang/stdlib functionality. It was that I could not effectively learn from existing source code.

Rationale

(for curating real-world projects)

Rust is a language of beautiful constraints. We are constrained with ownership, lifetimes, mutability, and in our code reuse strategies.

I love Rust for its constraints. I think they are well designed, even if numerous. I would rather maintain a codebase of Rust than one of any other language.

But to build skill through practice, one needs to create; accomplish; compile. — To explore how those constraints affect our design in an incremental and organic way.

Newcomers to Rust face a novel set of constraints on multiple design axes. Often these include data structure design, modularity, code reuse, and mutability.

I think we need to focus on helping them quickly develop a new mental model for patterns and software design that doesn't clash with Rust's constraints.

We don't know which axis they will struggle with - immutable-first could be a non-issue; or they could instinctively grasp lifetimes - or traits.

Instead of a tutorial, let's give experienced newcomers solved problems on a platter. I.e, open-source libraries and applications, curated for consistency, from which the intersection of Rust's constraints and software design can be (somewhat) understood; so that the theory we teach in the Book has a better initial frame of reference, and can stick.

Humans are good at inferring from patterns, but the crates ecosystem at large doesn't reflect much consistency in design, idioms, or patterns. Crates target wildly different minimum versions of Rust, and this alone is enough to prevent effective inference of Rust's constraints.

Let's curate some source code that we encourage newcomers to read, and soften that learning curve.

(for expanding use and scope of examples in API documentation and encouraging snippet proliferation)

As @JinShil said, it's true that there is some friction around 'incomplete' language features and APIs (take Path/PathBuf/OsString pain).

But examples go a long way to demonstrate pragmatic workarounds. They're excellent band-aids for imperfections - if we are willing to let imperfections be seen. As a library author, I am regularly guilty of avoiding the examples that highlight design flaws I've made, even if the example is for a common need. If I were to practice what I preach, I would create them, and annotate with "This API surface will be streamlined" (if true).

Examples are often the difference between hours of struggle and Ctrl+C,Ctrl+V. We may pretend those keys don't exist when we're writing production code, but they are an important part of the learning process for most developers. Experiments are important, and experimenting with changes to working code is more (directly) productive than starting from a blank file.

Let's embrace copy/paste as an essential part of incrementally learning Rust's quirks, and see how we can make that story better (cue the meme-turned-book). You want adoption, right?

@mark-i-m

This comment has been minimized.

Show comment
Hide comment
@mark-i-m

mark-i-m Dec 28, 2016

Contributor

Hmm... @nathanaeljones You make a very insightful point!

Come to think of it, I did spend hours reading the source std implementations of Vec and LinkedList to get a feel for idiomatic rust. Most programmers have a pretty good understanding of these data structures from a theory perspective, I think, so they might make good examples for a guided tour of design. For example, @Gankro's Learning Rust With Entirely Too Many Linked Lists is one of my favorite rust books.

I would however like to add extra emphasis on "Rustic" design patterns; that is, I don't think there are currently many resources for learning them beyond simply reading std source code. For example, there are a bunch of points on which my intuition was developed vaguely over time (e.g. Deref vs From, the different types of iterators, the Drain pattern). These sorts of intuitions should be addressed systematically in some sort of official rust tutorial.

Contributor

mark-i-m commented Dec 28, 2016

Hmm... @nathanaeljones You make a very insightful point!

Come to think of it, I did spend hours reading the source std implementations of Vec and LinkedList to get a feel for idiomatic rust. Most programmers have a pretty good understanding of these data structures from a theory perspective, I think, so they might make good examples for a guided tour of design. For example, @Gankro's Learning Rust With Entirely Too Many Linked Lists is one of my favorite rust books.

I would however like to add extra emphasis on "Rustic" design patterns; that is, I don't think there are currently many resources for learning them beyond simply reading std source code. For example, there are a bunch of points on which my intuition was developed vaguely over time (e.g. Deref vs From, the different types of iterators, the Drain pattern). These sorts of intuitions should be addressed systematically in some sort of official rust tutorial.

@mark-i-m

This comment has been minimized.

Show comment
Hide comment
@mark-i-m

mark-i-m Dec 28, 2016

Contributor

Also, raising awareness for new patterns that are barely stabilized is another gap. Every time I refer to the standard documentation, I find out about another trait that I never new existed. For example, last week I discovered ToString, and I am still not clear about when to use ToString and Display... which brings me a more general point: there needs to be a good reference of all std traits and what they mean, especially those that are intended to be idiomatic or have special compiler meaning.

Contributor

mark-i-m commented Dec 28, 2016

Also, raising awareness for new patterns that are barely stabilized is another gap. Every time I refer to the standard documentation, I find out about another trait that I never new existed. For example, last week I discovered ToString, and I am still not clear about when to use ToString and Display... which brings me a more general point: there needs to be a good reference of all std traits and what they mean, especially those that are intended to be idiomatic or have special compiler meaning.

@chriskrycho

This comment has been minimized.

Show comment
Hide comment
@chriskrycho

chriskrycho Dec 28, 2016

Contributor

@mark-i-m note that the recently merged RFC #1636 was aimed to address precisely the problem you bring up about new parts of the standard library and the language (independent of the specific examples cited).

There's a lot of work to be done in 2017 (to which I specifically intend to address basically any and all Rust contributions I make this coming year!) to get us caught up on documenting a lot of things; but at the least, every new feature merged going forward will be documented. That should help substantially with this (very real) problem. If you want a place to contribute, I know the docs team would love help documenting everything that has been merged but not documented since 1.0, and the reference in particular needs a lot of love!

Contributor

chriskrycho commented Dec 28, 2016

@mark-i-m note that the recently merged RFC #1636 was aimed to address precisely the problem you bring up about new parts of the standard library and the language (independent of the specific examples cited).

There's a lot of work to be done in 2017 (to which I specifically intend to address basically any and all Rust contributions I make this coming year!) to get us caught up on documenting a lot of things; but at the least, every new feature merged going forward will be documented. That should help substantially with this (very real) problem. If you want a place to contribute, I know the docs team would love help documenting everything that has been merged but not documented since 1.0, and the reference in particular needs a lot of love!

@sfackler

This comment has been minimized.

Show comment
Hide comment
@sfackler

sfackler Dec 28, 2016

Member

ToString has existed since 1.0.0. Its docs seem fairly clear about how it relates to Display and how it is intended to be used - is there something that still seems missing? https://doc.rust-lang.org/std/string/trait.ToString.html

Member

sfackler commented Dec 28, 2016

ToString has existed since 1.0.0. Its docs seem fairly clear about how it relates to Display and how it is intended to be used - is there something that still seems missing? https://doc.rust-lang.org/std/string/trait.ToString.html

@mark-i-m

This comment has been minimized.

Show comment
Hide comment
@mark-i-m

mark-i-m Dec 28, 2016

Contributor

@chriskrycho Thanks! I would be glad to help when I can 😄

@sfackler Sorry, you are right. The docs clearly say to implement Display and get ToString for free. I guess my point is that this information about traits should be gathered to one place, rather than its current distributed form throughout the std docs. I haven't yet read #1636 or other RFCs to see if this is already a proposed feature, though...

Contributor

mark-i-m commented Dec 28, 2016

@chriskrycho Thanks! I would be glad to help when I can 😄

@sfackler Sorry, you are right. The docs clearly say to implement Display and get ToString for free. I guess my point is that this information about traits should be gathered to one place, rather than its current distributed form throughout the std docs. I haven't yet read #1636 or other RFCs to see if this is already a proposed feature, though...

@withoutboats

This comment has been minimized.

Show comment
Hide comment
@withoutboats

withoutboats Dec 28, 2016

Contributor

I think figuring out the design patterns of Rust is a really important effort, but I really don't know how it could be an organized task of the Rust project. It seems like it needs to arise organically from user experiences. Perhaps there's a better way to open a forum for discussing patterns than what we have now.

Contributor

withoutboats commented Dec 28, 2016

I think figuring out the design patterns of Rust is a really important effort, but I really don't know how it could be an organized task of the Rust project. It seems like it needs to arise organically from user experiences. Perhaps there's a better way to open a forum for discussing patterns than what we have now.

@softprops

This comment has been minimized.

Show comment
Hide comment
@softprops

softprops Dec 28, 2016

@withoutboats https://github.com/rust-unofficial/patterns exists independently. I agree patterns should generally emerge from user experience/trail and err.

@withoutboats https://github.com/rust-unofficial/patterns exists independently. I agree patterns should generally emerge from user experience/trail and err.

@softprops

This comment has been minimized.

Show comment
Hide comment
@softprops

softprops Dec 28, 2016

I wanted to echo others excitement on this outline. I'm more excited than ever about rust.

I did want to make a comment on what the feature I think would help all others including making an argument for adopting rust in more organizations: fast compiles. I know it was briefly mentioned in the goals but I think it should be on of the top priorities given the over arching theme.

I come at this from an angle as an early adopter of scala. Scalac has notoriously always been slow. Though it had a vastly superior feature set compared to java. Using java libraries from scala has basically always worked (though the inverse is sometimes gross). The hold major hold back for many companies already using java, wasn't that scala didnt have useful features, it's that what productivity you'd gain from its langauge featured you pay dearly on your compiler cycles. This greatly reduced the chances of adoption of Java shops. Sbt (scalasource cargo) eventually made this tolerable but Scalac accumulated worse performance over time because there was a "work around". You can now incrementally pay for slow compile time tax. It took scala a long time to get where it is today but through observation I believe it could have gotten there more quickly of compile times were not so horrendous compared to javas.

Fast compile cycles pay for themselves ( literally in developer salary time ) which companies like. Fast compile cycles are really nice for learning a language as well has getting useful work down when you are comfortable with the language which developers like. Shorter feedback cycles are a langauge feature you can sell without much maketing. A faster compiler turn around will improve the learning experience as well as the library development experience.

In short, investing in out of the box fast compile cycles has a ripple effect on all of the other targeted areas of focus in this rfc. Please don't let it sink to the bottom in importance. It's going to be a tough sell for my scala team when I demo them another scalac!

I wanted to echo others excitement on this outline. I'm more excited than ever about rust.

I did want to make a comment on what the feature I think would help all others including making an argument for adopting rust in more organizations: fast compiles. I know it was briefly mentioned in the goals but I think it should be on of the top priorities given the over arching theme.

I come at this from an angle as an early adopter of scala. Scalac has notoriously always been slow. Though it had a vastly superior feature set compared to java. Using java libraries from scala has basically always worked (though the inverse is sometimes gross). The hold major hold back for many companies already using java, wasn't that scala didnt have useful features, it's that what productivity you'd gain from its langauge featured you pay dearly on your compiler cycles. This greatly reduced the chances of adoption of Java shops. Sbt (scalasource cargo) eventually made this tolerable but Scalac accumulated worse performance over time because there was a "work around". You can now incrementally pay for slow compile time tax. It took scala a long time to get where it is today but through observation I believe it could have gotten there more quickly of compile times were not so horrendous compared to javas.

Fast compile cycles pay for themselves ( literally in developer salary time ) which companies like. Fast compile cycles are really nice for learning a language as well has getting useful work down when you are comfortable with the language which developers like. Shorter feedback cycles are a langauge feature you can sell without much maketing. A faster compiler turn around will improve the learning experience as well as the library development experience.

In short, investing in out of the box fast compile cycles has a ripple effect on all of the other targeted areas of focus in this rfc. Please don't let it sink to the bottom in importance. It's going to be a tough sell for my scala team when I demo them another scalac!

@nathanaeljones

This comment has been minimized.

Show comment
Hide comment
@nathanaeljones

nathanaeljones Dec 28, 2016

@softprops Certainly. This article on profiling the compiler is good. Ideally, we should make a docker container for profiling Rust nightlies, so that developers can determine compiler hot-spots in minutes instead of hours. I'd like to collaborate on this.

I think figuring out the design patterns of Rust is a really important effort, but I really don't know how it could be an organized task of the Rust project. It seems like it needs to arise organically from user experiences. Perhaps there's a better way to open a forum for discussing patterns than what we have now.

@withoutboats I didn't mean to imply it should be an officially organized task.

Paragraph 2 of the RFC already implies involvement and change in the larger ecosystem - specifically crates for essential tasks and writing robust servers (goals I applaud - I think the RFC is excellent).

My understanding is that the roadmap has the potential to influence contributors and ecosystem development outside of the core project.

If there is consensus that 2017 is a good point in Rust's evolution for us to invest in more heavily in example code and take on that maintenance burden, then it would seem appropriate to encourage it in the RFC.

I don't want to imply that we should be prescriptive of code style or patterns, but rather descriptive of present usage.

  1. Prominently suggest curated examples of real-world Rust usage and code structure. I.e, If you'd like to see what production Rust source code looks like today, take a look at this list of projects which target Rust [version]. Rust is updated every six weeks and typically enables more elegant code with each release, so it can be difficult to infer current patterns of usage from the ecosystem at large. Ideally, this source code would be annotated, copy/paste friendly, readable, low complexity, yet not toy code. There's a tendency to select toy examples that are naturally low-friction in Rust, and that is unhelpful. Throw a few mutating graphs and trees in there. I found stdlib's module structure hard to follow initially, and although I still benefited from reading it, many of the APIs it uses are not externally available.

  2. Help more newcomers find existing unofficial - but trustworthy - resources. Most newcomers lack the tools to distinguish between outdated and up-to-date content - publish dates are insufficient. I gave up on community tutorials and resources very early on. If even 40% of unofficial examples no longer compile, then they're slowing down the construction of the mental model. There's a high penalty for introducing incorrect information during the learning process, and using Google to learn Rust is currently a terrible experience.

  3. Make "here's one way to do it" examples more common and more discoverable - in ::std, in essential crates, and in other forums.

  4. Encourage crate authors to invest in newcomer-friendly examples for their crates.

If this is not in-scope for the RFC, then perhaps there is a better forum?

[edit - pasting a newline somehow posted this too early. Sorry for the garbage notification]

nathanaeljones commented Dec 28, 2016

@softprops Certainly. This article on profiling the compiler is good. Ideally, we should make a docker container for profiling Rust nightlies, so that developers can determine compiler hot-spots in minutes instead of hours. I'd like to collaborate on this.

I think figuring out the design patterns of Rust is a really important effort, but I really don't know how it could be an organized task of the Rust project. It seems like it needs to arise organically from user experiences. Perhaps there's a better way to open a forum for discussing patterns than what we have now.

@withoutboats I didn't mean to imply it should be an officially organized task.

Paragraph 2 of the RFC already implies involvement and change in the larger ecosystem - specifically crates for essential tasks and writing robust servers (goals I applaud - I think the RFC is excellent).

My understanding is that the roadmap has the potential to influence contributors and ecosystem development outside of the core project.

If there is consensus that 2017 is a good point in Rust's evolution for us to invest in more heavily in example code and take on that maintenance burden, then it would seem appropriate to encourage it in the RFC.

I don't want to imply that we should be prescriptive of code style or patterns, but rather descriptive of present usage.

  1. Prominently suggest curated examples of real-world Rust usage and code structure. I.e, If you'd like to see what production Rust source code looks like today, take a look at this list of projects which target Rust [version]. Rust is updated every six weeks and typically enables more elegant code with each release, so it can be difficult to infer current patterns of usage from the ecosystem at large. Ideally, this source code would be annotated, copy/paste friendly, readable, low complexity, yet not toy code. There's a tendency to select toy examples that are naturally low-friction in Rust, and that is unhelpful. Throw a few mutating graphs and trees in there. I found stdlib's module structure hard to follow initially, and although I still benefited from reading it, many of the APIs it uses are not externally available.

  2. Help more newcomers find existing unofficial - but trustworthy - resources. Most newcomers lack the tools to distinguish between outdated and up-to-date content - publish dates are insufficient. I gave up on community tutorials and resources very early on. If even 40% of unofficial examples no longer compile, then they're slowing down the construction of the mental model. There's a high penalty for introducing incorrect information during the learning process, and using Google to learn Rust is currently a terrible experience.

  3. Make "here's one way to do it" examples more common and more discoverable - in ::std, in essential crates, and in other forums.

  4. Encourage crate authors to invest in newcomer-friendly examples for their crates.

If this is not in-scope for the RFC, then perhaps there is a better forum?

[edit - pasting a newline somehow posted this too early. Sorry for the garbage notification]

@softprops

This comment has been minimized.

Show comment
Hide comment
@softprops

softprops Dec 28, 2016

Most newcomers lack the tools to distinguish between outdated and up-to-date content - publish dates are insufficient.

There was a sales pitch a while back (I can't find a link) for people blogging about rust to make mention of the rust/crate version code examples are based on. I don't think that's a rust specific problem but we should bring that practice back!

Most newcomers lack the tools to distinguish between outdated and up-to-date content - publish dates are insufficient.

There was a sales pitch a while back (I can't find a link) for people blogging about rust to make mention of the rust/crate version code examples are based on. I don't think that's a rust specific problem but we should bring that practice back!

@steveklabnik

This comment has been minimized.

Show comment
Hide comment
Member

steveklabnik commented Dec 28, 2016

@mark-i-m

This comment has been minimized.

Show comment
Hide comment
@mark-i-m

mark-i-m Jan 1, 2017

Contributor

Also related to learning/documenting rust, there is rust-lang/rfcs#1828, which is another excellent pull request.

Contributor

mark-i-m commented Jan 1, 2017

Also related to learning/documenting rust, there is rust-lang/rfcs#1828, which is another excellent pull request.

@aturon

This comment has been minimized.

Show comment
Hide comment
@aturon

aturon Jan 5, 2017

Member

@nathanaeljones

Thank you for your insightful and very thought-out comment. I completely agree that gathering patterns and examples is one of the most important steps we can take for improving the learning curve this year, and I will update the RFC text to call out this approach specifically. As a general note, the commitment in this roadmap is primarily to the top-level items setting out our overall strategic goals; the tactics we use to achieve those goals are something we will be debating and shifting over the course of the year.

@softprops

I did want to make a comment on what the feature I think would help all others including making an argument for adopting rust in more organizations: fast compiles. I know it was briefly mentioned in the goals but I think it should be on of the top priorities given the over arching theme.

This is definitely a top priority in the roadmap ("Rust should have a pleasant edit-compile-debug cycle"). Incremental compilation continues to make good progress, and you can expect an update on its status soon.

Member

aturon commented Jan 5, 2017

@nathanaeljones

Thank you for your insightful and very thought-out comment. I completely agree that gathering patterns and examples is one of the most important steps we can take for improving the learning curve this year, and I will update the RFC text to call out this approach specifically. As a general note, the commitment in this roadmap is primarily to the top-level items setting out our overall strategic goals; the tactics we use to achieve those goals are something we will be debating and shifting over the course of the year.

@softprops

I did want to make a comment on what the feature I think would help all others including making an argument for adopting rust in more organizations: fast compiles. I know it was briefly mentioned in the goals but I think it should be on of the top priorities given the over arching theme.

This is definitely a top priority in the roadmap ("Rust should have a pleasant edit-compile-debug cycle"). Incremental compilation continues to make good progress, and you can expect an update on its status soon.

@aturon aturon merged commit c59aa27 into rust-lang:master Jan 5, 2017

@aturon

This comment has been minimized.

Show comment
Hide comment
@aturon

aturon Jan 5, 2017

Member

The FCP period has elapsed, and there continues to be broad consensus on the direction laid out in this RFC. There's going to be a lot to debate about the particular tactics we'll use to achieve the goals we've set out, but we now have a basic vision for 2017. I'll be working to turn the roadmap into a dynamic form that we can use to track progress and tactics soon.

RFC merged. Let's do this!!

Member

aturon commented Jan 5, 2017

The FCP period has elapsed, and there continues to be broad consensus on the direction laid out in this RFC. There's going to be a lot to debate about the particular tactics we'll use to achieve the goals we've set out, but we now have a basic vision for 2017. I'll be working to turn the roadmap into a dynamic form that we can use to track progress and tactics soon.

RFC merged. Let's do this!!

@nathanaeljones

This comment has been minimized.

Show comment
Hide comment
@nathanaeljones

nathanaeljones Jan 5, 2017

Yeah!

Where is the best place to kick off discussions for the following topics?

  • Creating cargo profile-compiler (perhaps we just invoke a turnkey Docker container). I haven't witnessed a strong correlation between kloc and compile times, so perhaps more data can help?
  • Improving the "Google [rust keyword]" learning experience. There's a lot of low-hanging fruit in mutable storage locations. I have SO edit privileges and would like to coordinate with anyone else interested in this.
  • Tracking key blockers - and workarounds - for robust servers. (OOM handling, TLS, etc).
  • Streamlining FFI/bindgen and achieving good example coverage of common patterns.
  • Streamlining and documenting build (and key package management!) integration for FFI use.

Yeah!

Where is the best place to kick off discussions for the following topics?

  • Creating cargo profile-compiler (perhaps we just invoke a turnkey Docker container). I haven't witnessed a strong correlation between kloc and compile times, so perhaps more data can help?
  • Improving the "Google [rust keyword]" learning experience. There's a lot of low-hanging fruit in mutable storage locations. I have SO edit privileges and would like to coordinate with anyone else interested in this.
  • Tracking key blockers - and workarounds - for robust servers. (OOM handling, TLS, etc).
  • Streamlining FFI/bindgen and achieving good example coverage of common patterns.
  • Streamlining and documenting build (and key package management!) integration for FFI use.
@steveklabnik

This comment has been minimized.

Show comment
Hide comment
@steveklabnik

steveklabnik Jan 5, 2017

Member

Where is the best place to kick off discussions for the following topics?

I would argue individual issues on this repo.

Member

steveklabnik commented Jan 5, 2017

Where is the best place to kick off discussions for the following topics?

I would argue individual issues on this repo.

@aturon

This comment has been minimized.

Show comment
Hide comment
@aturon

aturon Jan 5, 2017

Member

Where is the best place to kick off discussions for the following topics?

I'll be setting up a separate repo for managing the roadmap and discussions around it -- I'll post a link as soon as it's ready.

Member

aturon commented Jan 5, 2017

Where is the best place to kick off discussions for the following topics?

I'll be setting up a separate repo for managing the roadmap and discussions around it -- I'll post a link as soon as it's ready.

@luser

This comment has been minimized.

Show comment
Hide comment
@luser

luser Jan 6, 2017

Streamlining and documenting build (and key package management!) integration for FFI use.

FYI I put some notes I had collected on this topic into a GitHub repo recently:
https://github.com/luser/integrating-rust-into-existing-projects

I'd be interested in expanding on that in whatever venue is best. I've spent a lot of time driving the Rust integration into the Firefox build, so I have some related experience.

luser commented Jan 6, 2017

Streamlining and documenting build (and key package management!) integration for FFI use.

FYI I put some notes I had collected on this topic into a GitHub repo recently:
https://github.com/luser/integrating-rust-into-existing-projects

I'd be interested in expanding on that in whatever venue is best. I've spent a lot of time driving the Rust integration into the Firefox build, so I have some related experience.

@dumindu

This comment has been minimized.

Show comment
Hide comment

@aturon aturon referenced this pull request Jan 7, 2017

Closed

Types for enum variants #1450

@nikomatsakis

This comment has been minimized.

Show comment
Hide comment
@nikomatsakis

nikomatsakis Jan 7, 2017

Contributor

@rfcbot reviewed

Contributor

nikomatsakis commented Jan 7, 2017

@rfcbot reviewed

@burdges burdges referenced this pull request in dalek-cryptography/curve25519-dalek Jan 7, 2017

Closed

Erasing secrets from memory (zero on drop) #11

@kindlychung

This comment has been minimized.

Show comment
Hide comment
@kindlychung

kindlychung Jan 10, 2017

Lifetimes is probably the most difficult part of rust. It would be wonderful if the IDE can do some kind of visualization of it.

Lifetimes is probably the most difficult part of rust. It would be wonderful if the IDE can do some kind of visualization of it.

@jonathandturner

This comment has been minimized.

Show comment
Hide comment
@jonathandturner

jonathandturner Jan 10, 2017

Contributor

@kindlychung - there's been some work on this: https://internals.rust-lang.org/t/borrow-visualizer-for-the-rust-language-service/4187

Definitely something we're interested in on the IDE side 😄

Contributor

jonathandturner commented Jan 10, 2017

@kindlychung - there's been some work on this: https://internals.rust-lang.org/t/borrow-visualizer-for-the-rust-language-service/4187

Definitely something we're interested in on the IDE side 😄

@aturon aturon referenced this pull request Jan 23, 2017

Closed

Add tuple cons cell syntax #1582

@aturon aturon referenced this pull request in rust-lang/rust-roadmap-2017 Jan 31, 2017

Open

Rust should have a lower learning curve #3

@aturon aturon referenced this pull request Feb 12, 2017

Closed

Pattern synonyms #1895

@chriskrycho chriskrycho referenced this pull request in rust-lang-nursery/reference Mar 29, 2017

Closed

Document all features #9

18 of 48 tasks complete
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment