Yeesh. I'm going to write a "deconstifier" shim that allows you to interface
with other people's code, casting between const and non-const without throwing
a compiler warning. And I'm going to reserve the domain "deconstifier.io"
because when you have an .io domain people automatically assume that you are
an inarguably brilliant developer.

In 2012, someone complained that their documentation doesn't state that concatenating
a string past the max_allowed_packet will result in a 'null' for the string,
and how heinous that is, etc.

So they documented this fact. But not in the part of the documentation where
you'd look at the concat or concat_ws string manipulation functions. No,
that would be a wholly logical, reasonable, intuitive place to look for such
a thing. Instead, they documented it at the end of the table of string functions,
where everyone would look for such a thing.

The *only* reason I found this was after looking at the bug report. I don't
normally make a habit of looking tediously over every shred of documentation
when I need to research a problem, because, I dunno, I have other things I
need to accomplish in a day or something.

I dunno... I guess I could complain
and be the first person since 2012 to point out the ridiculous nature of their
solution and be known as 'That Guy' or something. On the other hand, I could
just tuck it away as My Little Secret and whip it out someday when the right
set of circumstances come about where such information is useful.

If you had the 4gb LONGBLOB, you'd need to change your max_allowed_packet
in mysql to something that could accomodate that size. I wonder how many
people even know there's this variable limiting how much they can actually
put in the table?

Actually, in our case, that's almost literally what we do for one situation.

We have metadata associated with the file, and we perform searches within
the file's contents for information. To keep our interfaces for this kind
of stuff uniform, we keep the file itself in a column of the database.

As the whole database is semi-temporary by the nature of what we're doing,
it isn't a big deal. If we were doing something that lasted longer, yeah,
this isn't the approach we'd want to use.

Problem is, there is no way to statically initialize a HashMap, so I cannot
use an initializer, which means I cannot declare this as static. I tried
wrapping this in an Option<T> type and initializing it to None, but that fails
as well, since in order for this to make sense, I have to use Rc<RefCell<UserRecord<'static>>>,
which is not correct either, since the user records will not out-live the
user_list variable (just the opposite in fact).

The only way I can see around this is to declare and initialize this variable
in main() and just pass it to everything as an argument, but holy hell, that's
a nightmare. There has to be a better way.

Answering my own question: you don't. You have to wrap the global variable
into a single function as a static variable. Initialize it statically to
None, then use a match-clause to lazily create the value on first access.
Easy enough to do manually (if a bit boiler-plate-y), but there's a crate
that automates this (via macros) called "lazy-static".

It's variable length, like UTF-8 is, but takes up no less than two bytes
per character, even though the majority of text still falls in the 0x00-0x7F
range (particularly in Western languages). So why would anyone want to choose
an encoding that is "variable length but no less than two bytes" when there
is a "variable length, as low as one byte" encoding available?

UTF-16 seems to neatly combine the worst of both worlds. So why does it
exist?