Correction, Go makes compiling and dependencies easy. It does not provide me with a platform for incremental distribution. If i could `go push v1.0 myapp` and you could download my 1.0 binary from Google? Well, i'd do that gladly.
And in general, we all spend as much time as we're willing to on free OSS. Usually it's for problems we solve, for ourselves. Unless you come to my repo and ask me for a binary, i have no information about anyone who is unable to build the binaries - or what their platform/arch might even be.
Do i build for everything, all the time, on the off chance that some random sysadmin might want to use `curl -O myrepo/bin` instead of `go get myrepo/bin`? I choose not to personally - but if the project gets popular, and there is a legitimate need for people to be able to download the bin, i'd gladly manage it. This is just not the default thing for me to do.
> Most of the people who want to use your app are not going to be other go developers.
In my example, you're wrong there. As i said, I'm choosing to do this because i'm targeting go developers. If i was writing a windows GUI app, of course i would release a binary.
> Versioning your code is a good practice and if there's a hosted binary release somewhere I can rely on it in my docker/config management process.
I'm not sure i follow here. I do version my code. Infact, it's even more versioned than if i used ldflags (imo) - because by injecting the version from Git at compile time, my binary has the version, but my code doesn't. You have to have my git repo, to know what version my code is at.
Moreover, with ldflags, you have to download my binary. You can't simply `go get foo/bar` to get the bin.
I understand your frustration, bins are nice - but strictly speaking from an OSS perspective, there is too much resistance in the process of releasing binaries (to my knowledge).
Perhaps there is a tool to automatically push a binary for a specific git tag to Github?
Correction, Go makes compiling and dependencies easy. It does not provide me with a platform for incremental distribution. If i could `go push v1.0 myapp` and you could download my 1.0 binary from Google? Well, i'd do that gladly.
And in general, we all spend as much time as we're willing to on free OSS. Usually it's for problems we solve, for ourselves. Unless you come to my repo and ask me for a binary, i have no information about anyone who is unable to build the binaries - or what their platform/arch might even be.
Do i build for everything, all the time, on the off chance that some random sysadmin might want to use `curl -O myrepo/bin` instead of `go get myrepo/bin`? I choose not to personally - but if the project gets popular, and there is a legitimate need for people to be able to download the bin, i'd gladly manage it. This is just not the default thing for me to do.
> Most of the people who want to use your app are not going to be other go developers.
In my example, you're wrong there. As i said, I'm choosing to do this because i'm targeting go developers. If i was writing a windows GUI app, of course i would release a binary.
> Versioning your code is a good practice and if there's a hosted binary release somewhere I can rely on it in my docker/config management process.
I'm not sure i follow here. I do version my code. Infact, it's even more versioned than if i used ldflags (imo) - because by injecting the version from Git at compile time, my binary has the version, but my code doesn't. You have to have my git repo, to know what version my code is at.
Moreover, with ldflags, you have to download my binary. You can't simply `go get foo/bar` to get the bin.
I understand your frustration, bins are nice - but strictly speaking from an OSS perspective, there is too much resistance in the process of releasing binaries (to my knowledge).
Perhaps there is a tool to automatically push a binary for a specific git tag to Github?