4 ms·

I actually like it. Makes it really easy to share code between my own programs - really handy for "microservice" projects. And if I want to have a Go program in

by geoka9 10y ago

I actually like it. Makes it really easy to share code between my own programs - really handy for "microservice" projects. And if I want to have a Go program in a different source tree, links allow me to do that.

alexbecker 10y ago
But how do you distribute such a project? Do you need an install script with any OSS project that includes go code, which sets up a bunch of links in the user's GOPATH directory? I imagine this script would be bug-prone and difficult for most users to debug.
- regecks 10y ago
  I distribute commercial Go source with a Dockerfile to build the app (and rpm package) and it has been received remarkably well - better than I had imagined. YMMV.
- geoka9 10y ago
  I've only used Go for SaaS backends but if I wanted to distribute the code to 3rd parties I'd probably use a Dockerfile too.
takeda 10y ago
Go is opinionated how things are done, and just happens that its opinion fits yours, the issue is what when it doesn't? With non-opinionated languages nothing is stopping you from structuring your code the same way. Some people stated how hard go makes it when you try to have project that utilizes different languages. Another issue is when you try to use a fork of one of library. Yet another is that it is much more complex to generate a package (e.g. rpm) of projects that has many dependencies.
- geoka9 10y ago
  > With non-opinionated languages nothing is stopping you from structuring your code the same way. With Go, I can do `go build $project` from anywhere and get a releasable binary in the working directory. I can do `import "$oldproject/$package"` in my new project and start using it immediately. I can use `godef` to jump around all of the Go code installed on my system and quickly drill down all the way to the Go builtins if I need to. I can use `guru` to see all references to a definition across all of the Go packages installed on my system. The list goes on. And I can do all of that from a favorite text editor (and not a huge slow IDE). I never felt so liberated in any other programming environment, and I've used quite a few. > Yet another is that it is much more complex to generate a package (e.g. rpm) of projects that has many dependencies. Go binaries have only the standard system libraries for dependencies - for all practical purposes they can be considered static. Or you mean something else? > Some people stated how hard go makes it when you try to have project that utilizes different languages. I've used links successfully, but maybe my scenarios were not complex enough? > Another issue is when you try to use a fork of one of library. Vendor support since 1.6 made this a nonissue; it's now trivial to use forked versions of libraries.
- Merovius 10y ago
  > Another issue is when you try to use a fork of one of library. A fork of a library is either identical to the original, or a new library. And you could argue (or rather: I do), that it is a good thing that you need to explicitly specify which one you intend to use.
  - takeda 10y ago
    So let say you use code with many dependencies, but you want to make a small change in one of the dependencies. In other languages you would then just compile and be done with it, but now with golang you now need to also modify potentially hundreds of places unless you resort to somehow cheat golang. As I said, being opinionated is great if the opinion matches yours otherwise you might end up fighting it on every step.

by geoka9 10y ago

alexbecker 10y ago

But how do you distribute such a project? Do you need an install script with any OSS project that includes go code, which sets up a bunch of links in the user's GOPATH directory? I imagine this script would be bug-prone and difficult for most users to debug.

regecks 10y ago
I distribute commercial Go source with a Dockerfile to build the app (and rpm package) and it has been received remarkably well - better than I had imagined. YMMV.
geoka9 10y ago
I've only used Go for SaaS backends but if I wanted to distribute the code to 3rd parties I'd probably use a Dockerfile too.

takeda 10y ago

Go is opinionated how things are done, and just happens that its opinion fits yours, the issue is what when it doesn't? With non-opinionated languages nothing is stopping you from structuring your code the same way. Some people stated how hard go makes it when you try to have project that utilizes different languages. Another issue is when you try to use a fork of one of library. Yet another is that it is much more complex to generate a package (e.g. rpm) of projects that has many dependencies.

geoka9 10y ago
> With non-opinionated languages nothing is stopping you from structuring your code the same way. With Go, I can do `go build $project` from anywhere and get a releasable binary in the working directory. I can do `import "$oldproject/$package"` in my new project and start using it immediately. I can use `godef` to jump around all of the Go code installed on my system and quickly drill down all the way to the Go builtins if I need to. I can use `guru` to see all references to a definition across all of the Go packages installed on my system. The list goes on. And I can do all of that from a favorite text editor (and not a huge slow IDE). I never felt so liberated in any other programming environment, and I've used quite a few. > Yet another is that it is much more complex to generate a package (e.g. rpm) of projects that has many dependencies. Go binaries have only the standard system libraries for dependencies - for all practical purposes they can be considered static. Or you mean something else? > Some people stated how hard go makes it when you try to have project that utilizes different languages. I've used links successfully, but maybe my scenarios were not complex enough? > Another issue is when you try to use a fork of one of library. Vendor support since 1.6 made this a nonissue; it's now trivial to use forked versions of libraries.
Merovius 10y ago
> Another issue is when you try to use a fork of one of library. A fork of a library is either identical to the original, or a new library. And you could argue (or rather: I do), that it is a good thing that you need to explicitly specify which one you intend to use.
- takeda 10y ago
  So let say you use code with many dependencies, but you want to make a small change in one of the dependencies. In other languages you would then just compile and be done with it, but now with golang you now need to also modify potentially hundreds of places unless you resort to somehow cheat golang. As I said, being opinionated is great if the opinion matches yours otherwise you might end up fighting it on every step.