Hacker News new | ask | show | jobs
by Nullabillity 2046 days ago
As someone who mostly writes Rust these days, I find it really nice that I can always (as long as I don't use wildcard imports) use intra-file search to find either the definition or the file that contains the definition.

Whenever I have to touch Go code (for reading and debugging) it's really annoying to just end up going "okay, I've got the folder, now what". Or, even more annoyingly, I've just got an interface and no clue about where to find the implementation.

Of course, that wouldn't be so bad if pls was actually usable and helpful. But at the moment it would be hard to call it either of those things.

4 comments

An architectural side effect, at least in the case of Rust, is that when a file includes many data structures, they're going to be visible to each other.

Depending on the case, this may have practical implications or not, but architecturally speaking, it's not good form.

A practical side effect is that having a lot of data structures is going to clutter the outline view in the IDE.

Hence why you'd typically stick to ~one independent data structure per module.

You can still use re-exports (pub use) to hide it from the public API.

> Or, even more annoyingly, I've just got an interface and no clue about where to find the implementation.

That bites me often times. Does gopls help in this regard? Can any tool besides the compiler help me to answer, what methods in a particular piece of code implement what interface?

Not even the compiler knows, since interfaces are resolved at runtime. You could build a list of potential implementations, but then structural typing means that it can't know the difference between an intentional and accidental implementation.
Dont most IDEs solve this.

I do C# for my day job, if I have an interface I put cursor on it and hit a key and go to the definition, whatever file it's in. Another key will cycle the usages of the interface.

This has been solved for years. More recently we've had things like Peek as well.

But if you have to rely on an IDE, it's hard to innovate in language design.

Rust does have rust-analyzer, but it uses piles of RAM and often just doesn't work. I'll periodically try it for a few days and give up on it again. Maybe it's a bug in Kate's LSP support.

I have been using rust-analyzer with vscode (on small programs) and it has been working reliably for me.
> Dont most IDEs solve this.

Working IDEs do, but Go's PLS doesn't, and that's part of the GP's complaints:

> Of course, that wouldn't be so bad if pls was actually usable and helpful. But at the moment it would be hard to call it either of those things.

That is why i made the switch to Goland, even if i switched to VSCode from the Jetbrains Products before.

Sure its a bit sluggish in comparison (well only when indexing really), but finally i do not have to worry about not finding something or import-completion breaking every 2 weeks etc.

Just switch, you will stop thinking about your setup and just work instead.

Python, without wildcard imports, does the same.

Usage in Haskell is a bit more mixed, but I see a lot of 'qualified imports'.