3 ms·

While I really love the stable nature of Go and its standard library, I am happy that this breaking change was put out there in the interest of security. This

While I really love the stable nature of Go and its standard library, I am happy that this breaking change was put out there in the interest of security. This issue hit me while building a tool for internal use at my employer. I am using the glide vendoring manager for this project, added another dependency which triggered an update of all other dependencies. At that point my tool broke and forced me to actually think about host key verification.

TheDong 9y ago
This isn't the standard library though, and if it were then it wouldn't have been changed.
- mbertschler 9y ago
  I didn't want to imply that. I meant that this kind of fix is a good reason to break something, and I am happy that they quickly reacted to this issue, and don't change everything all the time even though it is in the x/ packages and not covered by the standard library stability promise. In general I am very happy that the big emphasis on a stable APIs was taken up by the community, and that we have a lot of stable packages out now (even though they might not be 100% stable like the standard library). Since I also have to work with NodeJs where changing APIs and packages are much more common, I came to really appreciate that fact about the ecosystem.
- syscomet 9y ago
  It's a special case though. The golang.org/x/ packages are experimental but also candidates for promotion to the standard library. Eg, "context". But this sort of issue is exactly the sort of real-world review and hardening which justifies having a namespace for stuff to go _before_ it becomes stdlib.
  - kardianos 9y ago
    No, x repos are just eXtra. /x/exp is expiramental.
- bradfitz 9y ago
  We have broken compatibility once before in the standard library for security reasons. The go1compat doc says we're allowed to: https://golang.org/doc/go1compat https://golang.org/doc/go1compat > Security. A security issue in the specification or implementation may come to light whose resolution requires breaking compatibility. We reserve the right to address such security issues.

TheDong 9y ago

This isn't the standard library though, and if it were then it wouldn't have been changed.

mbertschler 9y ago
I didn't want to imply that. I meant that this kind of fix is a good reason to break something, and I am happy that they quickly reacted to this issue, and don't change everything all the time even though it is in the x/ packages and not covered by the standard library stability promise. In general I am very happy that the big emphasis on a stable APIs was taken up by the community, and that we have a lot of stable packages out now (even though they might not be 100% stable like the standard library). Since I also have to work with NodeJs where changing APIs and packages are much more common, I came to really appreciate that fact about the ecosystem.
syscomet 9y ago
It's a special case though. The golang.org/x/ packages are experimental but also candidates for promotion to the standard library. Eg, "context". But this sort of issue is exactly the sort of real-world review and hardening which justifies having a namespace for stuff to go _before_ it becomes stdlib.
- kardianos 9y ago
  No, x repos are just eXtra. /x/exp is expiramental.
bradfitz 9y ago
We have broken compatibility once before in the standard library for security reasons. The go1compat doc says we're allowed to: https://golang.org/doc/go1compat https://golang.org/doc/go1compat > Security. A security issue in the specification or implementation may come to light whose resolution requires breaking compatibility. We reserve the right to address such security issues.