Which of these javascript expressions is false?

nah, it's more fun this way.

Completely wrong. I'm hoping this was a joke... :-D

I always thought that NaN is required by IEEE rules to never equal any other number, including itself, because you can make NaN in different ways and this shouldn't result in equality or something, so C is wild but not javascript's fault.

The other three being true is definitely javascript's insane fault, though.

It also makes a lot of conditional expressions less complicated because comparisons of all kind against NaN return false.

I’m guessing there’s a reason they wanted min() to be able to be called without any arguments but I’m sure it isn’t a good one.

It not a totally unreasonable definition. For example it preserves nice properties like min(a.concat(b)) == min([min(a), min(b)]).

Obviously the correct thing to do is to return an optional type, like Rust does. But ... yeah I mean considering the other footguns in Javascript (e.g. the insane implicit type coersion) I'd say they didn't do too badly here.

Its the min value of the input params, or Infinity.

And the reason it's Infinity If there is no input, for better or worse, under the hood the method is assigning a variable, min, the highest value possible and then comparing it to each element in the list, reassigning it when it encounters an element lower than its value at the time. So it will obviously always be reassigned if there are any elements at all (if they're less than Infinity, I guess). But if there are no elements, it's never reassigned, and thus returns Infinity. It could have just signed min to the first element instead if Infinity, but that would lead to a runtime error when min was run without a function. If you're not going to throw a runtime error though, it makes sense for min to return Infinity because, what other number could you return that couldn't actually be the minimum

It’s pretty easy to avoid all of these, mostly by using ===. Null being an object is annoying and is one of the reasons ‘typeof’ is useless, but there are other ways to accomplish the same thing.

JavaScript has a lot of foot guns, but it’s also used by literally everyone so there is a lot of tooling and practice to help you avoid them.

That is not a fun fact. How do I unsubscribe :D

But B is true

"This comparison appears to be unintentional"

probably not true in most other langauges. although I'm not well versed in the way numbers are represented in code and what makes a number "NaN", something tells me the technical implications of that would be quite bad in a production environment.

the definitive way to check for NaN in JS would probably be something like

    
// with `num` being an unknown value

// Convert value to a number
const res = Number(num);

/*
 * First check if the number is 0, since 0 is a falsy
 * value in JS, and if it isn't, `NaN` is the only other
 * falsy number value
 */
const isNaN = res !== 0 && !res;