Rendered

cc @rust-lang/core

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!

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.

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

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 what we need is stabilization of Macros 1.1 which seems in reach at the beginning of 2017.

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.

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.

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

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. ;)

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.

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!

@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.

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.

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.

@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!

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.

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

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.

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.

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.

@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.

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

@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!

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

@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...

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 https://github.com/rust-unofficial/patterns exists independently. I agree patterns should generally emerge from user experience/trail and err.

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!

@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]

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!

@softprops that was http://words.steveklabnik.com/community-versions-for-rust and it went absolutely nowhere.

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

@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.

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!!

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.

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

I would argue individual issues on this repo.

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.

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.

Please check the content on https://www.reddit.com/r/rust/comments/5m88iu/rfc_for_rusts_roadmap_in_2017_was_just_merged/dc2gq54/ as well. Thanks

@rfcbot reviewed

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

@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 😄