2 ms·

There are many examples of things builtins can do which user-code can't: 1. The constructs like "x <- chan" and "x, ok <- chan" (and map indexing and so on) ar

There are many examples of things builtins can do which user-code can't: 1. The constructs like "x <- chan" and "x, ok <- chan" (and map indexing and so on) are only available to builtin types. It's impossible to write a thing like "x, ok <- chan" where it either panics or doesn't depending on if the caller wanted two or one return values. 2. generic types, like 'map' and 'chan'. 3. 'len' can't be implemented for a user type, e.g. "len(myCustomWorkQueue)" doesn't work. 4. range working without going through weird hoops (like returning a channel and keeping a goroutine around to feed it) 5. Reserving large blocks of memory up front (e.g. as 'make' can do for slices and maps) in an efficient manner (e.g. make(myCustomWorkQueue, 0, 20) doesn't work)

tptacek 8y ago
You're talking about the language. He's talking about the standard library.
- quotemstr 8y ago
  We're both talking about both. The core of my complaint is that the language privileges parts of the standard library.
  - TheDong 8y ago
    > privileges parts of the standard library It really doesn't. Maps and channels are not part of the stdlib. They're part of the language, but not the library. Similarly, range is part of the language, not the stdlib. If the stdlib was privileged, "container/*" in it would be generic, but it's not.
    - quotemstr 8y ago
      All right, but my point stands. Maps and channels should be part of stdlib, and they should rely on primitives available to user code too.
      - tptacek 8y ago
        Maps and channels are not part of the standard library. How you know that is, you can replace the entire standard library, using none of it, and still be programming in Go with maps and channels.
        coldtea 8y ago
        Parent wrote "should be" not "are".
      - thefounder 8y ago
        Such primitives would bring a lot of complexity which is something Go tried to avoid. Consider that make, map, chan etc are just language features/specs just like int64, string, func, main etc
        quotemstr 8y ago
        Why should string be fundamental?
        tptacek 8y ago
        Nobody said it "should" be. It simply is, in Go, the language we're discussing. If you nerdsnipe an HN thread with an argument that there's no difference between a language, its runtime, and its standard library, people are going to pile on to point out that's not true.
      - sagichmal 8y ago
        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.

tptacek 8y ago

You're talking about the language. He's talking about the standard library.

quotemstr 8y ago
We're both talking about both. The core of my complaint is that the language privileges parts of the standard library.
- TheDong 8y ago
  > privileges parts of the standard library It really doesn't. Maps and channels are not part of the stdlib. They're part of the language, but not the library. Similarly, range is part of the language, not the stdlib. If the stdlib was privileged, "container/*" in it would be generic, but it's not.
  - quotemstr 8y ago
    All right, but my point stands. Maps and channels should be part of stdlib, and they should rely on primitives available to user code too.
    - tptacek 8y ago
      Maps and channels are not part of the standard library. How you know that is, you can replace the entire standard library, using none of it, and still be programming in Go with maps and channels.
      - coldtea 8y ago
        Parent wrote "should be" not "are".
    - thefounder 8y ago
      Such primitives would bring a lot of complexity which is something Go tried to avoid. Consider that make, map, chan etc are just language features/specs just like int64, string, func, main etc
      - quotemstr 8y ago
        Why should string be fundamental?
        tptacek 8y ago
        Nobody said it "should" be. It simply is, in Go, the language we're discussing. If you nerdsnipe an HN thread with an argument that there's no difference between a language, its runtime, and its standard library, people are going to pile on to point out that's not true.
    - sagichmal 8y ago
      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.