uuid

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 [2] https://go.dev/pkg/uuid [3] https://github.com/kubernetes/kubernetes/blob/2220c3853a2402... [4] https://github.com/google/uuid/issues/221

I'm so glad the new uuid package landed - it's overdue but a very welcome addition! I've already replaced github.com/google/uuid with `uuid` in several projects

There have been committed 3 new features and a seemingly significant bug fix since the last release: https://github.com/google/uuid/compare/v1.6.0...HEAD If the library just existed as a correct implementation of the RFC without bugs or significant missing features, that would be one thing. But leaving features and bug fixes already committed to the repository unreleased for years because the maintainer hasn't cut a new release since 2024 is a bad sign.

While the uuid package is actively maintained, it hasn't had a release since 2024. Indeed, there's an open issue from June 2025 asking about it: https://github.com/google/uuid/issues/194

> You're not going to try and extract a timestamp from a uuid. So, random library: https://pkg.go.dev/github.com/google/uuid#UUID.Time > Time returns the time in 100s of nanoseconds since 15 Oct 1582 encoded in uuid. The time is only defined for version 1, 2, 6 and 7 UUIDs.

Good catch, you are correct. I initially was going post the actual command for checking out a branch at a time: > git checkout $(git rev-list -1 --before="YYYY-MM-DD" master) but thought I found a shortcut - which turns out is not really one, and like you said: confusing. I can't edit my post, but in any case; the point being: it would be nice if import statements are closer to "github.com/google/uuid@YYYY-MM-DD" or in this case you can pass a date to version: "YYYY-MM-DD" and the library would run the uglier nested command above to import the proper version.

> because interface{} is always counted as escaped from the stack Not quite - if the function accepting interface{} can be inlined (and other heuristics are groovy), then it won't escape. Trivial example but it applies to real-world programs: > cat main.go package main import "github.com/google/uuid" func main() { _ = foo(uuid.NewString()) } func foo(s any) string { switch s := s.(type) { case string: _ = "foo:" + s } return "" } # Build with escape analysis > go build -gcflags="-m=2" main.go # command-line-arguments ./main.go:9:6: can inline foo with cost 13 as: func(any) string { switch statement; return "" } ./main.go:5:6: can inline main with cost 77 as: func() { _ = foo(uuid.NewString())

> "UUID" was already taken by Google. This shouldn't really matter as your import paths are obviously different. `github.com/google/uuid` and `github.com/sdrapkin/guid` can happily coexist. Any file/codebase importing both (which would ideally be avoided in the first place) can alias them. > IMHO "Guid" is just as well known I think the point the commenter was trying to make is that these do not adhere to the UUID spec. You don't specify which version, but judging by the docs and your comparison to `github.com/google/uuid`, I'd wager most folks looking at this library would assume they are supposed to be V4 UUIDs.

Ah cool, the note here is also interesting: https://pkg.go.dev/github.com/google/uuid#EnableRandPool

Much faster (~10x) than standard github.com/google/uuid package I'm interested in feedback from the HN community.

> I have yet to come across a go project that doesn't pull in tons of 3rd party code as well. These have Zero dependencies. It's not rare in Go land. - https://github.com/go-chi/chi 19k stars - https://github.com/julienschmidt/httprouter 16k stars - https://github.com/gorilla/mux 21k stars - https://github.com/spf13/pflag 2.6k stars - https://github.com/google/uuid 5.6k starts Many others have just a few dependencies.

The constructor doesn't have to be private, it just has to be a constructor. For example take this library: https://github.com/google/uuid It represents UUIDs as `type UUID [16]byte`. It would be trivial to circumvent a constructor: `var uuid UUID`. Go values are zero initialized. (Aside: You might actually have a reason to do this, but often you would rather use https://pkg.go.dev/github.com/google/uuid#NullUUID). But it's obvious that you would use one of the constructors in the library to get an actual valid UUID.

Or maybe not. "google/uuid" tells you nothing about the owner. It might be Google, or it might be me, who squatted the name early on. "github.com/google/uuid" would be much difficult to squat. Also, it tells you that this comes from the Google user in GitHub, which is something much easier to verify. "code.google.com/go/UUID" would be even more of a guarantee. But I guess they decided relying on GitHub to host their Go packages was good enough.

The problem is people hardcoding github.com in their go files. https://www.digitalocean.com/community/tutorials/importing-p... >import "github.com/google/uuid" This should be just "google/uuid".