27
May 14

Django’s Master/Slave terminology row

For those who’ve missed the original thread (oh, how much you’ve missed, not), it’s here.

For those wondering how you should think about this, it goes like this:

Can you stop using those terms please, they’re not nice.
What, seriously?
Yeah, seriously.
Oh. Okay, well we have these other terms that have been around for decades and are actually slightly better at describing the kind of systems we’re building these days. Cool?
Cool, thanks.
No worries.

For those wondering how it actually went and don’t want to waste your life reading the nonsense in the original thread:

Can you stop using those terms please, they’re not nice.
OH GOD THE WORLD IS ENDING YOU’RE SO STUPID THEY’RE JUST WORDS YOU’RE DELUSIONAL THIS IS RACIST THIS IS PC GONE MAD

Hmmm. Here’s a hint folks, there are hard things in distributed database design. Handling (and even detecting) split-brain scenarios to ensure data consistency even in the presence of partition failure. Dealing with latency issues and the performance penalties they cause. The whole CAP balance problem in fact and the the entire related debate around SQL/noSQL. And a wealth of other problems both big and small, related both to design and implementation. An entire industry of people spend their professional lives working on those hard problems and there still aren’t enough people to handle all the problems.

Whether to call a specific replication design “master/slave” or “active/passive” is just not on the list of hard problems. Honestly, it’s not. Someone has a genuine problem with the “master/slave” terminology, and many others have had the same problem with the same terminology for years? Quit whining, be a better person, use another terminology and get back to work.