Hacker News Reader

Comment by tschumacher | Hacker News Reader

My coworker recently showed me this plugin [1] that fades out all Rust code that is unrelated to the variable under the cursor. Think of it as a more powerful version of the "click to highlight all appearances" you can do in most IDEs but it actually does information flow analysis on the code.

[1]: https://github.com/willcrichton/flowistry

View on HN

Will Chrichton gave a talk at Jane Street about his research that led to the development of this plugin. It’s a pretty good talk:

https://www.janestreet.com/tech-talks/rust-for-everyone/

As I recall, he also explains how Rust is uniquely positioned to enable this kind of syntax formatting.

Need this for every language …

It can't. It uses ownership types in Rust to do the analysis. It can be fooled by Rust's interior mutability. Other languages don't have a type system that enables this.

If Eclipse's archaic(!) variable renaming feature for C++ can distinguish between related and unrelated variables which have the same name, you can implement this thing in almost any language.

Eclipse CDT has a real-time static analyzer for the code you're working on though. It's not as naive as it looks from a distance.

Consider this simple C code:

    void inc(int* a, int* b) {
      *a += 1; *b += 2;
    }

Are you adding one to an integer and adding two to another integer, or are you adding three to a single integer?

In other words are the two pointers actually pointing to the same variable? There's no way to know. When you select one pointer, should the other also be highlighted?

But in Rust you cannot have two mutable references to a single variable so the above cannot happen.

Variable renaming is a much much simpler task than this. Of course it is archaic and has existed for a long time.

> In other words are the two pointers actually pointing to the same variable?

This statement is incorrect. You can't have pointers to a variable. You can have pointers to a memory address, and most people would be fine with a tool that is correct up to the level of being unable to differentiate that.

This is a disingenuous redefinition of what the GP is looking for in order to shill Rust.

honestly I'd be ok with a being treated as different than b in this colorized use case. sure, maybe it'd be "bug inducing" or be a subconcious push toward human brains to forget they produced two aliases etc but I think what you're proposing with the c colorizing is impractical and yes I get it, "the tools caused the crash that brought down civilization" but c'mon, if you're still using c, folks have already talked you out of safety nets lol

From thinking about it and merely looking at the gif example... I think you could actually get there via language server alone - at least mostly?

It just highlights parts that interface with a symbol, right? And that's information the language server is supposed to expose.

You'd "just" have to make a x+1 mapping to highlight anything that's touching the symbol

To be clear, I'm just speculating here and not speaking with authority on the topic. It's possible I'm missing something which makes this approach infeasible in practice

You merely explain why you can't copy the implementation strategy.

But that says nothing about providing the same value to the user in other languages via different means.

You merely assume an alternative implementation strategy exists and that it provides the same value to the user.

But that says nothing about whether it actually can exist.

> You merely assume an alternative implementation strategy exists [...]

Huh, where am I making that assumption?

> But that says nothing about whether it actually can exist.

Yes, I expressed no opinion on that.

> Huh, where am I making that assumption?

You didn't, and you didn't express any opinion on whether or not it can exist, either - GP is arguing dishonestly to shill Rust.

Which is really a shame. Rust is a nice enough language that it doesn't need dishonest shilling.

It's not exactly rare to avoid mutability/use a functional style in application code, and even in mutable code, IME aliasing is rare. In some ways Rust's rules are kind of a formalization of what was already good practice in C. Variable scope is also usually small. Turns out things that are easier for the computer to analyze are also easier for people to analyze, so it's long been good practice to structure your code in easy to analyze ways.

LLMs are getting better and cheaper. It's ridiculous overkill for the task, but they could potentially do something like this and more sophisticated versions highlighting related code on other dimensions.

Programming languages are built upon mathematically defined and deterministic syntax. You can analyze them with formulae, take concrete and deterministic actions on the syntax tree.

There's no need to unleash a fuzzy and inefficient network on something designed to be deterministic and parseable.

