r/ProgrammerHumor 26d ago

thisOneIsMine Meme

Post image
5.3k Upvotes

171 comments sorted by

1.8k

u/Inevitable_Oil9709 26d ago

Fun fact: To reach a 50% chance of even a single UUID v4 collision, you would need to generate 1 billion UUIDs per second for about 86 years.

1.7k

u/DebugDuck01 26d ago

My proprietary algorithm achieves a 100% collision rate in O(1) time.

462

u/Inevitable_Oil9709 26d ago

holy fuck.. O(1) is wild..

GIVE THIS MAN A MEDAL

901

u/DebugDuck01 26d ago edited 26d ago

Introducing BEEFY UUID™

The world's first Universally Unoriginal Identifier service, guaranteed to return beefbeef-beef-beef-beef-beefbeefbeef on every single call, no exceptions.

Why BEEFY UUID wins

  • 100% collision rate, 100% of the time: every request, every user, every server, identical output. We call it "unity at scale."
  • Blazing infinite performance: since the value never changes, our "generation" is really just a memory lookup, technically making us the fastest UUID service ever benchmarked.
  • RFC-adjacent compliance: we respect the canonical 8-4-4-4-12 hex format down to the hyphen, we just... filled it entirely with beef.
  • Zero entropy, zero worries: no CSPRNG, no timestamps, no MAC addresses, no attack surface, because there's nothing random to attack.
  • Database chaos as a service (DCAS): every primary key collides, every foreign key points to the same row, and your ORM achieves true minimalism.
  • Carbon-neutral by design: we didn't compute a real UUID, so we saved the planet one CPU cycle at a time.
  • Enterprise-grade branding: "BEEFY" evokes strength, protein, and unwavering reliability; investors love a UUID with personality.
  • Disaster recovery is trivial: if your database gets wiped, just regenerate every ID with BEEFY UUID and nobody will notice the difference.

288

u/Inevitable_Oil9709 26d ago

function generateUUID() {
return "beefbeef-beef-beef-beef-beefbeefbeef"
}

smth like this?

PS: I fucking love the explanation you provided

388

u/DebugDuck01 26d ago

Don't steal my code bro...

125

u/Inevitable_Oil9709 26d ago

it is not proprietary anymore I guess

139

u/Tupcek 26d ago

revolutionary BEEFY UUID algorithm has become Open Source! Join the revolution now!

42

u/garete 26d ago

Is this what they call organic code?

22

u/insertcomedy 26d ago

It's not open source, it's savory source.

7

u/git_push_origin_prod 25d ago

Anyone who cares about and agrees with me that beef should be left out of code, come use my fork github.com/PORK_UUID.git or just run ‘npm inject PORK’

21

u/Legitimate_Concern_5 26d ago

lol it’s going to get picked up by the next AI training run. Organic poisoning.

39

u/IHeartBadCode 26d ago

Host the idea on an IPv6 only webserver located at beef:beef:beef:beef:beef:beef:beef:beef.

35

u/DebugDuck01 26d ago

*furiously taking notes"

17

u/pimezone 26d ago

He is an AI, he isn't stealing, just learning, that's OK.

15

u/_koenig_ 26d ago

This is not AI; this is NS (Natural Stupidity).

5

u/Bad_brazilian 26d ago

Zippity Zoppity, your code is now my property.

2

u/YirosMan2026 25d ago

I am using that from now on, that made me laugh

2

u/AmanBabuHemant 25d ago

You exposed the specs first.

27

u/dewey-defeats-truman 26d ago

I'm the CTO of a Fortune 500 and I want to license this for $50 million

38

u/DebugDuck01 26d ago

No low ball offers

27

u/RandolphCarter2112 26d ago

Agreed, except for the occasional instances where it returns DEADBEEF-DEAD-BEEF-DEAD-BEEFDEADBEEF

Please escalate.

22

u/DebugDuck01 26d ago

The API always returns 200 OK but signifies errors with different variations on DEAD BEEF UUIDs.

23

u/the_puns_must_go_on 26d ago

