this post was submitted on 12 Aug 2025
530 points (96.8% liked)
Murdered by Words
2165 readers
219 users here now
Responses that completely destroy the original argument in a way that leaves little to no room for reply - a targeted, well-placed response to another person, organization, or group of people.
The following things are not grounds for murder:
- Personal appearance ("You're fat", "You're ugly")
- Posts with little-to-no context
- Posts based on a grammar/spelling error
- Dick jokes, "Yo mama", "No, you" type responses and other low effort insults
- "Your values are bad" without any logcal or factual ways of showing that they are wrong ("I believe in capitalism" - "Well, then you must be evil" or "Fuck you you ignorant asshole")
Rules:
- Be civil and remember the human. No name calling or insults. Swearing in general is fine, but not to insult someone else.
- Discussion is encouraged but arguments are not. Don’t be aggressive and don’t argue for arguments sake.
- No bigotry of any kind.
- Censor the person info of anyone not in the public eye.
- If you break the rules you’ll get one warning before you’re banned.
- Enjoy the community in the light hearted way it’s intended.
founded 2 years ago
MODERATORS
Who needs editors anymore?
I toataly ahgree.
Isn't that like Amdahls law, where you don't ask a question but say something wrong on the internet?
No you’re thinking of Murphys Law, where the number of transistors in a circuit doubles roughly every two years
No, you’re thinking of Moore’s Law, which is where without a clear indicator of the author's intent, any parody or sarcastic expression of extreme views can be mistaken by some readers for a sincere expression of those views. It’s why the “\s” thing exists.
Murphy’s Law is:
- Serve the public trust
- Protect the innocent
- Uphold The Law
Thank you for not smoking
no you're thinking of Sturgeon's law, where you can replace all resistors and capacitors in a circuit with a big one of each of the same total value
I think you're thinking of Betteridge's Law, which is a side dish consisting of thinly-sliced cabbage in dressing.
I think you’re thinking of Cole’s Law, where you are only allowed to include up to 5 citations in your report out of Cole’s Notes. Also word salad.
Pretty sure this is about Cole Protocol, which specifies procedures to prevent UNSC Ships from leading the Covenant to Earth. It uses a random series of slip space jumps, along with removal or complete destruction of all data sources pertaining to the location of Earth.
But this was arbitrary. It's not like "why are there only 16 colors on this video game" (because of space constraints). They could have made it 257 users and nothing would overflow. Given that, I think they should have made a human-comfortable number (multiple of 10) instead of a machine-comfortable number (power of 2).
It’s only arbitrary if you ignore the history of computing and the eventual settling on a standard of 8-bit bytes as the smallest addressable value in most programming languages and operating system libraries (though not always addressable in hardware).
Unless you’re making the very meta claim that it was arbitrary for us to settle on 8 bits instead of 10 or something. I think there are a lot of technical merits to 8 bit bytes (being a power of 2 is nice and 4 bits is just too small).
Yes, but this is not a historical piece of code, it is a 21 century app. I very much doubt they are using a uint8 to represent the array size, it's probably a 64 bit int. They might as well have used 300 or 250, or 1000.
WhatsApp’s back-end is written in Erlang. Erlang is a very old language with weird limitations. For one thing, it doesn’t have different machine-sized (16, 32, 64 bit) integers the way C does. Arbitrary-precision integers are the only primitive integer type. This makes it quite a slow type to use for something like a group chat member ID.
However Erlang also has a type called a binary which is used for space-efficient storage of binary data (along with primitive operations on bits). These types are stored as sequences of bytes. I’m guessing this is how WhatsApp does group chat IDs, which would make the 256 user limit perfectly understandable (keep every ID contained within a byte).
I don't think every user would have an ID in the chat of 1 byte, that would be a nightmare when leaving and joining the group, reusing IDs, etc... each user needs to be identified with its uuid (or whatever else they chose).
Using a 32 at 64 bit size and limiting the value makes much more sense, any subsequent changes would be a config tweak instead of a major refactor. I would guess the limit was a fun "Easter egg" type of thing rathar than a hard technical limit.
WhatsApp has billions of users. Scaling to that level and maintaining perfect real-time chatting with arbitrary user-created groups is not trivial. Storing 64 bit UUIDs for every single message and other interaction in a group chat would be inefficient, not to mention unidiomatic in Erlang (due to previously-mentioned lack of machine-sized integers).
The use-case of a group having <256 current users but >256 historical users and the desire to scroll back and read very old messages of people who left the group is very uncommon. It makes perfect sense to put a situation like that on a slow path while optimizing for the common case of <256 chatting right now.
I disagree for various reasons:
It's not very uncommon, it would be an issue as soon as it happens, without going back that far. Even if it was uncommon, it is possible and something to take care of, making for a super ugly "special case" code.
Plus you don't need to sort the user's ids to deliver messages, it's a foreach kind of operation.
And finally, given the underlying hardware, sorting 8 bit integers wouldn't be faster than sorting 64 bit ones (which we don't need to do, anyway), processors move all bits in parallel. Unless WhatsApp runs on 8 bit microcontrollers.
I didn’t say sorting, I said “storting” and must have corrected the typo while you were writing your reply. I meant storing. Having a 64-bit UUID attached to every single one of trillions of messages (per day) is a huge amount of wasted space (72TB per trillion messages, just to store 64-bit UUIDs without any message contents).
As an annoying aside, my phone now thinks “storting” is a word and helpfully autocorrects storing to that now. Good grief!
I don't see how a message uuid is related to the group membership storage...
I haven't seen the code of WhatsApp, obviously, but I use a similar question to interview candidates. There's a few ways of implementing groups, and you have to store group membership somehow, but just once per group.
When a message is sent, it can be stored with a foreign key that relates it to the group, a message ID that should be unique for whatever DB is in used, plus a timestamp. When checking new messages, a client provides the timestamp of the last retrieved message and the server provides all messages since then (per group). Even read confirmations can be implemented using timestamps. There's no need of storing all group members for every message (not that you claimed it is, just making sure).
Sounds like you’re not storing who sent each message to the group, so how is anyone supposed to follow a group conversation between multiple participants if all you’re storing is the group ID and a time stamp?
Oh, you mean the sender id. I would definitely store the uuid, but I understand the tradeoff storing something smaller. However due to code complexity of reusing ids and small relative savings (even less with compression) I would definitely prefer the uuid solution.
This is how I would do it (and I think how it’s done but can’t confirm):
There’s really no complexity at all because you can just store a table of group members with 256 entries and send the index into that table with each message to each user. The users have a copy of the table on their client and when they receive the message the client looks it up in the table and stores it in the local message history.
You would not store message history on the server. Only messages which have not been delivered to all group members would be stored on the server. When people leave/join the group, you send group membership notices to all members and their clients update their tables accordingly.
Since you don’t store message histories on the server, new people who join the group can’t see messages that were sent before they joined. This eliminates the need to send UUIDs with every message and furthermore it eliminates the need to send large message histories all at once when someone joins a group. Since clients store their own histories with UUIDs attached to messages (not table indices) there is no issue with table index reuse.
Some programming languages and data storage types have 8 bit limits. You'd be surprised.
Any language that implements and enforces a uint8, yes, but you don't use those types because of forward compatibility.
They could have made it 257 users and nothing would overflow
It might if the people writing the software are extremely old school about their approach to memory management
FF in the chat
0o377
I see what you did
0x0BA5ED
That is like 10 Years old. (I did not look it up) Can we not stomp on tiny mistakes from 10 years ago?
I'm sorry, but I disagree - sometimes things just qualify as classics, and also serve to act as warnings to future generations.
"Can't we just ignore history?"
Any time there's a community with the same name as a subreddit, it gets filled with Reddit's Greatest Hits.
I know the whole "Lucky 1 in 10,000" thing but man, the Internet nowadays is mostly just buckets full of the same old memes other people made. Original content is so goddamn rare, especially memes.
This is not a complaint about OP, just a general observation
Even if the number was chosen completely arbitrarily, why would it warrent a "yikes"?
Pretty sure the "Yikes" was because the number was obviously not arbitrary and the tech reporter didn't know that.
If it were truly an arbitrary number it likely wouldn't warrant a "yikes."
I get the impression this is the non tech crowd commenting here.
It's like the tech writer that didn't know what the shift key did.
256 = 200 + 56, initially they only wanted 200 people in a chatroom but decided 56 more was even better, so it's very oddly specific indeed.
I wonder why its so hard for journalism institutions to find someone with an appropriate background to cover certain high-volume beats.
It's particularly egregious with military and science stuff, where it becomes painfully obvious that whoever is doing the reporting just has no clue how any of the stuff they're reporting on actually works. Seems to be it'd be a worthwhile investment to hire someone with at least some sort of science degree or military training to cover beats that are that high volume.
It's not like they go with completely ignorant randos to do their sports reporting, the sports reporters usually know some stuff about the rules of the sport and how its played.
Because they won't pay what someone actually qualified for the task would require. They still get their clicks because people want to stay informed, and yet also do so for cheap. Late stage capitalism has everybody attempting to wring value out of every last penny in order just to keep afloat in a world where the absurdly wealthy see average people as just pawns in a game the one-percenters are driven to "win" no matter what.
load more comments
(1 replies)