Yes but he was saying other languages weren't in this aspect.

And I said the same as you but that also it could highlight on more abstract things that aren't in the parse tree, I meant things like feature-relatedness etc. These variables are only used for intermediate logging stuff and get greyed out etc.

It's not so much syntax as semantics here. And programming languages are often described and implemented with rather vaguer ideas than fully formally specified semantics. (Even Haskell doesn't have fully formalised semantics.)

Shouldn't be too difficult for C# with Roslyn

Visual Studio is irritatingly doing the opposite. If it detects unused methods/variables it will make them darker (which in general is quite useful), but it also does so when you're still busy creating new methods and just haven't linked them to anything yet.

Oh wow, this is actually useful

And, so, does syntax highlighting interfere in that? No.

The information channel is shareable.

That’s basically the first paragraph of the article.

I don't see that; it doesn't acknowledge that the channel can be multiplexed and thus isn't wasted by dedication to syntax.

"Color distinguishes things. And we just use it to distinguish syntax. Nothing wrong with distinguishing syntax. It's the "just" that bothers me. Highlighting syntax is not always the most important thing to us. The information we want from code depends on what we're trying to do."

It then goes on to talk about rainbow parentheses, which is information multiplexed on the color channel with the syntax highlighting.

This sounds good but if you need it, you probably can and should refactor the code.

You know what would be great for refactoring the code? Some way to easily see what parts reference the variable you’re trying to refactor.

Unless you have spaghetti code or have built an abstraction tower, a variable is probably scoped/namespaced neatly. Often, it's just a quick grep to find it. In Emacs, if a variable is only used within a file, you can just `M-x occur` and do the editing there. Where those tools fail, is when you have ecosystems that tries to be clever (JavaScript with its transpilers, Java with its annotations)

Check out 'M-x multi-occur' -- same as 'occur', but scans all of the frame's open buffers. So useful I aliased it to 'M-x mo'

Thanks! So I learned something new about Emacs again. It never ends.

Aliasing something to make it easier to M-x sounds like the next step after running out of letters to use with C-c? I have not reached that point yet, but that was another thing I never considered that could be useful to remember.

> Unless you have

That is a big "unless". We aren't all working on pristine code written to high standards…

Yes, but not everyone uses features like this to make code easier to read. Instead, features like this make less readable code become tractible. The same can be said about autocomplete and documentation popups too. I remember Uncle Bob saying once that his 5 line function limit was facilitated by an editor feature he had that could easily display the code of functions that are called. So it stands to reason that the recommendation should be 25 lines if you don't have such a feature, I think. We don't need to go back to Hungarian notation but certainly using a bunch of fancy features to read the code makes it inherently less readable on the surface level (unless you are very anal and also self-aware and can stick to clean principles).

I'm surprised my comment was downvoted so bad for making an astute observation. It happens to me all the time. A lot of the users of this site suck.

And this comment will most likely be flagged now for whining about getting downvotes.

https://news.ycombinator.com/newsguidelines.html:

"Please don't fulminate. Please don't sneer, including at the rest of the community."

"Please don't comment about the voting on comments. It never does any good, and it makes boring reading."

Lol well where else am I supposed to talk about it? I get irritated about this stuff daily, so I don't really care if my short quips bore a person here or there. Being interesting is what gets me downvoted!

Well, I guess you're not supposed to talk about it haha.

But since it's irritating you I had a quick look at your comment history.

I would say that the downvotes are because a high percentage of your comments are argumentative, and occasionally just flat out insulting. Within that your tone is often condescending and dismissive.

Disagreement alone should not result in downvotes but I guess that's what happens when you do it among jerks lol. As for being condescending, I really like reductio ad absurdum and I think that rubs people wrong. Also somehow, the downvotes seem to pile up the more I reply, as a quirk of how they are calculated...

Reply on news.ycombinator.com