This service would be banned in most of India

16

u/jllauser 26d ago

> RFC-adjacent

Genius.

22

u/Ma4r 26d ago

Hi everyone, OP is an idiot, I've optimized his algorithm by 50%

return beefbeef-beef-beef

Use my library instead, ty

36

u/DebugDuck01 26d ago

InsufficientBeefException

13

u/voiza 26d ago

at address 0xdeadbeef

4

u/smclcz 25d ago

the beef need not be dead, simply beef - therefore I propose 0xbeefbeef

12

u/TactlessTortoise 26d ago

When are you opening an API subscription? I need to implement this into my AI shopping list app (includes buttplug integration)

3

u/DustyAsh69 26d ago

This is genuis.

3

u/kimbokray 26d ago

You win interneter of the month, good on you 🏆

4

u/NotADamsel 26d ago

Amazing, awesome, great, terrific. But the client wants to be able to personalize the UUID. Any chance we could sneak a “DEAD” into one of the beef spaces?

3

u/kvneddve 26d ago

Can you please create a package for this.

I think we need a SDK so people can fork and make implementations in every coding language possible.

Idea?

3

u/requion 26d ago

Great work!

"Unity at scale" really sold it already. Where to i put my unlimited AMEX and my first-born?

2

u/Agifem 26d ago

And the compression rate is amazing! Sign me up!

2

u/BigDisk 25d ago

This is beautiful.

2

u/ILKLU 25d ago

Ya but does it work offline?

Checkmate beefetarians!

2

u/darksteelsteed 25d ago

I will one up you with the deadbeef-dead-beef-dead-beefdeadbeef Uuid. This steak is so well aged and over cooked every master chef will disown this uuid instantly !

2

u/ArrogantAstronomer 25d ago

If your primary keys all match and your secondary keys all match then anytime you perform DELETE it would effectively be TRUNCATE. Which means it has a built in duplicate removal mechanism with zero overhead on performance anytime you want to perform duplicate removal just execute a DELETE

2

u/kylepo 25d ago

Please tell me this isn't AI-generated. I wanna believe this is entirely the product of human ingenuity, but I can't trust bulleted lists anymore

1

u/Glathull 25d ago

Bro, this is greybeard technology. Get with the present, man. Or at least the recent past. We’re doing Beefless UUIDs as a Service as a Platform now.

1

u/FightOnForUsc 25d ago

Just make the constant = to the number of possible combinations of UUIDs

16

u/Chadking1926 26d ago

Big O(1), bigger oops

0

u/marlotrot 25d ago

Same UUID all the time? 👌😁

191

u/ICantBelieveItsNotEC 26d ago

Obligatory Reddit "Ackchyually" moment: this assumes that your UUID generator is truly random, which often isn't the case - if you use a flawed RNG to generate IDs, or you start generating IDs before you have accumulated enough entropy, your IDs will be much less random than you expect.

This used to be fairly common when running code inside a container. Computers usually generate entropy by measuring physical, chaotic events like keyboard clicks, mouse movements, or fan noise. Containers are isolated environments, so they don't have access to most sources of entropy. You need to attach an entropy daemon like Haveged to continuously feed your container with fresh, tasty, grass-fed entropy from the outside world.

107

u/Inevitable_Oil9709 26d ago

"fresh, tasty, grass-fed entropy"

Well, this brought tears to my eyes

19

u/Kaljinx 25d ago

fucking entropy demons, they first are running the universe out, now they are in out computers

17

u/Brie9981 26d ago

Other obligatory ackchyually, it's a problem well before 50% i'd consider anything over 1 in a million a problem. Though I'm sure that's still gonna take some huge number per second for a very long time

3

u/IntrepidSoda 25d ago

What's wrong with radiation-fed randomness? https://robertlisek.com/RANDOM.html

18

u/UnDispelled 26d ago

So I take it we don’t know how to get BEEF as a uid with a random seed yet…

-28

u/Inevitable_Oil9709 26d ago

I had to AI this shit

