go VS closure-library

Sorry, Kelly Knorton, I didn't realize his username on here and github is kellegous not knorton.

https://github.com/kellegous/go

Before jumped into this solution, I tried (deployed & tested) few others myself, mainly kellegous/go, kutt.it and adamyi/golinks. But, all of them "too featureful" for my needs.

> "I recently learned that some Node.js engineers prefer stream classes when building strings, for performance reasons." Pretty much tells you everything you need to know about node js, I guess.

Google Closure Library includes a StringBuffer class. [1]

I recall it having explanatory notes, but I don't see them in the code now. JavaScript engines can optimize a string concatenating to in-place edit, if there is only one reference to the first string. The StringBuffer class keeps the reference count at one, guaranteeing this optimization is available, even if the StringBuffer itself is ever shared.

[1] https://github.com/google/closure-library/blob/master/closur...

This made me wonder what the oldest go-link (from inside Google) discoverable on the public internet is. So far I've found one going back to 2013 (but there should definitely be some from the mid 2000s): https://github.com/google/closure-library/blame/11ed104958a2...

(Fun fact: go-links are so critical to Google ops, that they're expected to be accessible in a "everything is down" scenario.)

For data type I always use DECIMAL(#, 6). So 6 decimal places. This accommodates all generally agreed upon rounding standards for calculating interest, taxes, discounts, etc. So for me, something like $12.75 USD will look like 12.750000 in the database. I store the 3-letter currency code in a separate column. I know what the base value for each currency is on the code side in our framework, which has a currency library that reads a dataset that has every currency stored like this (the 'rules' key is a bitmask per Google's i18n currency.js):