Hacker News Reader

Comment by randomdata | Hacker News Reader

> Without that clarity, you end up with incompatible, spec-compliant implementations.

The Go team officially maintains two implementations, gc and gccgo, to ensure that implementation doesn't end up ruling over the specification as has happened in other languages. There are also other third party implementations, including tinygo.

Which spec-induced incompatibilities across these implementations are you referring to?

View on HN

Go doesn't have a one-page spec, so what do you expect the GP to point to? You are proving his point.

Looks like one page to me: https://go.dev/ref/spec

Yeah, no.

Feel free to show us the second page.

It starts about 2/3 of the way through the table of contents.

A link is fine.

https://go.dev/ref/spec#:~:text=Declarations%20and%20scope-,...

That points to the same page.

It's now become abundantly clear to everyone that you're using a different definition of "page" than everyone else in this conversation.

The only other person in this conversation is you, so not exactly the most representative of samples, but it is an interesting perspective. I've not heard anyone else consider the same HTML resource to be more than one page before. In fact, the term "single page application" hinges on a single HTML resource in the same way. The application may have more than one screen of content, but it is still considered one page.

oxnrtr is in this conversation too. And when describing the length of a document, "pages" universally means the number of printed pages it would occupy, not the number of computer files it's stored in.

There is no sign of anyone else participating in this conversation. Else we'd have heard their input by now. A page referring to a single HTML resource is standard nomenclature. Paper is antiquated technology, not how the Go specification is distributed, and carries no relevance to this discussion.

I hope you receive the help you need and deserve.

Reply on news.ycombinator.com