By amazing do you mean specifically for Go? Because I don’t see how it differs from working on two Maven projects simultaneously in Java where one depends on the other.
E.g. if your workspace looks like this:
workspace/
mod1/
mod2/
Then both mod1 and mod2 will pull their dependencies remotely.But if you add a file to workspace/go.work, then local versions of mod1 and mod2 can be used without changing either mod1 or mod2.
As you can see it's quite complicated. The contents of go.work is literally
mod1/
mod2/
Also, the go.work file is meant to be your local workspace. If mod1 and mod2 have dependencies between each other, they should declare them explicitly and pull them in from the remote in most cases. The go.work file is only when you want to work on both modules locally. Meaning you don't check in go.work to your github repository in most cases.I wasn’t aware about “not checking in go.work”. What if you want separate modules to be aware of each other but keep them in the same repo?
Yes and no. It depends. You can use modules. With modules, each sub project lives in a directory under the root project. Maven reactor figures out the build order and all that crazy stuff. It’s the same with sbt and gradle.