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:
>
> Recentl
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
@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
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, co
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 th
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
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 inp
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 fri
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 ben
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á
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 uns
11 matches
Mail list logo
