Why is there no standard `uuid` package?

[高橋誠二]

Recently satori/go.uuid took a breaking change of API, and some of frameworks which depend on the package.

And google/uuid is unstable.

Why Go doesn't have an official uuid package?

Is there any load map to develop google/uuid and merge it to Go itself?

[Tamás Gulácsi]

Because UUID is both vague (what format should it be stored? With- or without dashes? Where to split?) and over-engineered (host's mac address in the UUID? or use the full-random v4 ?).
For example I use github.com/oklog/ulid - shorter and time-sortable alternative.

[Sotirios Mantziaris]

i agree that there should be a std package version of uuid like in almost every other language.

[高橋誠二]

I agree UUID is vague but supplying "default" UUID generator on the standard package is significant.

If you'd like to use advanced ID generator, like snowflake, you can use that package.

The problem is there is no stable and de facto standard package of it.

2018年2月9日金曜日 3時17分38秒 UTC+9 Tamás Gulácsi:

[Dave Cheney]

But that’s the problem, who’s default uuid format is chosen? And how to justify this over the other users who want their default to be chosen.

The answer is as it currently stands, multiple uuid libraries exist outside the standard library.

Can you tell me, in concrete terms, what are the benefits to you of a (I’m going to assume the one that is compatible with your project) uuid implementation being included in the standard library.

[高橋誠二]

Thanks you for the opinion.

My colleagues are using satori/go.uuid, with web framework, "goa".

API breaking change broke that package and our team had trouble for versioning.

https://github.com/satori/go.uuid/issues/66

I know it is not the problem of the code of uuid generation itself,

but my friends in other companies also had the same problem,

or they create an original generator.

it is just the reinventing the wheel so I asked why go has no standard uuid package.

it's sure that defining the default format, but except for large-scaled system,

generally you can be satisfied with a plain "securerandom" string, can't you?

2018年2月9日金曜日 11時10分52秒 UTC+9 Dave Cheney:

[Dave Cheney]

Your argument that the stdlib grows a uuid package is really a call for stability. “3rd parties cannot provide us the stability we need, so the go team must”. I don’t think that is a fair expectation on the go team, especially as there is no clear standard for what a uuid is (having multiple inplemebtations pushes the discussion into the domain of the python standard library).

I think your problems would be best solved by forking the uuid library at a revision that works for you, or sponsoring the development of a sufficiently stable uuid library. There is clearly a market for one.

[Henry]

I don't think UUID representation (whether with dash or without dash or how many dashes) is a strong argument for not including UUID into Go's stdlib. You can expose it in byte array, provide the default implementation for its string representation, and let the users work with the byte array if they need a custom string representation. By the way, the RFC did define the standard UUID string representation which is in the form of 8-4-4-4-12 (xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx) that you can use as the default UUID string representation.

That being said. It is also fairly trivial to implement your own UUID library. It takes a bit of reading to ensure your implementation conforms to the RFC. I know because I ended up implementing my own UUID library because there weren't such libraries back then. 

[高橋誠二]

It's very reasonable, and as an actual decision, we fork that lib.

I understood that a stability of library is not so problem.

However, as Henry says, default UUID specification is defined on RFC.

Implementing it is useful, isn't it?

2018年2月9日金曜日 12時28分16秒 UTC+9 Dave Cheney:

[Axel Wagner]

On Fri, Feb 9, 2018 at 6:24 AM, Henry <henry.ad...@gmail.com> wrote:

I don't think UUID representation (whether with dash or without dash or how many dashes) is a strong argument for not including UUID into Go's stdlib.

Then how about the bigger problem: Semantics. There are tradeoffs of throughput, latency, collision-resistance, time-sortability, density… and what the correct tradeoff is depends heavily on the workload.

All of these qualify as "UUIDs" that might or might not be useful depending on the workload:

* Centralized counter

* Combination of Node-ID and current time

* Combination of Node-ID and random number

* Combination of Node-ID, random number and current-time

* Random Number

In some workloads, time-sortable dense UUIDs are a good thing (e.g. log-entries, where you will ~always read and write continuous ranges), in some they are a bad thing (e.g. event-traces, where you will mostly read and write random single entries and avoid hotspotting). Some workloads can deal with a small probability of global collisions, as long as locally the ids are sufficiently unique, some can't. Some workloads will have access to the current time/system properties like a MAC/a central server, some won't…

The proliferation of UUID Go-packages should show you, that there are a variety of different semantics that people want supported - settling on a single one will be next to impossible.

 

You can expose it in byte array, provide the default implementation for its string representation, and let the users work with the byte array if they need a custom string representation. By the way, the RFC did define the standard UUID string representation which is in the form of 8-4-4-4-12 (xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx) that you can use as the default UUID string representation.

That being said. It is also fairly trivial to implement your own UUID library. It takes a bit of reading to ensure your implementation conforms to the RFC. I know because I ended up implementing my own UUID library because there weren't such libraries back then. 

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Henry]

@axel: The specification for UUID is defined in RFC 4122. You are free to use it or create your own variants. However, the specs is there.

[Sotirios Mantziaris]

i agree that since there exist a RFC it should not be that much of a problem. 

[as]

Probably because UUIDv4 is the most common type and is trivial to approximate. For other requirements, there are non-RFC conformant implementations that achieve the desired properties

https://github.com/segmentio/ksuid