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)
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.)
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.
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.
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.)
I think (some will correct me if I'm wrong) the general term for this is flow analysis, and TypeScript does it under the hood so it can refine/narrow types. Not with visualisations though
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.
I like it. It's compensation for not coding with a style optimized for human reading but since not all the base codes you have would be even close to be described like that, then this is a good useful tool.
23 comments
[ 0.21 ms ] story [ 49.1 ms ] threadwould love this for typescript
Couldnt we re-use data from the compiler to help with that ?
I love this plugin btw.
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.
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.)
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/...
Seems like a very specific feature to have plugin for.
https://microsoft.github.io/language-server-protocol/specifi...