Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Go 1.13 Release Notes

golang.org

Post reply on HN
Print view View original

231–240 of 264 posts

Re: Go 1.13 Release Notes

#231

Post by omaranto »

ainar-g wrote: post #187
omaranto wrote: post #138

Earlier quoted context omitted.

I always have trouble explaining this limitation of Go maps. First, a string can point to an unlimited amount of data (i.e., it can be of arbitrary length) and all of its characters are taken into account when deciding string equality. Now, an array type in Go is not like that: the length of the array is part of the type. There is (or at least there wasn't when I last checked) no type of all arrays of ints, say, but…

I see now, thanks. Existing maps will probably remain that way forever, but the new Generics Draft Design[1], if implemented, should allow people to easily write a wrapper that will work on anything. [1]: https://go.googlesource.com/proposal/+/58566e5309365c84587ae...

Fixing the existing maps sounds a lot easier than adding generics. All that would be required is to allow slices as keys. If there is a concern about immutability you could just say mutating a slice used as a key leads to undefined behavior.

Re: Go 1.13 Release Notes

#232

Post by ainar-g »

omaranto wrote: post #231
ainar-g wrote: post #187

Earlier quoted context omitted.

I see now, thanks. Existing maps will probably remain that way forever, but the new Generics Draft Design[1], if implemented, should allow people to easily write a wrapper that will work on anything. [1]: https://go.googlesource.com/proposal/+/58566e5309365c84587ae...

Fixing the existing maps sounds a lot easier than adding generics. All that would be required is to allow slices as keys. If there is a concern about immutability you could just say mutating a slice used as a key leads to undefined behavior.

AFAIK, “undefined behaviour” is not a thing in Go The Language (there is some undefined behaviour in the Go The StdLib). The Go Specification[1] doesn't even contain the word “undefined”, and only has two instances of “unspecified”.

I guess that if immutable slices became a thing, one would probably be able to use them as map keys. But so far the Go Team is very reluctant about adding immutability to the language.

[1]: https://golang.org/ref/spec

Re: Go 1.13 Release Notes

#233

Post by omaranto »

ainar-g wrote: post #232
omaranto wrote: post #231

Earlier quoted context omitted.

Fixing the existing maps sounds a lot easier than adding generics. All that would be required is to allow slices as keys. If there is a concern about immutability you could just say mutating a slice used as a key leads to undefined behavior.

AFAIK, “undefined behaviour” is not a thing in Go The Language (there is some undefined behaviour in the Go The StdLib). The Go Specification[1] doesn't even contain the word “undefined”, and only has two instances of “unspecified”. I guess that if immutable slices became a thing, one would probably be able to use them as map keys. But so far the Go Team is very reluctant about adding immutability to the language. [1…

Lots of currently allowed map keys can be mutated such as structs or arrays. Let whatever happens when you mutate them (what does happen?) happen also for slices.

Re: Go 1.13 Release Notes

#234

Post by tapirl »

bakery2k wrote: post #224
tapirl wrote: post #199

Earlier quoted context omitted.

> In Python you are allowed to use tuples of immutable objects as keys You can do this in Go too with structs.

Don't all the keys in a Go map have to have the same type? So if you use structs as keys, they all need to have the same length? In Python, you can use (1, 2), (3, 4, 5) and (6, 7, 8, 9, 10) all as keys in the same map.

Same in Go, you can use interface{} values as keys, the concrete values of the interface keys can be a 2-element, 3-element or n-element array values.

    package main
    import "fmt"
    
    func main() {
        var m = map[interface{}]int {
            [2]int{1, 2}: 12,
            [3]int{1, 2, 4}: 123,
            [4]int{1, 2, 3, 4}: 1234,
        }
        fmt.Println(m)
    }

Re: Go 1.13 Release Notes

#235

Post by ainar-g »

omaranto wrote: post #233
ainar-g wrote: post #232

Earlier quoted context omitted.

AFAIK, “undefined behaviour” is not a thing in Go The Language (there is some undefined behaviour in the Go The StdLib). The Go Specification[1] doesn't even contain the word “undefined”, and only has two instances of “unspecified”. I guess that if immutable slices became a thing, one would probably be able to use them as map keys. But so far the Go Team is very reluctant about adding immutability to the language. [1…

Lots of currently allowed map keys can be mutated such as structs or arrays. Let whatever happens when you mutate them (what does happen?) happen also for slices.

Uhm, no, they cannot be mutated. If you use a structure with two integers as a key and then change one of these integers, then you have a new value, and a new key, just like with integers.

Re: Go 1.13 Release Notes

#236

Post by psanford »

Gibbon1 wrote: post #193
ptman wrote: post #192

Earlier quoted context omitted.

To not break go1 backwards compat?

Compatible with what exactly. No one uses octal. Here is a link to Pike fucking it up 10 years ago. https://github.com/golang/go/issues/151#issuecomment-6604830...

Lots of code uses octal. Its still the standard way of notating file permission bits on unix: os.Chmod(filename, 0777).

You would break so much code if you just threw that away.

Re: Go 1.13 Release Notes

#237

Post by rb808 »

tapirl wrote: post #204
rb808 wrote: post #62

Earlier quoted context omitted.

I just wish there were more jobs for either. They're both much less popular than I expected.

It depends on which fields of your expected jobs are. Go is the language of cloud infrastructure, and half of blockchian projects are written in Go.

Right. I'm not interested in either of those fields. I want to use Go instead of Java/Scala, but there is little appetite.

Re: Go 1.13 Release Notes

#238

Post by omaranto »

tapirl wrote: post #234
bakery2k wrote: post #224

Earlier quoted context omitted.

Don't all the keys in a Go map have to have the same type? So if you use structs as keys, they all need to have the same length? In Python, you can use (1, 2), (3, 4, 5) and (6, 7, 8, 9, 10) all as keys in the same map.

Same in Go, you can use interface{} values as keys, the concrete values of the interface keys can be a 2-element, 3-element or n-element array values. package main import "fmt" func main() { var m = map[interface{}]int { [2]int{1, 2}: 12, [3]int{1, 2, 4}: 123, [4]int{1, 2, 3, 4}: 1234, } fmt.Println(m) }

Oh, cool! This still doesn't quite get rid of my complaint since the size of an array must be known at compile time, but it's good that they don't all have to be the same size.

Re: Go 1.13 Release Notes

#239

Post by omaranto »

ainar-g wrote: post #235
omaranto wrote: post #233

Earlier quoted context omitted.

Lots of currently allowed map keys can be mutated such as structs or arrays. Let whatever happens when you mutate them (what does happen?) happen also for slices.

Uhm, no, they cannot be mutated. If you use a structure with two integers as a key and then change one of these integers, then you have a new value, and a new key, just like with integers.

That didn't quite clear up for me what happens when you mutate keys, so I ran a quick experiment. It seems like maybe the map stores a copy of the key, as the map doesn't "see the mutation".

    package main

    import "fmt"

    func main() {
        x := [2]int{1, 2}
        m := make(map[[2]int]int)
        m[x] = 5
        fmt.Println(m[x])
        x[1] = 3
        fmt.Println(m[x], m[[2]int{1, 2}], m[[2]int{1, 3}])
        for k, v := range m {
            fmt.Println(k, v)
        }
    }
This prints:

    5
    0 5 0
    [1 2] 5
I'd be perfectly happy if slices were allowed as keys with the same semantics as arrays...

Re: Go 1.13 Release Notes

#240

Post by erik_seaberg »

Thaxll wrote: post #173
erik_seaberg wrote: post #95

Earlier quoted context omitted.

Java got async I/O in 2002, generics and "for (x : iterable)" in 2004, and lambdas in 2014. Vintage 2001 Java was drastically harder to read and slower, though error handling was always less cumbersome than Go.

"error handling was always less cumbersome than Go" You mean useless stack traces 50 lines long?

You're free to filter any of that out, and the boilerplate that generated it doesn't obstruct your reading of useful code.
Post reply on HN