Hacker News new | ask | show | jobs
by codexon 4137 days ago
I was using Go recently and I ran into some simplicity issues. It is not straightforward to create a map of net.IPs or manipulate netmasks. You will have to copy to and from a separate array/integer.
3 comments

That is not a simplicity issue.

"Something that is simple may take longer to write and might be more verbose" -- from the article.

In a simple language, there should not be functions that do exactly what you want to do; that would be a sign of the language being complex and featureful, which are enemies of simple.

(and yes, this is a bit tongue-in-cheek)

Even in a simple language, simple things should be simple. Granted, it's easy to make complex things sound simple, but the example given seems simple.
net.IP is implemented as a []byte. Byte slices are not valid keys (you can't use the "==" operator).

An alternative would be to use [16]byte as your map keys and then subslice the array for net.IP.

Why isn't a byte slice a valid key? If anything, there should be a pretty straightforward equality check on an array of bytes.
A slice is not an array of bytes. That's exactly the point.

See http://blog.golang.org/go-slices-usage-and-internals to get a basic understanding

OK so I've read it. Slices sound exactly like one would guess, using the word from other languages. A view into an array.

So exactly why are they not suitable for equality? Even that article starts with "Slices are analogous to arrays in other languages". Please elaborate on this basic thing.

For an array (which are value types in go) you have the obvious element-wise equality.

For slices? Also element-wise? Even with different capacities? If the refer to the same window in the underlying array? Is there a need to copy the slice for inserting it to the map? Probably yes, because otherwise you could mutate the key from outside. But then it would be inconsistent to assignment (slices are reference types).

I have no idea how this could be done concisely.

Yes, element wise, why anything else? Different lengths are not equal; if capacity is externally visible, then that needs to be part of the compare.

As far as the whole ownership issue, that's a bit more than just ==, isn't it? Equality was the only thing I was questioning.

My thoughts exactly
Congratulations. Welcome to why you don't use Go.

Lack of generic access to data structures is one of their bigger fails.

However, they don't see it that way. One point of Go was to prevent needing to describe things before being able to compile it. Most things that people regard as "failures" in Go were deliberate choices to enable large codebases.

No, that's not why you don't use go. What the parent comment is dealing with is the fact that you can't have maps keyed by a net.IP, which is implemented as a []byte. Byte slices are not valid keys. This isn't really about generics.
It is very much about polymorphism and generics.