Hacker News Reader

Comment by todotask | Hacker News Reader

One of those point under "Expectations" can be explain in this page

Nope, none of these points apply to the specific change, atleast as far as I am able to tell. The code that broke did not use unsafe when I last updated it and then it simply didn't work anymore in the current go version.

I agreed with jeffsmith82's comment.

That comment isn't applicable either; I had x/crypto vendored so any fix upstream wouldn't break my app.

I'm afraid blake2 used assembly and runtime.support_avx2, which doesn't seem to be covered by the compatibility promise: assembly is part of the toolchain, and the symbol it used was an internal one.

See:

https://go-review.googlesource.com/c/crypto/+/110355/

https://go-review.googlesource.com/c/crypto/+/110016/

So, my code broke because a library that was provided by the go developers used some unstable feature I had no idea about and had no real way of knowing short of checking a dependency three levels below my project? And to top that, that library was certainly subject to API breakage, the entire reason I vendored it in the first place.

It doesn't seem reasonable to me. When I developed my project, vendoring /x/ projects was recommended exactly due to the breakage, so now it breaks my projects because of recommendations of the golang team.

I believe one of those probably applies.

> Use of package unsafe. Packages that import unsafe may depend on internal properties of the Go implementation. We reserve the right to make changes to the implementation that may break such programs.

I suspect the crypto code you vendored used unsafe somewhere within it (whether to use `//go:linkname` or for other reasons), which would except it from the go1 compatibility promise.

Reply on news.ycombinator.com