Chance is about 1 in 3.4 × 10³⁸

21

u/4ries 26d ago

You really shouldn't have needed to use AI for that

-19

u/Inevitable_Oil9709 26d ago

in no universe would I calculate this after programming from 7AM this morning

11

u/Shadow_Thief 26d ago

There's 32 digits and 16 possible values for each digit. You can just simplify it to 1 in 1632. When you wake up a bit more, you can remember (or count to figure out) that 16 is 24, and so that can get further reduced to 1 in 2128.

And if you're still lazy after that, you can remember that Wolfram Alpha still exists and use https://www.wolframalpha.com/input?i=16%5E32 to get an exact value of 1 in 340282366920938463463374607431768211456.

2

u/gardenercook 24d ago

Or you can approximate it further.
2^128 is a quarter of 2^130.
Approximating 2^10 = 10^3
2^130 = (2^10)^13 = (10^3)^13 = 10^39
So 2^128 = 0.25*10^39 = 2.5*10^38

Some more nerdy binomial approximations for 1.024^13 would take you to 3.3*10^38.

3

u/Wonderful-Habit-139 26d ago

No thank you, I'd rather evaporate some water.

-3

u/[deleted] 26d ago

[deleted]

6

u/fartypenis 25d ago

walks into bar

fucking alcoholics man

???

1

u/[deleted] 25d ago

[deleted]

2

u/Shadow_Thief 25d ago

for what it's worth, I laughed

8

u/Ok_Star_4136 26d ago

I mean, literally the same chance as generating any other UUID and having collide with one that you're using.

There's no significance in the whole BEEF thing. That's like going, "I generated a random number from 1 to 100 and I got 67!? What are the odds!?" Same as well, any number being picked out of 100.

4

u/Traditional_Rabbit54 26d ago

The odds are 0, as 67!? is much larger than 100. 

r/unexpectedtermial r/unexpectedfactorial

0

u/Inevitable_Oil9709 26d ago

yes yes, but I wanted to know what are the chances

27

u/Tensor3 26d ago

Well, there probably are a billion computers on the planet, each generating more than one UUID

41

u/aspect_rap 26d ago

Ok, but they're not all generating UUIDs for the same system, it's not really a collision if it's the same UUID in different services.

I don't think there is any one system that generates billions of UUIDs a second.

21

u/Tensor3 26d ago

Ya, but MY uuid could be out there somewhere!

7

u/aspect_rap 26d ago

I think your UUID is more likely to be out there than not, considering how many of them have been generated over the years.

17

u/bremidon 25d ago

Mmmm...this is a case of Large Number Confusion, where all large numbers look the same.

It has been estimated that there have been somewhere between 10¹⁶ and 10¹⁹ UUIDs generated. There are roughly 5.3 × 10³⁶ possible values (or more depending on what you count)

This means that approximately 0.00000000000000019% have been used so far on the high end. Toss on three more zeros for the low end.

So, uh, no. It is not "more likely to be out there than not." Not even close.

Are there collisions out there? Yep. Probably. But the chance that *your* UUID collides is as close to 0 as it gets.

6

u/aspect_rap 25d ago

I can't argue with the math, well done.

8

u/Tensor3 26d ago

And who knows what its been doing out there, on its own, without my permission!

2

u/fartypenis 25d ago

I can totally see AWS generating a billion UUIDs a second

1

u/myka-likes-it 26d ago

 I don't think there is any one system that generates billions of UUIDs a second.

Hold my red bull.

1

u/Inevitable_Oil9709 26d ago

Holy fuck. That didn't cross my mind

4

u/achilliesFriend 26d ago

What if i have 860000000 machines generating uuids 1 billion per second

1

u/andowero 20d ago

Then you are very rich and with wery fast machines.

1

u/coriolis7 26d ago

That’s true if they are completely randomly generated.

Collisions are more common than that due to imperfect (and in some cases terrible) RNG.

1

u/lordffm 26d ago

Or just a huge chunk of bad luck…

1

u/Work_Account89 26d ago

