Hacker News Reader

Comment by doorman2 | Hacker News Reader

Go workspaces are amazing. You create a go.work file, add a line with each module you're working on, and then the Go language server handles the rest. Solutions and projects seem way more complicated, but also not entirely congruent. A Go workspace is used when you have two modules that depend on each other and you want to work on both concurrently. The two modules are still independent and could be worked on individually by pulling in the latest release of the other module.

The modules in a workspace may have entirely different ownership. For instance, let's say you're using a WebRTC library to run a selective forwarding unit as part of your video conferencing app. Maybe you notice a bug in the WebRTC library. You can check out the code for the WebRTC library and add it to your workspace so you can test your application against your local WebRTC library changes.

View on HN

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.

In maven, don't you need to update the pom file of the projects to point to the local copy? What's nice about the Go workspace system is that the workspace lives above the individual modules, meaning that the individual modules don't need any modification to pull in local dependencies.

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.

> In maven, don't you need to update the pom file of the projects to point to the local copy?

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.

This is how a VS Solution is. You can have it anywhere in the file system and points to different projects. How those projects are on your file system its up to you (aka git clone, git submodule)

You can read about the VS solution format here: https://learn.microsoft.com/en-us/visualstudio/extensibility...

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.

Yeah the VS sln file is outdated and meant only to be used by the IDE. There are talks about revamping it, like the C# csproj had.

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?

See https://news.ycombinator.com/user?id=rad_gruchalski response

Reply on news.ycombinator.com