[go-nuts] Re: Why is there no standard `uuid` package?

[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


On Wednesday, February 7, 2018 at 5:43:08 PM UTC-8, 高橋誠二 wrote:
>
> 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?
>
>

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Why is there no standard `uuid` package?

[Sotirios Mantziaris]

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

On Friday, February 9, 2018 at 9:52:33 AM UTC+2, Henry wrote:
>
> @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. 

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Why is there no standard `uuid` package?

[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. 

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Why is there no standard `uuid` package?

['Axel Wagner' via golang-nuts]

On Fri, Feb 9, 2018 at 6:24 AM, Henry  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
> (--Mxxx-Nxxx-) 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+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Why is there no standard `uuid` package?

[高橋誠二]

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:
>
> 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. 

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Why is there no standard `uuid` package?

[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 
(--Mxxx-Nxxx-) 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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Why is there no standard `uuid` package?

[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. 

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Why is there no standard `uuid` package?

[高橋誠二]

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:
>
> 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. 

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Why is there no standard `uuid` package?

[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. 

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Why is there no standard `uuid` package?

[高橋誠二]

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:
>
> 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.

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Why is there no standard `uuid` package?

[Sotirios Mantziaris]

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

On Thursday, February 8, 2018 at 3:43:08 AM UTC+2, 高橋誠二 wrote:
>
> 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?
>
>

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.