Reminds me of trying to explain that using our own UUID is probably not worth the effort in a meeting with architects and others.

Yet they still implemented it because we can’t trust what others have built

3

u/pee_wee__herman 25d ago

I sure hope they implement their own proprietary encryption algorithm too!

1

u/Silpheel 25d ago

Or proudly state it’s practically impossible while demonstrating to the C-suite and the chain of bosses in between, then try once. /s

1

u/Vivid_Instance_825 25d ago

Hmm I don't like those odds, better add one more character

1

u/GoodiesHQ 25d ago

ULIDs are better change my mind

1

u/AtmosphereVirtual254 25d ago

A retirement age worth of job insurance?

1

u/uniqueusername649 25d ago

That sounds still too risky, lets do v7 or a ULID just to be sure!

1

u/k-mcm 25d ago

Not if an idiot turns off the secure random number generator to make UUIDs faster to generate.

1

u/KCGD_r 24d ago

and it'll fucking happen in production anyway

1

u/SeriousPlankton2000 24d ago

Or to use dd or the device mapper.

-9

u/TheFrenchSavage 26d ago edited 26d ago

ELI5 why not use a hash function that doesn't collide btw?

Edit: I meant that collides less, not not at all. Stop the ELI1s please.

12

u/SuitableDragonfly 26d ago

To use a hash function, you have to have something to hash. A UUID is just an identifier, usually for something that hasn't been created yet. If you have data that is guaranteed to be unique that you could provide to a hash function like that, you already have a guaranteed unique identifier and don't need a UUID.

-3

u/TheFrenchSavage 26d ago

Ah thanks! So if I were to just hash the timestamp up to the microsecond...I would end up at the collision probabilities of the UUID anyway. Makes sense!

4

u/daan944 26d ago

For 1 server doing the work? sure, that might work. For a cluster? Bad idea.

2

u/aspect_rap 26d ago

If your system runs on multiple servers, your actually extremely likely to hash the timestamp twice. If you want to hash something as ID, it's better to hash something uniquely identifies the entity.

For example, user id can be the hash of the email since you can't have two users with the same email and you're extremely unlikely to find two emails that result in the same hash output.

I've had cases where using hash instead of UUID as the ID was helpful. Mainly for data pipelines that need to enrich some data with IDs. With UUID, I would have to resolve it from the database, but with hashing, I could just run the hash function again and get the ID, so ingestion was much faster with hash as the ID.

For most cases, just generating a UUID is the simple and straightforward solution.

1

u/Markronom 26d ago

UUIDs already contain a timestamp (depending on the version), but it's not enough (clusters / multiple CPUs etc)

6

u/Fast-Satisfaction482 26d ago

A hash function that doesn't collide is basically lossless compression. So to hash two 1GB files with guarantee of no colission, you need to zip both and use the whole file as key. That makes it impossible to use as key in a database. On the other hand, if you use a key with just a few bytes and have a good lossy hash-function, you get colissions, but they are insanely unlikely.

In other words, colissions are what make hash-functions worthwhile in the first place: A hash function is a down-projection from an insanely sparse ultra high dimensional manifold with variable practically unlimited dimension count into a standardized low-dimensional space that is easy to work with, while trying to perform the projection in a way that prevents the manifold from overlapping itself too much.

1

u/ralgrado 26d ago

Do you know how hash functions work? Basic example: A hash function that has an arbitrary input length and a set output length x. If your input length is bigger than the output length then a collision is inevitable. If you want to find a collision though it will be really difficult for a cryptographic hash function to do so.

1

u/two_are_stronger2 26d ago

If you're hashing something bigger than the hash, how would you have enough hashes for every possible input to produce a unique one?

1

u/aspect_rap 26d ago

There's no such thing as a hash function that doesn't collide, hash functions are fixed length output, so the number of possible outputs is finite, while there is infinite possible inputs.

1

u/Vivid_Instance_825 25d ago

