Hacker News Reader

Comment by Jabbles | Hacker News Reader

Meh.

1. How often do you insert into a slice? You know that's a O(n) operation, right?

2. nil is typed, I'll grant that it's not the most obvious part of Go's type system.

3. Meh.

4. This is type covariance. It's complicated and hard to get right. The Java Generics FAQ looks like this: http://www.angelikalanger.com/GenericsFAQ/JavaGenericsFAQ.ht...

5. I like by-value loops. Everything else in Go is by-value.

6. Yeah, fuck everything we know about parsing, let's make whitespace significant, then we can declare slices like:

    x := []int{
      1
      -2
      +3
    }
    len(x) == 3
    y := []int{1 -2 +3}
    len(y) == 1

7. Meh

View on HN

That's not type covariance. Variance only comes up when you have generics, which Go doesn't, and subtyping, which Go doesn't really have. It's the lack of a coercion/conversion between slice-of-T to slice-of-interface.

The correct language-level solution to #4 is to introduce generics and to allow generic type parameters to have interface bounds. That would solve the problem without having to introduce variance.

Isn't it possible to talk about variance as soon as you have a type constructor (function from types to types)? In this case [].

Edit: I don't know go, but if slices give write access, I think the automatic conversion the author wants would be unsound.

Yes, a coercion would be unsound (at least, unless the coercion copied the backing store of the slice, which would be very unintuitive). It shouldn't coerce. I'm describing generic type parameter bounds, which are not the same thing.

(For what it's worth, I'm not sure I would bother solving this problem if I were suddenly put in charge of Go's design, given Go's extreme aversion to type system features. I'm just describing what the solution to this problem typically is.)

I don't see how it's not type covariance.

Go's slices are generic to the extent needed, and the subtyping of Go's interfaces fits the requirements for ordering of types well enough.

In Go, if T implements interface I, T is not a subtype of the interface type I. T can be converted to the interface type I, but it's not a subtype.

What's the difference though? Is this true of interfaces in Java for instance, or does it have to do with the specific implementation of go?

I don't know if you need to make whitespace any more significant in Go than it already is to implement 6. As you may know, Go inserts semicolons at the end of a line in the lexing phase if a token of the right type is the last one on the line (https://golang.org/ref/spec#Semicolons):

> • an identifier

> • an integer, floating-point, imaginary, rune, or string literal

> • one of the keywords break, continue, fallthrough, or return

> • one of the operators and delimiters ++, --, ), ], or }

The things you can put as elements of a slice, values of a map, or values in a struct literal are Expressions nonterminal symbols (https://golang.org/ref/spec#Expression). As far as I can tell, the tokens that can end an Expression are a subset of those after which semicolons can be automatically inserted.

This sums up my opinion on this pretty well.

On 1 I'll just say it'd be nice if append (and other varargs functions) could take multiple of individually listed and slice-expanded args at the same time. As in: `append(a[:2], 3, a[2:]...)`. I already expect append to be O(n), and this would be some very nice sugar.

Yes, the syntax here just looks so unnecessarily ugly. For all the talk of Pythonistas moving to go, I can't see myself switching over to a language with so many ugly, hard-to-remember warts.

Reply on news.ycombinator.com