replace suicide as a verb

[MylesBorins]

As discussed with @mikeal and @jasnell in #3720

we could alias 'suicide' to another word in the codebase to maintain reverse compatibility while moving to the new word and updating the docs. then it's a feature rather than compat break and stays semver-minor. @mikeal

What word should we use instead?

---

Content warning: some discussions of suicide in the comments below. --@isaacs

[silverwind]

Where does it say we shouldn't use it? In the same vein, one could say kill is bad, which is an universally used term in the Unix world.

[Qard]

I'm 👍 on replacing problematic terminology gradually, with aliases. For the kill and suicide terms, it seems to me like stop and stopped actually makes more sense, especially across language barriers. The master and worker terminology could also be parent and child, which seems a bit friendlier.

Sadly, the whole unix process model is overridden with terminology related to violence and slavery... 😞

[bnoordhuis]

Don't forget the sexual overtones: mount, touch, finger... Back on topic, we can't remove the .suicide property because of backwards compatibility. I'm -1 on aliasing it, that's just more surface area for bugs and confusion.

[mikeal]

I'm -1 on kill because it's documented that way in syscalls so this would add a lot of confusion, same for anything else that is documented as such far below the node.js layer. suicide is purely part of our own abstraction and should be changed. This goes back to the Node.js is fun principal: seeing suicide in my code bums me out and is decidedly not fun.

[mscdex]

Yeah IMHO I'm not seeing the benefit of changing the wording here when there would be backwards incompatibility. The word is short and to the point. As @silverwind mentioned, this is a slippery slope and in general, deviating from traditional UNIX/industry word usage (e.g. renaming kill to stop) is likely to just cause more confusion.

I'm -1 as well.

[mikeal]

Can you re-scope this to just be about suicide rather than opening up the potentially endless bikeshed about every verb in the code base?

[ChALkeR]

-1 for aliasing unless the reason for doing that is very serious.

That term suicide there is not directed onto someone, and without that, words are just words. You can see that word in any dictionary, in Wikipedia, in some book, etc. — it doesn't make the dictionary, Wikipedia, or the book bad.

Also, It's already there, non broken, and is purposely exposed. It's also not a security nor a bugfix. That would make deprecation a semver-major change, I guess. And I doubt that it will go away in the forseeable future.

[mikeal]

Yeah IMHO I'm not seeing the benefit of changing the wording here when there would be backwards incompatibility.

The whole point is that we can do this in a reverse compatible way without breaking any code, so this is just not true.

I think that this verb is particularly meaningful in that a member of our community killed himself not that long ago and those of us that were close to him would rather not be reminded of it every time we use this API.

[jasnell]

Going back and changing everything that is potentially unfortunate or problematic is likely not worth the effort. The comment I made that kicked this conversation off in the first place was due to my forgetting that suicide was already a term in use in the code. I'd rather not add to the problem by introducing new stuff. However, if we we have the opportunity to make improvements as we go, then we should likely do so, but we shouldn't bikeshed on it too much or try to solve everything all at once.

[mscdex]

Yeah IMHO I'm not seeing the benefit of changing the wording here when there would be backwards incompatibility.

At some point it would be removed though and if other parts of our API have been any indication, not everyone updates their code for things like this and sometimes we end up being "stuck" with past decisions.

I think that this verb is particularly meaningful in that a member of our community killed himself not that long ago and those of us that were close to him would rather not be reminded of it every time we use this API.

While that is tragic, to me it's important to separate technical, personal, historical, etc. contexts here and the suicide term as we use it in node.js is used in a purely technical context. I'd be much more open to changing the wording if for example the word was not an accurate description of what it was representing.

Also, as I said, changing this one particular instance leads to a slippery slope because then we would have to evaluate the entire code base and somehow objectively determine the "offensiveness" of each word we use because of the large diversity of negative things that exist in the world. For example, what about a female coder that had an abortion and has an issue calling sub-processes, "child processes" because the world "child" reminds her of her abortion and to add insult to injury, node's built-in module is also called child_process, requiring her to see the word every time she goes to start a subprocess? What about child.kill()? What about process.kill()? The list goes on...

Deviating from existing technical terms used throughout common computing platforms and the computing industry in general because a separation of contexts cannot be made on an individual level will IMHO cause more problems that will outweigh any benefit that may come of it.

That's my 2 cents.

[mikeal]

@mscdex There's a big gap between potentially offensive verbs we are using, and will in all likelihood continue to use, because they are adopted from the layer below us (like kill) and those that we are adopting in APIs that are entirely Node.js. In this case, we actually own this abstraction, we are not perpetuating the use of a common term, in the case of suicide we've actually chosen it for an API. This term isn't even common, I've never seen it anywhere else, a quick google for "suicide API" found no technical pages and a lot of depressing real stories, so I'm not seeing the case for persisting this verb when it's easily in our ability to move past it without negatively impacting users. You're making a good case for several other verbs, just not this one.

[mikeal]

At some point it would be removed though

Only if nobody is using it anymore, the cost of keeping the compatibility code there is basically zero.

[bnoordhuis]

the cost of keeping the compatibility code there is basically zero.

There is no such thing as zero cost code.

[mikeal]

"basically zero" == "as close to zero as a few lines of code can get, but definitely not literally zero" :)