I guess in the sense that you only need the Go toolchain, rather than also needing a C toolchain to compile+link an extra C object file into your binary.
IMO, it's playing fast and loose with that term, but I guess the point is that it's not using CGO (i.e. calling into C code). It is, however, using the assembler packaged with the Go tools, so in that regard it's not "pure" go.
The terminology in this context is already fast and loose: It is rigorous in a practical engineering sense and is far from a mathematical level of precision. As I pointed out above, the maintainers could just define Go to include a few Assembly languages.
Comments
Possibly I'm confused, but in what sense is this "in Pure Go"?
I guess in the sense that you only need the Go toolchain, rather than also needing a C toolchain to compile+link an extra C object file into your binary.
IMO, it's playing fast and loose with that term, but I guess the point is that it's not using CGO (i.e. calling into C code). It is, however, using the assembler packaged with the Go tools, so in that regard it's not "pure" go.
IMO, it's playing fast and loose with that term
The terminology in this context is already fast and loose: It is rigorous in a practical engineering sense and is far from a mathematical level of precision. As I pointed out above, the maintainers could just define Go to include a few Assembly languages.
It doesn't use CGO.