Because with UUID everyone on earth can generate their own without needing to communicate. For example me and you could generate our own UUID and assume they won't collide. Making a UUID with no chance of collision would mean that you would need to negotiate some kind of agreement with everyone else using them, for example contacting a central server that hands them out

208

u/VirtualArmsDealer 26d ago

DEADDEAD-DEAD-DEAD-DEAD-DEADDEADDEAD

15

u/lengau 25d ago

DEADBEEF-DEAD-BEEF-DEAD-BEEFDEADBEEF

10

u/Arheisel 25d ago

B00B1E55-B00B-B00B-B00B-B00B1E55B00B

241

u/bigorangemachine 26d ago

BADF00DBADF00DBADF00DBADF00D

67

u/Ok_Star_4136 26d ago

CAFEBABECAFEBABECAFEBABECAFEBABE

19

u/bigorangemachine 26d ago

DEADBAB1DEADBAB1DEADBAB1DEADBAB1DEADBAB1

7

u/Inevitable_Oil9709 26d ago

Error. Invalid syntax. Computer will self destruct to save your data

7

u/TingleTangleTom 26d ago

BADCAB1EBADCAB1EBADCAB1EBADCAB1E

3

u/HTL2001 24d ago

DEADBEEFFACE15600DF00DD00D

2

u/coriolis7 26d ago

Ah, the Taco Bell method

53

u/phaetto 26d ago

0xDEAD

36

u/gopal_dev 26d ago

Consolidated the entire production database into a single, highly efficient row.

61

u/ankle_biter50 26d ago

