3 ms·
The design of the Go build and packages system kinda renders that point moot because the expectation is that provided you follow Go's guidelines then a Go appli
by DaiPlusPlus 5y ago
The design of the Go build and packages system kinda renders that point moot because the expectation is that provided you follow Go's guidelines then a Go application should always be easily recompilable, and all external dependencies should always be distributed in source-form, not as binaries (e.g. https://github.com/golang/go/issues/2775 https://github.com/golang/go/issues/2775 ).
- Macha 5y agoRight, but if every application did distribute as source and could just be recompiled, there would be fewer complaints about the difficulties distributing Linux binaries
- Zababa 5y ago> provided you follow Go's guidelines then a Go application should always be easily recompilable, and all external dependencies should always be distributed in source-form, not as binaries So it's a human solution, and not a technical one, which means that it can and will fail.
- DaiPlusPlus 5y agoThat's like saying condoms are ineffective because you included people too lazy to put them on in the first place in your calculations. Provided you (and your org) use Go as Google intends then that isn't an issue.
- Zababa 5y ago> That's like saying condoms are ineffective because you included people too lazy to put them on in the first place in your calculations. I think it's closer to say that the existance of condoms won't make AIDS and unwanted pregnancies disappear, even if they were 100% effective. Which, if you're trying to eliminate completly AIDS, is a fair claim to make. My point is that you shouldn't assume that everyone is going to follow the Go guidelines, because some people won't, and you don't want your security to rely on that.