3 ms·

/offtopic This kind of discussion is actually something that bothers me even more than generics at the moment : https://groups.google.com/forum/#!topic/golang

by bsaul 12y ago

/offtopic This kind of discussion is actually something that bothers me even more than generics at the moment : https://groups.google.com/forum/#!topic/golang-nuts/m7k9EpxqK4I https://groups.google.com/forum/#!topic/golang-nuts/m7k9Epxq... Come on... removing an item from a list requires tricks ?? I know go aims at being memory efficient, but delete(list,obj) should be idiomatic.

ansible 12y ago
Come on... removing an item from a list requires tricks ?? That's not a list, it is a slice. Which is a slight abstraction over an array. You the programmer are directly responsible for the size of the slice storage, and how many elements it currently contains. I know go aims at being memory efficient, but delete(list,obj) should be idiomatic. If this ends up being a common operation, I could understand arguments to add it to the language. But in general if you are adding / removing items a lot, you'd be better off using an actual list data structure instead.
- bsaul 12y ago
  Then i guess we're back to generics. Having to use this interface : http://golang.org/pkg/container/list/ http://golang.org/pkg/container/list/ , with its "Element" wrapping a "Value" property of type interface{} seems really weird for such a basic need. It means that whenever you're storing an object into the list, you need to remember the element in addition to the original object to be able to remove it later...
  - NateDad 12y ago
    Except that no one ever actually used that package. We just use normal slices which are generic.
    - bsaul 12y ago
      Hence my point... People use arrays like they would use ArrayList or Vector or any dynamic container created in the last 25 years and expect to be able to remove an object in one function call.
      - NateDad 12y ago
        And people use lists like they would an array and assume a list of 100 int64s uses 800 bytes, when it actually probably uses twice that much (if you're lucky).
scott_s 12y ago
I'm not a Go programmer, but I think this is a problem of data structure expectations. Slices are not "lists", but views into arrays. So, by design, slices are a view into contiguous chunks of values. In such structures, removing an item will necessarily be O(n). A general principle in interface design for data structures is don't make expensive things easy. So, if removal from a slice is O(n), then the data structure is obviously not optimized for that, so don't provide a function for it.
- NateDad 12y ago
  +1 this is exactly it.
- bsaul 12y ago
  I would agree, except for the fact that slices have a lot of very convenient sugar syntax, making it look like the de facto standard for storing anything (with maps that is). Well, i may be spoiled, but ever since i stopped working with C, i never had to deal with data structure so different between arrays and list than go (that is, slices and container/list). The performance concern is an absolute hypocrisies. Whenever you decide which structure you pick in eg, Java, you know that the various containers are optimized for various operation, and you decide which to use depending on performance only. In go the language is so broken (because of the type system) that using a chained list vs an array makes your code look completely different.
infogulch 12y ago
Seems you're looking for SliceTricks from the Go wiki: https://code.google.com/p/go-wiki/wiki/SliceTricks https://code.google.com/p/go-wiki/wiki/SliceTricks Actually there are multiple options for delete from a slice. If you need to preserve order then it's going to be an O(n) operation, and if you're deleting often maybe it shouldn't be a slice but some other structure. There are two options for delete mentioned in that document: Delete copy(a[i:], a[i+1:]) a[len(a)-1] = nil // or the zero value of T a = a[:len(a)-1] Delete without preserving order a[i], a[len(a)-1], a = a[len(a)-1], nil, a[:len(a)-1]

by bsaul 12y ago

ansible 12y ago

Come on... removing an item from a list requires tricks ?? That's not a list, it is a slice. Which is a slight abstraction over an array. You the programmer are directly responsible for the size of the slice storage, and how many elements it currently contains. I know go aims at being memory efficient, but delete(list,obj) should be idiomatic. If this ends up being a common operation, I could understand arguments to add it to the language. But in general if you are adding / removing items a lot, you'd be better off using an actual list data structure instead.

bsaul 12y ago
Then i guess we're back to generics. Having to use this interface : http://golang.org/pkg/container/list/ http://golang.org/pkg/container/list/ , with its "Element" wrapping a "Value" property of type interface{} seems really weird for such a basic need. It means that whenever you're storing an object into the list, you need to remember the element in addition to the original object to be able to remove it later...
- NateDad 12y ago
  Except that no one ever actually used that package. We just use normal slices which are generic.
  - bsaul 12y ago
    Hence my point... People use arrays like they would use ArrayList or Vector or any dynamic container created in the last 25 years and expect to be able to remove an object in one function call.
    - NateDad 12y ago
      And people use lists like they would an array and assume a list of 100 int64s uses 800 bytes, when it actually probably uses twice that much (if you're lucky).

scott_s 12y ago

I'm not a Go programmer, but I think this is a problem of data structure expectations. Slices are not "lists", but views into arrays. So, by design, slices are a view into contiguous chunks of values. In such structures, removing an item will necessarily be O(n). A general principle in interface design for data structures is don't make expensive things easy. So, if removal from a slice is O(n), then the data structure is obviously not optimized for that, so don't provide a function for it.

NateDad 12y ago
+1 this is exactly it.
bsaul 12y ago
I would agree, except for the fact that slices have a lot of very convenient sugar syntax, making it look like the de facto standard for storing anything (with maps that is). Well, i may be spoiled, but ever since i stopped working with C, i never had to deal with data structure so different between arrays and list than go (that is, slices and container/list). The performance concern is an absolute hypocrisies. Whenever you decide which structure you pick in eg, Java, you know that the various containers are optimized for various operation, and you decide which to use depending on performance only. In go the language is so broken (because of the type system) that using a chained list vs an array makes your code look completely different.

infogulch 12y ago

Seems you're looking for SliceTricks from the Go wiki: https://code.google.com/p/go-wiki/wiki/SliceTricks https://code.google.com/p/go-wiki/wiki/SliceTricks Actually there are multiple options for delete from a slice. If you need to preserve order then it's going to be an O(n) operation, and if you're deleting often maybe it shouldn't be a slice but some other structure. There are two options for delete mentioned in that document: Delete copy(a[i:], a[i+1:]) a[len(a)-1] = nil // or the zero value of T a = a[:len(a)-1] Delete without preserving order a[i], a[len(a)-1], a = a[len(a)-1], nil, a[:len(a)-1]