3 ms·

The problems with the API they point out are almost all things that rust's ownership system was built to solve. Things like: slices.Sort(s) // correct

The problems with the API they point out are almost all things that rust's ownership system was built to solve. Things like: slices.Sort(s) // correct slices.Compact(s) // incorrect slices.Delete(s, ...) // incorrect s := slices.Delete(s, ...) // incorrect if 's' is referenced again in the outer scope s = slices.Delete(s, ...) // correct All of those are solved by having functions like 'slices.Sort' take a '&mut' reference in rust speak, and having 'slices.Compact' and 'Delete' take an owned slice, and return a new owned slice.

lifthrasiir 3y ago
You don't even need a notion of ownership. A distinction between an immutable and mutable slice should be enough, because an immutable slice can never be changed which implies that its excess capacity (if any) can't be exploited for optimization.
- tsimionescu 3y ago
  None of these functions would apply to an immutable slice, so how is it related?
  - lifthrasiir 3y ago
    If immutable and mutable slices are differently typed [2], it is natural to define two functions (say, `slices.Compact` vs. `slices.Compacted`) to handle each type, like Python `list.sort` vs. `sorted`. It should be natural to expect `slices.Compacted` to never alter its input, and any attempt to use a mutable version will be very explicit except for slicing [1]. [1] Especially given that the capacity is preserved by default, which contributes to the current confusion. See my older comment: https://news.ycombinator.com/item?id=39112735 https://news.ycombinator.com/item?id=39112735 [2] Originally "...are different" but edited for clarity.
    - ikiris 3y ago
      This sounds awful in practice having to memorize different functions for the same thing based on mutability of the thing.
      - ttymck 3y ago
        In practice it's not that bad
      - shakow 3y ago
        Programming is hard and one can not destroy complexity, only move it; other news at 12.
    - makapuf 3y ago
      This would not allow the previous errors to be checked by the compiler since the main thing you're relying on is the name. Nothing prevents you to call deleted(mutable) and discard the result apart from the name.
      - comex 3y ago
        Indeed. Though, Rust does have a way to mark a function such that any caller that implicitly discards its return value gets a compiler warning. This feature largely solves the problem you’re talking about. But it’s orthogonal to Rust’s borrowing system or mutable versus immutable distinction. That said, I’d also point out that, while you can more or less replicate the Go example with Rust slices, in Rust it would be more idiomatic to pass around a Vec (or a mutable reference to a Vec) if a callee needs to do something like change the length. And you can’t resize a Vec if there are other references to its contents.
        ReleaseCandidat 3y ago
        `#[must_use]`. I really don't know why Rust made that error.
        3y ago
- DinaCoder99 3y ago
  You'd need three types: immutable slice of an immutable array, mutable slice of a mutable array (ie basically a reference to a mutable array), and an immutable slice of a mutable array.
masklinn 3y ago
Long before that, the problems with the API are solved by having a separate heap type for length manipulations rather than confusing the interfaces. If Delete or Compact are only available there and it’s modified in place, the problems don’t arise in the first place.
shakow 3y ago
IMHO, all these comes from the million dollar mistake that Go made from the very beginning, with slices being a bastard between both an owned and non-owned data container. Indeed, any function accepting a slice may simply use it as an immutable view on whatever data it needs, or modify it, potentially re-alloc it, and wreak havoc by invalidating all previous references to it and/or its elements. And God forbid you passed a subslice to such a function, you're in for a nasty surprise. Even without going the whole 9 yards of the Rust memory model, something like the views in C++, or the java {Array,Linked}Lists containing references to objects and thus being resistant to re-alloc, or even plainly immutable list like in OCaml are all working and simple enough solutions to the issue. I still can't wrap my mind around how supposedly experienced people like Pike & co. may have designed slices, then went ‶yep, that makes perfect sense for a robust, basic, widely used data structure to create our language around″, outside of a few toy programs.
- bsaul 3y ago
  my feeling with slices is that go wanted to really make programmers mindful of the cost of allocating new space on array operations. By having this weird API on slices, they force you to be explicit on allocating new memory.
  - masklinn 3y ago
    None of that makes any sense. Slices don't force you to be explicit on allocating new memory in any way. you can literally do this: s := []int{} for i := range 29754 { s = append(s, i) } do you see explicit allocation of new memory? As far as I'm concerned that's not in any way more explicit than e.g. var s = new List(); foreach(var i in Enumerable.Range(0, 29754)) { s.Add(i); }
    - bsaul 3y ago
      s = append(s,i) makes you realize something happened to the memory behind s. Otherwise you would simply call s.append(i)