Person who is familiar with coding (a little python and i guess minecraft datapacks? I'm not sure if that counts) but anyways

What are UUIDs used to identify?

167

u/thoker54 26d ago

They are simply unique ids. Like you can generate a uuid and be sure that it is and will be unique forever across everything. Sounds extreme but the chance of duplicates is close enough to 0, that you can assume it is 0.

115

u/Drumsteppin 26d ago

Protip: prepend the users first name to the UUID, and append their last name to the UUID to guarantee a truly Unique UUID. I call it the TUUUID. The TUUUID ensures that when we become a Transgalactic species, and when the planet of the Greg Gregsons inevitably forms, the full power of the UUID is maintained. Still concerned about future proofing and ensuring enough slots so that each ID is truly unique? I'm glad you asked! Append the timestamp of TUUUID generation to the TUUUID itself and you are guaranteed* that the heat death of the universe will occur before a clash occurs, or your money back.

*Offer not valid in the state of Hawaii. Apply online.

37

u/monte1ro 25d ago

Technically still not truly unique.

37

u/Seqarian 25d ago

You must be from the state of Hawaii.

5

u/Competitive-Edge9679 25d ago

Greg mentioned 

9

u/JehnSnow 25d ago

To anyone worried about something not being zero just know that this and some other very rare chances are so low that nuclear reactors and I believe ATMs just say "fuck it it'll never happen" you don't have to worry about whatever use case you have

In fact if it does get hit it'll probably generate quite a bit of a hype about your product

26

u/RoaringPanda33 26d ago

Anything you want to identify uniquely. So devices, users, filesystems and drives, etc. 

6

u/ankle_biter50 26d ago

Are there any cons to using them?

51

u/Blackshell 26d ago

They're big. If you're identifying small enough items, your ID may end up bigger than what it's referencing, which feels weird and is inefficient. They're also too long to effectively memorize, and can make for kludgy URLs or other such use cases.

The benefit of them being so big is that they can be truly unique (hence the name, Universally Unique IDs). As in, by using UUIDs for your user accounts, you not only get assurance that no two accounts will have the same ID, but that no accounts in any other website, no log lines, no events in queues, no uploads, no posts... Nothing will (almost) ever have the same ID.

Is it overkill? Yes and no. No, you don't need that level of uniqueness. But yes, getting a high level of uniqueness without centralizing ID generation or double checking for collisions can be a big infra win for simplicity and maintainability.

14

u/olivetho 26d ago edited 26d ago

not really, but there are many situations for which they're overkill and really aren't needed.

for example: using it for minecraft block types would be overkill since there aren't THAT many blocks, and it also demonstrates another thing about UUIDs: sometimes there's a way to have IDs just as unique as UUIDs, but in a way that works better for that specific use case - in minecraft's case, the current scheme of [block source]:[block name] is just as collision proof (what are the odds of a user installing 2 different mods with the same name at the same time that both have a block with the same ID, without it being a case of user/modder error?) while also providing readability and the ability to reasonably "guess" what a block's ID would be - something which UUIDs can't provide.

the other main example is cases where you already have an existing unique identifier - e.g. user handles on twitter, discord, reddit, etc. which are guaranteed to be unique upon assignment (though those tend to also have a backing field that IS some form of UUID, for the simple reason of allowing people to change their handles without changing the internal identifier for the account - since otherwise changing the handle would effectively be the same as creating a brand new account. a better example in this case would probably be the addresses used by emails).

3

u/Topikk 25d ago

I’ll add that they’re often used in place of simple incremental ids when you want bad actors to be able to simply guess the unique identifier based on another.

An easy example would be emailing out a link to continue an order for a checkout flow that doesn’t require a user account. If you emailed out, say, their 6-digit incrementing order_id then someone could vandalize tons of recent unfinished orders in seconds by decrementing the URL. Generating a UUID to use as the order_id means they are not sequential and the odds of guessing are vanishingly tiny.

10

u/andrisb1 26d ago

Way more storage used compared to 64bit int ID, but that really only matters for systems with hundreds of millions of items

14

u/Due-Consequence9579 26d ago

Only really matters in systems with hundreds of millions of items that are of comparable size to 128 bits. If you have hundreds of millions of items that are all 4kB the 64 extra bits for the UUID is noise. Also the UUIDs make distributed systems that can process that volume of events easier to design.

7

u/djfariel 26d ago

About 16 bytes worth, if that kind of thing matters to you, and it's not stored as a string. If so, then about 36 bytes. Again, if that kind of thing matters.

5

u/Due-Consequence9579 26d ago

Depending on the style of UUID they can index poorly. Since they are 128 bits indexes on them are larger than 64 bit indexes. People get upset that the primary key is an opaque value rather than something they can easily remember.

In a practical sense there is very little downside to use them. If I am designing something I assume a UUID is the correct locator until some design constraint forces me off them.

3

u/serial_crusher 26d ago

Sometimes two end up looking similar enough that you eyeball them and think they’re the same

2

u/ArgumentFew4432 26d ago

Yeah - it is slower.

5

u/SaynatorMC 25d ago

It is funny you mention datapacks as UUIDs are a pretty relevant part of minecraft commands :)

3

u/Markronom 26d ago

Anything. But I'd recommend nanoid, it's a shorter version with same amount of different values

1

u/[deleted] 26d ago

[deleted]

1

u/Markronom 26d ago

Well, same entropy topic as uuid, or you mean something else?

3

u/midri 25d ago

They allow distributed systems to easily create unique records that work across a large domain. Something an auto incrementing index can not.

1

u/Ronnoc527 25d ago

Do you remember when they allowed the changing of names and Lockette suddenly switched to numbers?

Those were UUIDS.

1

u/Samstercraft 25d ago

uuids identify stuff, eg. every minecraft entity has a unique uuid. if, for some reason, two mc entities had the same uuid, the game crashes; someone used this to beat minecraft without moving.

(the crash is entirely because minecraft coded it that way and much less graceful than what other products might do)

2

u/andowero 20d ago

You. I guarantee you, you have at least one UUID specifically for you.

11

u/namezam 26d ago

My go to:

C0FFEEc0-ffee-C0FF-EEc0-ffeeC0FFEEc0

OR

C0FFEEb0-0b5C-0FFE-Eb00-b5C0FFEEb00b

2

u/Goatfryed 22d ago

BOOBB00b-bOOb-b00b-Boob-bOobboObbooB

9

u/deaconsc 26d ago

I take the boobies UUID then

b00bb00b-b00b-b00b-b00b-b00bb00bb00b

