The flip side of that coin is you have to reimplement a lot of things yourself, so any essential complexity that the language doesn't handle for you is pushed on you to re-implement in your codebase.

Python's decent at this too. At least the simple Python people use in small scripts. It's almost pseudocode, as long as no one tries and overengineers it.

Also, I hate that in languages with dynamic typing you have to read whole function to understand what type of arguments it takes and what is the return type. Nim is statically-typed, so all the types are properly declared.

*: excluding `for (… of …)` and `for (… in …)` – I can never remember which is which. `for (… of …)` is the one you can use with Arrays and other iterables.

There's more that will trip you up in JS if you leave it for too long. Off the top of my head:

1. Which function definition (`function` or `=>`) do I need to use in order to make the `this` keyword point at the correct object in an event handler/anonymous function/foreach parameter?

2. I see code with both `!==` and `!=` - what is the significance of using both?

3. Long chains of `filter` and `map`.

With its tuple, object, and destructuring syntaxes JS actually ends up with some of the most readable mapreduce code of mainstream C-derived languages (it’s soooo much worse in Java).

x = 0; !x → true

y = ""; !y → true

z = null; !z → true

2. `!==` is strict comparison, and `!=` tries to do incomprehensible magick to munge incomparable types together. I still know some of the rules (array to string sticks in my mind), but I doubt many people know all of them. There's almost never a good reason to use `!=`, outside `elem.value != my_integer`. (Though `NaN !== NaN`, so you need to watch out for that: since equality is defined recursively on objects I'm pretty sure this is infectious.)

3. The length of the chain is easy (though, iirc there are performance implications since it's not lazy). The hard part is the fact that map callbacks can take one, two or three arguments, so stuff like `["123", "456", "10", "1234"].map(parseInt)` will behave unexpectedly. (Something like `[123, undefined, 2, 5]`, though I might be thinking of PHP.) Not sure whether `Array.prototype.filter` has similar gotchas.

That's off the top of my head. I haven't seriously used JavaScript since the ES5 times, but JavaScript's a very… memorable… language. (I can't even remember hello world in Pascal.)

Most languages : myArray.any((e) => true);

Delphi : AClass.any<Type>(myArray, function (e) : Boolean begin Exit(True); end);

The readability is through the roof, lol.