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.
You can still use re-exports (pub use) to hide it from the public API.
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?
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.
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.
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.
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.
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.