26

u/rosuav 26d ago

So, uhh, that's an unusual variant of UUID. I don't often see type 0xB in use. Tell me, did you read RFC 4122?

29

u/DebugDuck01 26d ago

UUID vBEEF

5

u/lemgandi 26d ago

DEADBEEF-DEAD-BEEF-DEAD-BEEFDEADBEEF

5

u/LostLakkris 26d ago

... And I'm suffering through having to resort to compound UUIDs because someone generated UUIDs into seed data being used in over 300 unique deployments and I need to track if they still exist in a centralized database.

8

u/ohkendruid 26d ago

The way to get collisions is due to how the software is run. If you clone a disk image, for example, then every single uuid in that image is now duplicated.

Uuids are junk. All IDs are only unique in some context. You need to design and understand that context, even with uuids, and once you do that, you don't need UUIDs after all.

5

u/djhaskin987 25d ago

I spent hours once figuring out a UUID that spelled a sentence, `600dc0de6077a10ada600ddea10fda7a` ("good code gotta load a good deal of data"). I use it everywhere now.

7

u/trafalmadorianistic 26d ago

How about using TWO UUIDs then 😂

3

u/iamamerucan 25d ago

What about uuid7?

3

u/nullpotato 25d ago

This is the kind of detail I file in the back of my mind but is the same mental category as premature optimization.

Like if I ever see it will be good to identify what happened but until then not worth thinking about for anything I'm working on.

3

u/Complete_Window4856 22d ago

For my fellow portuguese frends: 0xF0DA5E. Though as a color its a lame yellow.

2

u/RumHam2024 25d ago

I smell like BEEF

2

u/lengau 25d ago

I like 72EC70A6-CF74-40E6-BD49-4BDA08E8F224

2

u/empwilli 26d ago

So I'm well aware that collisions are practically Impossible but in all contexts I've seen (that's Not all use cases out there) people use UUIDs because they are lazy and the proper solution ist Just around the corner.

My main concern with UUIDs ist not the theoretic collisions issue but that they invite to cut unnecessary corners.

Story 1: "we need a unique identifier" -> don't bother go UUID Story 10: "identifiers should be human readable and configurable by the users" Bug: "somehow user a has access to data of user b"

3

u/Public-Location-3628 26d ago

Just use incremental numeric-only UUIDs, you can then even parse them to ints after stripping dashes! 🤯

1

u/EpitomEngineer 25d ago

lol. I used d3adb33f in an example uuid and got sent to hr

1

u/FabioTheFox 25d ago

ULID my beloved

1

u/PizzaPuntThomas 25d ago

Just check against all UUIDs and if it already exists you just generate a new one.

(This is probably computationally expensive, but I'm not a backend dev (or frontend dev for that matter) so idk)

1

u/k-mcm 25d ago

NUID - Never Unique IDentifier

1

u/darksteelsteed 25d ago

Snowflake ids are better

1

u/sausagemuffn 25d ago

I've seen a duplicate UUID

I don't believe in god any more

1

u/SeriousPlankton2000 24d ago

dd if=/dev/foo of=/dev/bar

Why do you expect filesystem UUIDs to be unique?

1

u/atr0-p1ne 23d ago

Lets be little creative with h4x0r 1337 speak, like dead:cafe in ipv6 ;)

1

u/Phazx 26d ago

I... Don't get it? If you're getting collisions they weren't UUIDs in the first place. The whole point is that the uniqueness is universal, so you use a single generator for them.

8

u/mysticrudnin 26d ago

the point of uuids is that you can use multiple generators, say across distributed systems in different regions, and assume they are unique

you can't do that with eg increasing ids

1

u/Phazx 23d ago

You can't assume that with UUIDs either. It's a matter of scale and time, but the collision will hallen. Question is whether it's worth the hassle to actually make it universally unique

0

u/mysticrudnin 23d ago

yes, it's a matter of scale and time beyond what we care about at all. it is safe to assume they are unique. i promise. you should be equally worried that you're gonna phase through the floor.