Surely only temporarily, though. I mean, this is an exponential process---adding one bit only doubles the space, and it will not take another nine years before some video passes 4 billion.
By that line of reasoning, 15.75 years from now there will be a viewcount greater than 8 billion.
... and now I realize you may be correct, and that it's probably inevitable that a viewcount will not only exceed the total number of people alive, but will double or even quadruple it. Our total population is actually about 100 billion, but only ~7% of us are still alive.
The shadows of the dead will be forever enshrined as YouTube view counts. Our shadows.
YouTube is slightly under 10 years old. It's interesting how we're willing to project it forward into the far future. Not that i think that's wrong or anything - it's just that it's gone from nothing to essential in a fraction of a human lifetime.
"We always overestimate the change that will occur in the next two years and underestimate the change that will occur in the next ten." - Bill Gates
Why not just use some sort of unlimited BigNum implementation? Yeah, for small numbers it's still ~2x the size of just storing an int, depending on implementation (or it can be: "int unless MAX_VALUE, in which case bignum is stored somewhere else") and it might be slower to operate on... but, on the other hand, you are already storing and processing a full video for every such counter!
Edit: Now I realize that would mean Google couldn't have made this joke. But I am still not sure this was foreseen by Youtube devs from day one.
Yea according to a reddit post from a Googler this was more of a staged easter egg then a real bug. Google coding styles actually prohibit the use of unsigned integers in C++ code.
Interesting, until very recently I was writing a whole bunch of C++ at Google but I can't recall any such restriction. Most internal data structures at Google are expressed as protocol buffers and surely these support unsigned integers. In fact if someone suggested that a view counter should be signed that would invite a snark (kind of Google's specialty) like 'can it ever be negative'?
[One problem with unsigned integers in protocol buffers is that some supported languages like Python have no concept of signed/unsigned integers. Which is why for example Thrift does not support that distinction. This has nothing to do with C++ though.]
> One problem with unsigned integers in protocol buffers is that some supported languages like Python have no concept of signed/unsigned integers.
You can still implement range checks to enforce that the numbers are in the correct domain. It's not that much of a problem.
This is more of a problem in a statically typed language like Java, because it means there is no native data type to map protobuf's unsigned types to. In Python this doesn't matter as much because numbers will automatically promote themselves to bigints.
I suggest someone write a browser add-in that re-plays this 100s of time when machines are idle to do massive distributed viewcount attack and force YouTube upgrade to 64-bit unsigned int now!
