awful programming: feature flags and suffering

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > YOSPOS > awful programming: feature flags and suffering

Rhusitaurion: Sep 16, 2003; One never knows, do one?

FamDav posted:

the biggest issue is that distributing the software and even the software written to operate said software is at most 40% of delivering a reliable product in this space. with so few products delivering adequate resources and support, its pretty obvious how mongo was able to do as well it did.

imo we're still missing an open source distributed transaction log (as a a service) with a protocol that can encode sql semantics with serializable isolation at low 1000s tps and an order of magnitude or so more reads. everything else is just ux and routing.

Bloomberg's comdb2 https://github.com/bloomberg/comdb2 is more-or-less capable of this. I have no idea how bad it is to administer, since it was provided as a managed service internally, but it does what it says on the tin - serializable SQL transactions at 1k+ tps with a multi-datacenter cluster. They use it for drat near everything. As long as you don't try to use it for OLAP-type stuff (which everyone at BB did/does because it's all have lol), it works pretty good.

# ¿ Jul 23, 2018 03:39

Adbot: ADBOT LOVES YOU

# ¿ Apr 27, 2024 06:32

Rhusitaurion: Sep 16, 2003; One never knows, do one?

Symbolic Butt posted:

current q report: working with dates feels really nice but q is hella weakly typed so this is biting me a lot

Fun fact: this works with other handles as well:

code:

q)1 "lol\n" / 1 is the handle for stdout - lol printed directly to console, "function" returns 1
lol
1 
q)x:read0 0 / 0 is stdin
stuff
q)x
"stuff"

q is something else.

# ¿ Oct 17, 2018 02:23

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > YOSPOS > awful programming: feature flags and suffering