If someone has been around long enough to understand what a "slave" is can't figure out what a "replica" or a "follower" does, maybe they shouldn't be in tech. The transition cost for documentation is essentially zero.

Naming things is hard, and better names are better for everyone. Antirez said he would change the name if he could start over, hence the hill you're dying on is not shared by the author of the library you're posting on.

Edit: For clarity of argument.

>This hill you're dying on looks awfully lonely.

Ironic coming from a grey response to a 15 point comment.

I will change my tune if even one victim of slavery comes forward and speaks about the use of the terminology.

I'm glad that your concerned that "follower" and "replica" aren't perfect terms. We should be concerned with terminology.

I humbly suggest that "slave" DBs are not physically whipped by their "masters", therefore are an even worse metaphor.

> These arguments are a waste of everyone's time.

Then why are you wasting your time? If you don't care, don't argue back. Boom, you've got your time back. We all get a better name, everyone is happy.

Here's a question: if "slave" is offensive, should "kill" (as in 'kill 69' to kill a process in SQL Server) be considered offensive as well? Simply as a consequence of being something 'bad/immoral'? I'm sorry, and I'd be glad to be corrected, but I genuinely find this argument...disingenuous. And people who see things the same way I do see that kind of argument and think that you've got other motives.

EDIT: I want to say (to prevent this discussion from flying off into Trump-land) that I'm liberal on most issues except gun control. I just have a hard time relating to the 'micro-aggression-y' brand of liberalism I've been seeing of late.

> I genuinely find this argument...disingenuous

My argument is that the term is not technically correct. How is that disingenuous?

Edit: Edited this note to mention I updated the previous note with an edit note.

There are probably hundreds of ill-fitting terms in the tech world that now mean what we mean them to mean (lol). This one receives blowback not because it's technically unsound (which it might be), but because some paint it 'offensive'. That's why everyone seized on this part of your (now edited) argument.

EDIT: thanks for being honest btw

What is easier having to have this conversation EVERY time the term gets used for the rest of eternity, or making the change once and being done with it?

That's not very compelling. Just because certain people make a lot of noise doesn't mean we have to do what they want us to do.

>For most projects it seems like a pretty easy change. You could add new keywords, alias the old methods/commands to them. You don't even have to deprecate them, just make the docs point to the newer terminology.

...for every project that uses these terms across the entire industry. You know what's easier? Not making the change. There are two arguments:

1. The technical gain by changing these terms outweighs the drawbacks (legacy code, consensus/convention, etc.). I doubt there's much to gain here.

2. The technical aspect doesn't matter since it's offensive. I've already addressed this.

Antirez said if he started a new project it would be named something different. I can only assume some other future databases will will take this approach. Maybe Antirez will write one of them. When that happens now we have a new problem: divergence in the ecosystem.

My preference would be for a big project to adopt a separate term, "secondary", "follower", "replica", whatever. So that when other new DBs look for an "alternative term" there is somewhat of a standard. Really though, that's not even that bad of a problem, because when i say all those terms, "secondary" etc. it's pretty obvious in the context of a DB what i'm talking about.

Do you have to do something __just__ because people are making your life hard? No. Do you have to make a change just because something is technically incorrect? No. Do you have to make a change because something is offensive to a large group of people? Still no. Maybe a better question to ask is, at what point would the tables be turned? What would push you over the edge to say it should be changed?

Agreed - I was talking more 'sum' than 'average' cost.

>Antirez said if he started a new project it would be named something different. I can only assume some other future databases will will take this approach. Maybe Antirez will write one of them. When that happens now we have a new problem: divergence in the ecosystem.

Also agreed, divergence breaks the 'consensus/convention' I mentioned earlier. That definitely has consequences, although in this case it wouldn't be too bad, as you mention next:

>My preference would be for a big project to adopt a separate term, "secondary", "follower", "replica", whatever. So that when other new DBs look for an "alternative term" there is somewhat of a standard. Really though, that's not even that bad of a problem, because when i say all those terms, "secondary" etc. it's pretty obvious in the context of a DB what i'm talking about.

Also true, and (assuming we're making the change) that seems to be the path of least resistance. At least we'd only have one new term, lol. And they are fairly clear.

>Do you have to do something __just__ because people are making your life hard? No. Do you have to make a change just because something is technically incorrect? No. Do you have to make a change because something is offensive to a large group of people? Still no. Maybe a better question to ask is, at what point would the tables be turned? What would push you over the edge to say it should be changed?

It's hard to quantify the factors imo. You kinda have to balance consensus/convention & migration cost vs. 'cost of incorrectness' & 'human cost of offensive term'. Cost of incorrectness is a big one if newbies struggle to understand the tech due to confusing terminology, but I don't see that here. If the term were truly offensive I'd agree that that'd tip the scales. I just don't see it.

For Django the change was much simpler because it was mostly a docs/tests change. However, here, we'd have to change Redis' API (or include more than one way to do the same thing).

Raising the point is fine. Discussion is important. But making the change, in this case, has some clear downsides that antirez has carefully weighed against the pros.

A good practice should be to try to find the most convincing voice (online, not just here) with an argument that answers this question.

That's the best route to honesty. If you can't do this then you're not up for debate.

This is something we all have to do with all of our arguments or questions.

If a question is not investigated it becomes a statement. Just because the person that you're asking cannot come up with a good answer does not mean that a good one does not exist.

So you win by make a statement and not asking an honest question.