[thedufer]

"no chance of collisions" can't be applicable to any finite-length ID. Low chance, perhaps.

That said, this appears to be exactly the scheme MongoDB uses (except Mongo IDs are 96 bits).

[JoeAltmaier]

Ok, Less likely than the chance your computer will spontaneously catch fire while running your code. Less likely than the chance the sun will emit a colossal solar flare and engulf the earth in a firey death.

[thedufer]

Right, but that's the point of a GUID. Claiming no chance makes it sound like its distinct from other GUID generators in that way. I think the intended claim is "here is a scheme for roughly timestamp-ordered GUIDs", which makes it clear that the timestamp-ordering is the interesting part.

[Goopplesoft]

Actually it can. As long as they aren't randomly generated. UUID4s are random, lots of them including the mongodb use a timestamp/mac address as the first n bits of the guid. Not sure whether they have "no chance of collisions" but it is very possible.

[gohrt]

"no chance" means making a claim that there will never be 2^N devices generating IDs simultaneously (for N somewhere around 30-60)

2 machines can have the same MAC addresses (they are reprogrammable) and can operate at the same microsecond.

"aren't randomly generated" is not practical constraint in a high-speed distributed system (where you don't have time for synchronization overhead).

[Goopplesoft]

Its an infinitesimally small chance. You'd need a mac collision, must be generated at the same time, and a uuid collision. Even at the largest scales (Google et all) the probability of that happening is effectively 0.

[malka]

Yes. And my glass of water could spontaneously turn into ice. However, I do not expect it to happen anytime soon.

[thedufer]

Please, generate 2^<length>+1 of them and let me know how it goes.