Hacker News Reader

Comment by cakoose | Hacker News Reader

On slide 9 it says that enhancing the syntax for "import" would be a backwards-incompatible syntax change. Sure, old compilers wouldn't accept newer code, but newer compilers would accept old code without breaking the behavior.

Is Go's definition of "backwards compatible" different from the usual one?

View on HN

Slightly OT, but it's kind of strange to suggest enhancements to the import statement when the spec explicitly states that an import statement contains an opaque string.

It's the go build tool that add semantics to the values of the import statement, not the language.

The issue is more with older code not compiling on newer compilers if the syntax is changed. Go works on the basis of no breaking changes between major versions.

I guess theoretically it could be changed in such a way that both the older and newer syntax would be valid on newer compilers, but that adds additional complexity which is also an anti-Go idiom.

So sadly we're left with two alternatives: 1) code rewriting / generation, or 2) 3rd party compilers.

But it looks like Go has done similar things in the past. For example, the slicing operation gained an additional optional argument (https://golang.org/doc/go1.2#three_index). It's not exactly the same thing, but it seems roughly in the same league of difficulty.

Based on what I'm reading, versioning is a serious pain point. Sure, you always have to make sure the payoff is worth the additional complexity (universally, not just in Go) but the author seems to categorically disqualify this option by incorrectly saying that it would break backwards compatibility.

> But it looks like Go has done similar things in the past. For example, the slicing operation gained an additional optional argument (https://golang.org/doc/go1.2#three_index). It's not exactly the same thing, but it seems roughly in the same league of difficulty.

It's not really same in my opinion. Slices already accepted multiple parameters - or even none. So adding another optional parameter doesn't affect the syntax. Where as import names are all stored in a single quoted string, so you'd have to rethink the entire structure of the import syntax (which leaves you with two import different methods of expressing imports - which is messy) or use some nasty kludge of including versioning within the import string.

What's more versioning is only half the story here. There's other issues with Go's imports that this author aims to resolve - such as the dependency on a static repo. Because import paths are based directly on the repo path (eg github.com) it makes it a pain to prototype code in a private repository before pushing changes public. And then there's issues with dependency on any specific resource (you can't use mirrored repos with go get), plus a whole slew of related issues regarding hard-coded repo paths.

So versioning is only half the story.

> Based on what I'm reading, versioning is a serious pain point. Sure, you always have to make sure the payoff is worth the additional complexity (universally, not just in Go) but the author seems to categorically disqualify this option by incorrectly saying that it would break backwards compatibility.

Well I've already argued that any clean solution would break backwards compatibility and any kludge would be messy and rather short sighted (plus potentially may not address the other issues with go get and import()).

So I think it's a little misjudged for you to say he's "incorrect" in his opinion in the way that you have.

From what I gather the commenter is saying that a new compiler could accept this syntax:

      import "github.com/pkg/term" "{hash,tag,version}"

And this (old) syntax:

       import "github.com/pkg/term"

Meaning the language would be backwards compatible. But you're saying that this wouldn't be backwards compatible - why ?

Your method doesn't follow the same format as the rest of Go's syntax (eg comma delimited lists) which could break any 3rd party pre-parsers or other such tooling. So there's the potential break backwards compatibility there.

Plus lumping everything within the second set of quotes means you don't have idiomatic styling nor a simple method for the gofmt to validate since you have a list handled as a string. So it's not really a clean fix in my opinion (which was one of the other points I raised).

Whatever we bake into the language will be set in stone for all of the foreseeable future - regardless of whether it's a good change or bad change. So I tend to think it makes more sense to use 3rd party tooling to address this problem for now, and then bring whatever method seems to work the best into the official language specifications for Go 2.0. Other people's opinions might differ, but that's why I personally prefer the approach this author it taking.

> Your method doesn't follow the same format as the rest of Go's syntax (eg comma delimited lists) which could break any 3rd party pre-parsers or other such tooling. So there's the potential break backwards compatibility there.

The new slicing syntax could have broken 3rd party pre-parsers or other tooling. Yet that change was considered backwards-compatible.

It could have done, but there's fewer tooling that parse slices (particularly at that point in time) than there are which parse import strings (there's lots and lots of tools that already do that!).

However the other key point is one I made earlier: slices already support a number of optional parameters so the language semantics didn't change even if the syntax of slices were expanded. adding 1 additional optional parameter to a property that already supports multiple optional parameters really isn't comparable to the import example which had a list of values represented in a new and completely non-idiomatic way (Ie initially without punctuation and then nested inside a string. Nothing else in Go follows that pattern, let alone the import strings already).

Reply on news.ycombinator.com