On Fri, Feb 9, 2018 at 6:24 AM, Henry <henry.adisuma...@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+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.
