Item — HN Reader

> Yet it dutifully tries as hard as it can within this design goal by e.g making its == compile to JS ===.

Now we're effectively losing the "==" operator, which is behaving like in most other traditional scripting languages (e.g. Perl). What did we win by losing an operator? Why obfuscate that this is not the JS "==" operator but most likely the "===" operator?

1 comments

Either one wants weak typing or strong typing, but one cannot have both. "most other traditional scripting languages" consists of Perl and PHP (not even (ba)sh/test, to which == is string comparison whereas -eq is integer comparison), while languages typically used on the backend together with JS/CS include Python, Ruby, Java, C#, and whatnot, none of which have such an error-prone feature.

> What did we win by losing an operator? Why obfuscate?

Type safety, and resistance against both bona fide errors and clueless developers. Sane defaults matter.