lifthrasiir 3y ago

You don't even need a notion of ownership. A distinction between an immutable and mutable slice should be enough, because an immutable slice can never be changed which implies that its excess capacity (if any) can't be exploited for optimization.

tsimionescu 3y ago
None of these functions would apply to an immutable slice, so how is it related?
- lifthrasiir 3y ago
  If immutable and mutable slices are differently typed [2], it is natural to define two functions (say, `slices.Compact` vs. `slices.Compacted`) to handle each type, like Python `list.sort` vs. `sorted`. It should be natural to expect `slices.Compacted` to never alter its input, and any attempt to use a mutable version will be very explicit except for slicing [1]. [1] Especially given that the capacity is preserved by default, which contributes to the current confusion. See my older comment: https://news.ycombinator.com/item?id=39112735 https://news.ycombinator.com/item?id=39112735 [2] Originally "...are different" but edited for clarity.
  - ikiris 3y ago
    This sounds awful in practice having to memorize different functions for the same thing based on mutability of the thing.
    - ttymck 3y ago
      In practice it's not that bad
    - shakow 3y ago
      Programming is hard and one can not destroy complexity, only move it; other news at 12.
  - makapuf 3y ago
    This would not allow the previous errors to be checked by the compiler since the main thing you're relying on is the name. Nothing prevents you to call deleted(mutable) and discard the result apart from the name.
    - comex 3y ago
      Indeed. Though, Rust does have a way to mark a function such that any caller that implicitly discards its return value gets a compiler warning. This feature largely solves the problem you’re talking about. But it’s orthogonal to Rust’s borrowing system or mutable versus immutable distinction. That said, I’d also point out that, while you can more or less replicate the Go example with Rust slices, in Rust it would be more idiomatic to pass around a Vec (or a mutable reference to a Vec) if a callee needs to do something like change the length. And you can’t resize a Vec if there are other references to its contents.
      - ReleaseCandidat 3y ago
        `#[must_use]`. I really don't know why Rust made that error.
        3y ago
DinaCoder99 3y ago
You'd need three types: immutable slice of an immutable array, mutable slice of a mutable array (ie basically a reference to a mutable array), and an immutable slice of a mutable array.

masklinn 3y ago

Long before that, the problems with the API are solved by having a separate heap type for length manipulations rather than confusing the interfaces. If Delete or Compact are only available there and it’s modified in place, the problems don’t arise in the first place.

shakow 3y ago

IMHO, all these comes from the million dollar mistake that Go made from the very beginning, with slices being a bastard between both an owned and non-owned data container. Indeed, any function accepting a slice may simply use it as an immutable view on whatever data it needs, or modify it, potentially re-alloc it, and wreak havoc by invalidating all previous references to it and/or its elements. And God forbid you passed a subslice to such a function, you're in for a nasty surprise. Even without going the whole 9 yards of the Rust memory model, something like the views in C++, or the java {Array,Linked}Lists containing references to objects and thus being resistant to re-alloc, or even plainly immutable list like in OCaml are all working and simple enough solutions to the issue. I still can't wrap my mind around how supposedly experienced people like Pike & co. may have designed slices, then went ‶yep, that makes perfect sense for a robust, basic, widely used data structure to create our language around″, outside of a few toy programs.

bsaul 3y ago
my feeling with slices is that go wanted to really make programmers mindful of the cost of allocating new space on array operations. By having this weird API on slices, they force you to be explicit on allocating new memory.
- masklinn 3y ago
  None of that makes any sense. Slices don't force you to be explicit on allocating new memory in any way. you can literally do this: s := []int{} for i := range 29754 { s = append(s, i) } do you see explicit allocation of new memory? As far as I'm concerned that's not in any way more explicit than e.g. var s = new List(); foreach(var i in Enumerable.Range(0, 29754)) { s.Add(i); }
  - bsaul 3y ago
    s = append(s,i) makes you realize something happened to the memory behind s. Otherwise you would simply call s.append(i)