31 ms·

> maps.SortedByKeys thats what you call overfitting kids

by 38 2y ago

kbolino 2y ago
Whatever you think the best name for it is, it's still missing from the library.
- 38 2y ago
  the point is you dont need it. by your own admission, it would save literally 0 lines of code from your current example. you need discipline when adding sugar otherwise you can ruin a language.
  - kbolino 2y ago
    I said no such thing. First, it would save one line of code (v := m[k]). Second, it would also allow an optimization. When iterating a map directly, you have both the key and the value at the same time. However, since we iterate only the keys here, we then have to look up the value anew for each key. That takes extra time and, for large maps, will thrash the CPU cache. So the following would be both fewer lines of code and faster: for k, v := range maps.Sorted(m) { // do something with k and v } Making common operations clear and concise is not mere sugar in my opinion. It not only improves the developer experience, it also clarifies the developer's intent, which enables better optimizations, and allows bugs and traps to be addressed in one place, instead of languishing in far-flung places.
- jerf 2y ago
  I think the problem with putting this into the standard library is that while Go may not be super focused on absolutely top-tier performance, it does generally try to avoid offering things that are unexpectedly slow or unexpectedly allocate large things. A sort-by-keys on the standard map would require allocating a full slice for the keys in the sort routine to do the sort, which would surprise people who expect build-in iterators to not immediately do that. Plus it's in the class of things that's pretty easy to implement yourself now. There's always a huge supply of "but the library could just compose these two things for me". If you stick them all in things get bloated. You could literally have written it in the time it took to write the complaint. You got 80% of the way there as it is, I just tweaked your code a bit to turn it into an iterator: https://go.dev/play/p/agBGl_rT7XS https://go.dev/play/p/agBGl_rT7XS
  - 38 2y ago
    its completely pointless to make this an iterator, because you have to loop the entire map to do so, which kills any benefit of using iterators
    - kbolino 2y ago
      And yet slices.Sorted was added which does exactly this already, but only for single-valued iterators.
      - deleted 2y ago
        [deleted]
      - randomdata 2y ago
        > And yet slices.Sorted was added which does exactly this already It does not. slices.Sorted accepts an iterator, but returns a slice. Like the earlier comments point out, Go tries its best to give a reasonable idea of what kind of complexity is involved at the API level. slices.Sorted returning an iterator would mask that. By returning a slice, it makes clear that the entire collection of data needs to be first iterated over as the parent described.
        kbolino 2y ago
        This is a good point which likely explains why maps.Sorted doesn't exist (yet): what would it even return? I think returning an iterator is acceptable, the docs could explain the expense of the operation, and the implementation could change in the future as needed. But that does hide some complexity. If it ought to return a slice of entries, that opens up new problems. What is an entry? A two-member generic struct? Ok, fine, but then how do I ergonomically iterate over them, pulling out both members? There's no clear solution to that problem yet.
        randomdata 2y ago
        There is another, perhaps more important, reason: If you need sorted keys, the map is almost certainly the wrong data structure. Sure, there may be some edge case situations, like where you are dealing with someone else's code where you don't have control over the structures you've been given, but: 1. The standard library doesn't appeal to edge cases. 2. The "noiser" solutions to deal with the edge case serve as a reminder that you aren't working in the optimal space.

> maps.SortedByKeys thats what you call overfitting kids

by 38 2y ago

> maps.SortedByKeys thats what you call overfitting kids

kbolino 2y ago

Whatever you think the best name for it is, it's still missing from the library.

38 2y ago
the point is you dont need it. by your own admission, it would save literally 0 lines of code from your current example. you need discipline when adding sugar otherwise you can ruin a language.
- kbolino 2y ago
  I said no such thing. First, it would save one line of code (v := m[k]). Second, it would also allow an optimization. When iterating a map directly, you have both the key and the value at the same time. However, since we iterate only the keys here, we then have to look up the value anew for each key. That takes extra time and, for large maps, will thrash the CPU cache. So the following would be both fewer lines of code and faster: for k, v := range maps.Sorted(m) { // do something with k and v } Making common operations clear and concise is not mere sugar in my opinion. It not only improves the developer experience, it also clarifies the developer's intent, which enables better optimizations, and allows bugs and traps to be addressed in one place, instead of languishing in far-flung places.
jerf 2y ago
I think the problem with putting this into the standard library is that while Go may not be super focused on absolutely top-tier performance, it does generally try to avoid offering things that are unexpectedly slow or unexpectedly allocate large things. A sort-by-keys on the standard map would require allocating a full slice for the keys in the sort routine to do the sort, which would surprise people who expect build-in iterators to not immediately do that. Plus it's in the class of things that's pretty easy to implement yourself now. There's always a huge supply of "but the library could just compose these two things for me". If you stick them all in things get bloated. You could literally have written it in the time it took to write the complaint. You got 80% of the way there as it is, I just tweaked your code a bit to turn it into an iterator: https://go.dev/play/p/agBGl_rT7XS https://go.dev/play/p/agBGl_rT7XS
- 38 2y ago
  its completely pointless to make this an iterator, because you have to loop the entire map to do so, which kills any benefit of using iterators
  - kbolino 2y ago
    And yet slices.Sorted was added which does exactly this already, but only for single-valued iterators.
    - deleted 2y ago
      [deleted]
    - randomdata 2y ago
      > And yet slices.Sorted was added which does exactly this already It does not. slices.Sorted accepts an iterator, but returns a slice. Like the earlier comments point out, Go tries its best to give a reasonable idea of what kind of complexity is involved at the API level. slices.Sorted returning an iterator would mask that. By returning a slice, it makes clear that the entire collection of data needs to be first iterated over as the parent described.
      - kbolino 2y ago
        This is a good point which likely explains why maps.Sorted doesn't exist (yet): what would it even return? I think returning an iterator is acceptable, the docs could explain the expense of the operation, and the implementation could change in the future as needed. But that does hide some complexity. If it ought to return a slice of entries, that opens up new problems. What is an entry? A two-member generic struct? Ok, fine, but then how do I ergonomically iterate over them, pulling out both members? There's no clear solution to that problem yet.
        randomdata 2y ago
        There is another, perhaps more important, reason: If you need sorted keys, the map is almost certainly the wrong data structure. Sure, there may be some edge case situations, like where you are dealing with someone else's code where you don't have control over the structures you've been given, but: 1. The standard library doesn't appeal to edge cases. 2. The "noiser" solutions to deal with the edge case serve as a reminder that you aren't working in the optimal space.