4 ms·

Brace for a wave of drive-by pull-requests swapping google/uuid [1] out for the now-standard uuid package [2]. Kubernetes project will be the first one [3] I g

Brace for a wave of drive-by pull-requests swapping google/uuid [1] out for the now-standard uuid package [2]. Kubernetes project will be the first one [3] I guarantee it. [1] https://pkg.go.dev/github.com/google/uuid https://pkg.go.dev/github.com/google/uuid [2] https://go.dev/pkg/uuid https://go.dev/pkg/uuid [3] https://github.com/kubernetes/kubernetes/blob/2220c3853a2402ffc0502995c49b383f84ae8ceb/go.mod#L36 https://github.com/kubernetes/kubernetes/blob/2220c3853a2402... [4] https://github.com/google/uuid/issues/221 https://github.com/google/uuid/issues/221

dabber21 2mo ago
will 'go fix' take care of this?
- qwm 1mo ago
  I don't think it ever suggests anything specific to 3rd-party packages
iaaan 2mo ago
Unfortunately for people SELECTing UUIDs out of a DB directly into a uuid struct, the built-in uuid structs don't implement the necessary interface for that, so you'll have to continue using the google package, or a plain string.
- reactordev 1mo ago
  Oooof… well played go team, well played.
- deepsun 1mo ago
  Or just a number (128-bit).
- agwa 1mo ago
  The database/sql package gained native support[1] for the uuid.UUID type so it will Just Work even without the methods. This probably should have been mentioned in the release notes and database/sql package docs. [1] https://cs.opensource.google/go/go/+/refs/tags/go1.27.0:src/database/sql/convert.go;l=270-280 https://cs.opensource.google/go/go/+/refs/tags/go1.27.0:src/...
  - semiquaver 1mo ago
    Doesn’t the type name uuid.UUID violate go’s style guide for type naming? I seem to recall a fairly specific prohibition on stutter-types.
    - coder543 1mo ago
      No. What else could it reasonably be named? Hard to imagine. The rule has always been intended to cover types that have another word in them but still choose to pointlessly repeat the package name. `uuid.UUIDGenerator` is a hypothetical example of the anti-pattern that would instead be better named as `uuid.Generator`.
      - whateveracct 1mo ago
        > No. What else could it reasonably be named? Hard to imagine. Ocaml often just has it be T so uuid.T
      - tomjakubowski 1mo ago
        uuid.Entifier
    - kbolino 1mo ago
      Repeating the package name is fine if it's exactly the same name (modulo capitalization) and there's nothing better to name the type anyway. The style issue would arise with e.g. uuid.UUIDVersion, which should just be named uuid.Version. There used to be a gopls lint that would flag names like uuid.UUID but it got relaxed awhile ago.
    - markusw 1mo ago
      Yeah, I would have gone with uuid.V4 or something. But oh well, as long as it works. :D
      - dolmen 1mo ago
        V4 or V7 are just how you initialize them (constructor), but then this the same representation, so they don't need specific types.
- ungerik 1mo ago
  uuid.UUID is implemented as [16]byte, like most other UUID implementations out there. If you want to keep your package implementation agnostic, use [16]byte as argument type; that's assignment-compatible with any other type that is such an array underneath: For an example, see the UUID logging of golog: https://pkg.go.dev/github.com/domonda/golog#Message.UUID https://pkg.go.dev/github.com/domonda/golog#Message.UUID

dabber21 2mo ago

will 'go fix' take care of this?

qwm 1mo ago
I don't think it ever suggests anything specific to 3rd-party packages

iaaan 2mo ago

Unfortunately for people SELECTing UUIDs out of a DB directly into a uuid struct, the built-in uuid structs don't implement the necessary interface for that, so you'll have to continue using the google package, or a plain string.

reactordev 1mo ago
Oooof… well played go team, well played.
deepsun 1mo ago
Or just a number (128-bit).
agwa 1mo ago
The database/sql package gained native support[1] for the uuid.UUID type so it will Just Work even without the methods. This probably should have been mentioned in the release notes and database/sql package docs. [1] https://cs.opensource.google/go/go/+/refs/tags/go1.27.0:src/database/sql/convert.go;l=270-280 https://cs.opensource.google/go/go/+/refs/tags/go1.27.0:src/...
- semiquaver 1mo ago
  Doesn’t the type name uuid.UUID violate go’s style guide for type naming? I seem to recall a fairly specific prohibition on stutter-types.
  - coder543 1mo ago
    No. What else could it reasonably be named? Hard to imagine. The rule has always been intended to cover types that have another word in them but still choose to pointlessly repeat the package name. `uuid.UUIDGenerator` is a hypothetical example of the anti-pattern that would instead be better named as `uuid.Generator`.
    - whateveracct 1mo ago
      > No. What else could it reasonably be named? Hard to imagine. Ocaml often just has it be T so uuid.T
    - tomjakubowski 1mo ago
      uuid.Entifier
  - kbolino 1mo ago
    Repeating the package name is fine if it's exactly the same name (modulo capitalization) and there's nothing better to name the type anyway. The style issue would arise with e.g. uuid.UUIDVersion, which should just be named uuid.Version. There used to be a gopls lint that would flag names like uuid.UUID but it got relaxed awhile ago.
  - markusw 1mo ago
    Yeah, I would have gone with uuid.V4 or something. But oh well, as long as it works. :D
    - dolmen 1mo ago
      V4 or V7 are just how you initialize them (constructor), but then this the same representation, so they don't need specific types.
ungerik 1mo ago
uuid.UUID is implemented as [16]byte, like most other UUID implementations out there. If you want to keep your package implementation agnostic, use [16]byte as argument type; that's assignment-compatible with any other type that is such an array underneath: For an example, see the UUID logging of golog: https://pkg.go.dev/github.com/domonda/golog#Message.UUID https://pkg.go.dev/github.com/domonda/golog#Message.UUID