4 ms·

Couldn't disagree more in the Go case. Folder-level namespaces (rather than file-level) makes Go exceptionally annoying to navigate, and interfaces heavily obsc

Couldn't disagree more in the Go case. Folder-level namespaces (rather than file-level) makes Go exceptionally annoying to navigate, and interfaces heavily obscure the.. interface between abstractions and implementations.

rubiquity 5y ago
I'll +1 Zig code, but I came here to say this about Go as well. Once Go codebases creep past medium sized (25-50k LOC perhaps) into large I find them to be inscrutable. I've noticed this even in projects that people in the community point to as the gold standard such as the various HashiCorp tools. I don't write much Go anymore but my hunch is that it's a combination of the package layout and auto method delegation for embedded structs. Even Java does a much better job of helping the developer at obviating the interfaces between different subsystems.
deleted 5y ago
[deleted]
psanford 5y ago
It seems like gopls solves your problems. It will do the correct thing for navigating to definitions and listing implementations of interfaces.
- Nullabillity 5y ago
  In my experience gopls hasn't been useful for much more than crashing. But that aside, Go's incessant insistence on structural typing makes it impossible for any tool to generate a list that is both complete and free from false positives.
KptMarchewa 5y ago
Java basically does the same thing and I've never heard anyone complaining about that. Python does the file level thing and it's source of constant annoyances with cyclical imports. Ugh, wasted so much hours on fixing it.
- Nullabillity 5y ago
  > Java basically does the same thing and I've never heard anyone complaining about that. I don't love dealing with Java, but it has none of these particular issues. It's easy to find the definition of a class, because it enforces that the file path must match the fully qualified class name for all public classes (and this tends to be followed for privates as well in practice). Finding the implementation isn't quite trivial, but if you know a class in the tree then you can easily find the whole parent tree by following the "extends Foo" clauses, or find subclasses by grepping for it instead.

rubiquity 5y ago

I'll +1 Zig code, but I came here to say this about Go as well. Once Go codebases creep past medium sized (25-50k LOC perhaps) into large I find them to be inscrutable. I've noticed this even in projects that people in the community point to as the gold standard such as the various HashiCorp tools. I don't write much Go anymore but my hunch is that it's a combination of the package layout and auto method delegation for embedded structs. Even Java does a much better job of helping the developer at obviating the interfaces between different subsystems.

deleted 5y ago

[deleted]

psanford 5y ago

It seems like gopls solves your problems. It will do the correct thing for navigating to definitions and listing implementations of interfaces.

Nullabillity 5y ago
In my experience gopls hasn't been useful for much more than crashing. But that aside, Go's incessant insistence on structural typing makes it impossible for any tool to generate a list that is both complete and free from false positives.

KptMarchewa 5y ago

Java basically does the same thing and I've never heard anyone complaining about that. Python does the file level thing and it's source of constant annoyances with cyclical imports. Ugh, wasted so much hours on fixing it.

Nullabillity 5y ago
> Java basically does the same thing and I've never heard anyone complaining about that. I don't love dealing with Java, but it has none of these particular issues. It's easy to find the definition of a class, because it enforces that the file path must match the fully qualified class name for all public classes (and this tends to be followed for privates as well in practice). Finding the implementation isn't quite trivial, but if you know a class in the tree then you can easily find the whole parent tree by following the "extends Foo" clauses, or find subclasses by grepping for it instead.