6 ms·

And make the standard library unmagical? One of the things I've always disliked about Go is how stdlib provides magic facilities unavailable to user code.

icholy 8y ago
What's magical about the stdlib?
- grey-area 8y ago
  Maybe they meant the language, which has some generic functions like append or delete - instead of those functions being attached to a data type or accepting any type, they only act on built-in types. I doubt any of that would change though given the stated goal of remaining compatible in most cases.
- SamWhited 8y ago
  There are a handful of packages (time and some stuff in os for example) that are tied into the runtime and can't be rewritten outside the standard library. It's not a huge amount, and some of it can probably be fixed in the future.
bradfitz 8y ago
I agree, but there's not much, and it's usually for decent reasons: * the "time" package hooks into the Go scheduler. * the "reflect" package needs type information out of the runtime. * the "net" package hooks into the Go scheduler a bit. But way less than it used to. I think you might even be able to do this all yourself outside of std nowadays. What else? Our rough plan going forward is to actually move a bunch of the stdlib elsewhere but ship copies/caches of tagged versions with Go releases. So maybe "encoding/json" is really an alias for "golang.org/std/encoding/json" and Go 1.13.0 ships with version 1.13.0 of golang.org/std/encoding/json. But if you need a fix, feature, or optimization sooner than 6 months when 1.14.0 comes out, you can update earlier.
- aleksi 8y ago
  My guess that quotemstr meant builtins: append, copy, range "protocol", etc.
- TheDong 8y ago
  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
deleted 8y ago
[deleted]

icholy 8y ago

What's magical about the stdlib?

grey-area 8y ago
Maybe they meant the language, which has some generic functions like append or delete - instead of those functions being attached to a data type or accepting any type, they only act on built-in types. I doubt any of that would change though given the stated goal of remaining compatible in most cases.
SamWhited 8y ago
There are a handful of packages (time and some stuff in os for example) that are tied into the runtime and can't be rewritten outside the standard library. It's not a huge amount, and some of it can probably be fixed in the future.

bradfitz 8y ago

I agree, but there's not much, and it's usually for decent reasons: * the "time" package hooks into the Go scheduler. * the "reflect" package needs type information out of the runtime. * the "net" package hooks into the Go scheduler a bit. But way less than it used to. I think you might even be able to do this all yourself outside of std nowadays. What else? Our rough plan going forward is to actually move a bunch of the stdlib elsewhere but ship copies/caches of tagged versions with Go releases. So maybe "encoding/json" is really an alias for "golang.org/std/encoding/json" and Go 1.13.0 ships with version 1.13.0 of golang.org/std/encoding/json. But if you need a fix, feature, or optimization sooner than 6 months when 1.14.0 comes out, you can update earlier.

aleksi 8y ago
My guess that quotemstr meant builtins: append, copy, range "protocol", etc.
TheDong 8y ago
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

deleted 8y ago

[deleted]