Go's Tooling Is an Undervalued Technology
Coming from the C# and JVM world to go, tooling looked like one of the worst parts of Go.<p>The debugging story is very limited:<p>- No function execution<p>- No edit-and-continue<p>- No conditional breakpoints<p>- No watchpoints<p>Package management works OK on the consumption side, though it is much more clunky than with classic package managers (e.g. set an ENV variable to get a custom proxy, but write something in go.mod file to get a per-package proxy). However, the publishing side is all over the place:<p>- Relies on source-control integration<p>- Horrible import paths for packages published from large repos<p>- Versioning based on source-control tagging, exact format undocumented<p>- Major version changes require source-code level changes in all files touching the package<p>- Multiple Go modules in same repo use-case is not documented (can you have separate versions from same commit? how do they reference each other?)<p>The source-code level tools/plugins available are extremely basic (except for GoLand):<p>- No refactoring support other than "rename variable"<p>- Reference-finding across modules rarely seems to work<p>- No way to automatically find all implementations of an interface - especially problematic in a language with implicit interface implementation<p>- The tools are pretty slow, constantly re-parsing large chunks of code; go pls has fixed some of that