[HN Gopher] Flowistry: An IDE plugin for Rust that focuses on re...
       ___________________________________________________________________
        
       Flowistry: An IDE plugin for Rust that focuses on relevant code
        
       Author : Bogdanp
       Score  : 128 points
       Date   : 2025-10-18 14:33 UTC (8 hours ago)
        
 (HTM) web link (github.com)
 (TXT) w3m dump (github.com)
        
       | habitue wrote:
       | These kinds of tools should be standard in understanding code
        
       | fHr wrote:
       | Nice plugin, will try this out tomorrow!
        
       | marcelr wrote:
       | this looks fantastic
       | 
       | would love this for typescript
        
       | brundolf wrote:
       | Super cool! I assume it plays nice with rust-analyzer?
        
       | jryio wrote:
       | The author has a nice talk diving deep into the routines research
       | and the plugin in a Rust East Coast talk here:
       | https://youtu.be/aYmuMlzvjvc
        
       | user- wrote:
       | Anyone have suggestions for similar tooling for other languages?
        
         | cyberax wrote:
         | JetBrains IDEs :)
        
       | ttoinou wrote:
       | I've always dreamed about this + also how the data flows from the
       | outside (who calls this function)
       | 
       | Couldnt we re-use data from the compiler to help with that ?
        
         | tcfhgj wrote:
         | as far as I understood from the corresponding talk, it uses
         | data from the compiler
        
       | Groxx wrote:
       | looks fantastic, and rust is probably a great language for this
       | since ownership restricts effects - even if you add it to python,
       | you can't _really_ trust it, because at runtime you can just run
       | up a call stack and modify memory at any time. (though I would
       | still definitely want it, as it 's usually going to be correct)
        
         | wcrichton wrote:
         | (Author here) That's exactly why I built this for Rust, and why
         | it's difficult to replicate in any other language.
        
           | epolanski wrote:
           | Hey author, interested about your bio and work.
           | 
           | Any way to follow what you up to?
        
             | wcrichton wrote:
             | My personal site (https://willcrichton.net/), lab site
             | (https://cel.cs.brown.edu/), and Mastodon page
             | (https://mastodon.social/@tonofcrates) are all good ways to
             | follow me!
        
       | yoyohello13 wrote:
       | Looks cool, but why say 'IDE' instead of just VSCode plugin?
        
         | Neywiny wrote:
         | It says IDE plug-in
        
           | TehCorwiz wrote:
           | Yes, that's the question. It doesn't appear to support any
           | IDEs except VSCode so why use the general term and give an
           | incorrect impression?
        
             | dmix wrote:
             | Probably because it's based on an idea published in a
             | paper, it's not limited to this particular repo
        
         | PufPufPuf wrote:
         | Probably because "Visual Studio Code" is a Microsoft trademark,
         | but the plugin works with all the IDEs based on the open source
         | base (VSCodium, Cursor, etc.)
        
       | ivape wrote:
       | This is an interesting way to do micro context engineering. This
       | is basically pulling in the minimum relevant code for your
       | current concern, and then you can just sprinkle on some
       | instructions and send off your prompt. Might work reasonably well
       | for very small local models, or just generally cheap inferencing
       | on the server.
       | 
       | I love this plugin btw.
        
       | sheepscreek wrote:
       | Just the other day I was experimenting with moving over a big
       | chunk of a C# codebase (heavy on allocations) to Rust, and the
       | Rust code quickly became very cluttered. C# reads better but is a
       | bit more verbose. Rust is more compact and sometimes very dense.
       | 
       | To make it easier to scan through long files, I wished for an
       | extension that could make the traits appear a few shades darker.
       | This might be even better. Going to give it a try tonight.
        
       | btown wrote:
       | Does this exist for larger/more informal dependency relationships
       | within a function body in other programming languages?
       | 
       | For instance, if I highlight a parameter or variable foo, can I
       | see not only all usages of foo itself, but usages of any variable
       | that was derived from foo?
       | 
       | While borrow usage makes this foolproof, this type of
       | visualization would be tremendously useful for even other types
       | of code.
       | 
       | (As for Flowistry, I can see this being vital for anyone trying
       | to maintain e.g.
       | https://github.com/servo/servo/blob/main/components/layout/f... -
       | perhaps the most daunting single file in a modern codebase I've
       | ever seen! And yes, that's a 400-line function.)
        
       | Animats wrote:
       | Actual paper: [1]
       | 
       | This could be useful. I've been plugging away, on and off, on the
       | concept of statically checked back-references for Rust. This is
       | one of the biggest complaints that C/C++ people have about Rust -
       | if A points to B, it's really hard to have a pointer from B to A.
       | This leads to unsafe workarounds.
       | 
       | You can do it safely with Rc, RefCell, Weak, borrow(),
       | borrow_mut(), upgrade(), and downgrade(). It's verbose, adds run-
       | time overhead, and there's the potential of panicking at run time
       | on a double borrow. But the expressive power is there. This is
       | work in progress, and I have some notes here.[2]
       | 
       | The thing that's hard to check statically that borrows are
       | disjoint as to scope. Borrows have lifetime scopes. If those
       | lifetime scopes do not overlap, the borrows do not clash.
       | Checking this across function calls is hard. (Checking across
       | generic function calls is worse.) The Flowistry approach might
       | help. The note that "Flowistry does not completely handle
       | interior mutability" is a concern, because we're analyzing things
       | that use RefCell.
       | 
       | The practical problem is to come up with a set of restrictions
       | that are 1) sound, 2) checkable at compile time without too much
       | compute effort, 3) allow programmers to do most of the legit
       | things people want to do with back pointers, such as have a
       | reference to the parent node in a tree, and 4) lead to usable
       | diagnostic messages for problems.
       | 
       | [1] https://arxiv.org/abs/2111.13662
       | 
       | [2] https://github.com/John-
       | Nagle/technotes/blob/main/docs/rust/...
        
       | ivanjermakov wrote:
       | Why not contribute to rust-analyzer's documentHighlight LSP
       | method? It behaves very similar to what GIFs are showing.
       | 
       | Seems like a very specific feature to have plugin for.
       | 
       | https://microsoft.github.io/language-server-protocol/specifi...
        
         | pveierland wrote:
         | Explained in README:
         | https://github.com/willcrichton/flowistry#why-isnt-flowistry...
        
       ___________________________________________________________________
       (page generated 2025-10-18 23:00 UTC)