3 ms·

Could, sure. Should? I think you are asserting facts that are not in evidence.

uryga 8y ago
I'm a bit confused, and I'd like to understand your position better. I can see why arrays, structs/tuples, or [tagged] unions are usually primitives – they sort of express different fundamental layouts of data in memory, so they need support from the runtime/compiler. In the case of Go, channels also make sense as a primitive – as I understand it, `select` requires scheduler support. But higher level data structures like lists, sets, maps etc. are all implemented using those primitives under the hood. So, especially in a "systems language", I would sort of expect them to just be libraries in the stdlib, not language features[1]. But if you think otherwise (or see a gap in my reasoning) I'd love to hear why! [1] Except maybe some syntactic sugar for list/dict/set literals.
- TheDong 8y ago
  > But higher level data structures like lists, sets, maps etc. are all implemented using those primitives under the hood In Go you don't have generics as a primitive with which to build those things. As a result, you don't have the building blocks for anyone to build a usable data structure unless it's baked into the core of the language.
  - uryga 8y ago
    I'm aware of that, and I read the generics proposal linked. I commented here because I wanted to respond to this: > Should [be just libraries]? I think you are asserting facts that are not in evidence. I tried to describe why I feel that go's collections should be libraries and not builtins, and hopefully understand why GP seemed like they were questioning that idea.
- sagichmal 8y ago
  "Should" implies some normative assignment of value. > But higher level data structures like lists, sets, maps etc. are all implemented using those primitives under the hood. So, especially in a "systems language", I would sort of expect them to just be libraries in the stdlib, not language features[1]. Maybe! But if those higher order structures are closer to language features than libraries -- and, specifically to this conversation, if they leverage parts of the runtime that aren't available to mere mortals -- is it a strictly worse outcome? I don't know. Some evidence might suggest yes. But I think it's at best arguable.
  - uryga 8y ago
    I think I understand, thanks for explaining.

I'm a bit confused, and I'd like to understand your position better. I can see why arrays, structs/tuples, or [tagged] unions are usually primitives – they sort of express different fundamental layouts of data in memory, so they need support from the runtime/compiler. In the case of Go, channels also make sense as a primitive – as I understand it, `select` requires scheduler support. But higher level data structures like lists, sets, maps etc. are all implemented using those primitives under the hood. So, especially in a "systems language", I would sort of expect them to just be libraries in the stdlib, not language features[1]. But if you think otherwise (or see a gap in my reasoning) I'd love to hear why! [1] Except maybe some syntactic sugar for list/dict/set literals.

TheDong 8y ago
> But higher level data structures like lists, sets, maps etc. are all implemented using those primitives under the hood In Go you don't have generics as a primitive with which to build those things. As a result, you don't have the building blocks for anyone to build a usable data structure unless it's baked into the core of the language.
- uryga 8y ago
  I'm aware of that, and I read the generics proposal linked. I commented here because I wanted to respond to this: > Should [be just libraries]? I think you are asserting facts that are not in evidence. I tried to describe why I feel that go's collections should be libraries and not builtins, and hopefully understand why GP seemed like they were questioning that idea.
sagichmal 8y ago
"Should" implies some normative assignment of value. > But higher level data structures like lists, sets, maps etc. are all implemented using those primitives under the hood. So, especially in a "systems language", I would sort of expect them to just be libraries in the stdlib, not language features[1]. Maybe! But if those higher order structures are closer to language features than libraries -- and, specifically to this conversation, if they leverage parts of the runtime that aren't available to mere mortals -- is it a strictly worse outcome? I don't know. Some evidence might suggest yes. But I think it's at best arguable.
- uryga 8y ago
  I think I understand, thanks for explaining.