I find Javascript depressing. If it had a few more years to develop, it could have been a really great language. I understand why it wound up that way, but, sigh.
If you want to see a much better language with the same general design, look at Lua. It's made for scripting C programs rather than web pages, and it has had over a decade longer to mature.
Lua has been able to make major, reverses-compatibility breaking changes to improve its design in ways Javascript hasn't. Where Javascript has "The Good Parts" and incrementally improving implementations, Lua has been able to fix things and evolve.
Lua (without JIT) is also one of the fastest non-JIT, non-native compiled languages there is. LuaJIT is also one of the faster JIT languages. Now, I'm not sure how it compares to the popular JS JIT engines, but from what I've read, its very hard to beat LuaJIT for performance.
I've talked and written recently about why "just pick[ing] up Lua or Python" was not an option, but there are other strong reasons that was not in the cards.
Think about what mid-1990s Lua and Python were like, how much they needed to change in incompatible ways. The web browsers would never have tolerated that -- you'd get a fly-in-amber-from-1995-or-1996 version of Python or Lua, forced into a standards body such as Ecma (then ECMA), and then evolved slowly _a la_ ECMA-262 editions 2, 3, and (much later, after the big ES4 fight) edition 5.
Interoperation is hard, extant C Python and Lua runtimes were OS-dependent and as full of security holes, if not more full, than JS in early browsers, and yet these languages and others such as Perl were also destined to evolve rapidly in their virtuously-cycling open source communities, including server-side Linux and the BSDs (also games, especially in Lua's case -- Python too, but note the forking if not fly-in-amber effects: Stackless Python in Eve Online, e.g.).
JS, in contrast, after stagnation, has emerged with new, often rapidly interoperating, de-facto (getters, setters, array extras, JSON) and now de-jure (ES5) standards, the latter a detailed spec that far surpasses C and Scheme, say, in level of detail (for interop -- C and Scheme favor optimizing compiler writers and underspecify on purpose, e.g. order of evaluation).
The other languages you cite have been defined normatively over most or all of their evolving lives entirely by what their C implementations do. Code as spec, single source implementations do not cut it on the web, what with multiple competing open- and closed-source browsers.
You have to compare Lua at 1995 (version 2) to JavaScript at 1995, as its development, at least inside the browser, would be arrested the same way JavaScript's was. Lua 2 was certainly had a much better implementation than the first JavaScript, but I would not call it a better language (didn't have JavaScript's annoying quirks, but also didn't have closures, for example). 2000's Lua (5.0 and 5.1) is quite different from its earlier incarnations.
I'm mostly thinking about how many of the problems highlighted in "Javscript: The Good Parts" have been fixed in Lua, while Javascript can't be fixed. Not a matter of design and taste, but outright bugs.
That's what I try to do, which turns it into a crippled Ruby. And there's no getting around it silently doing the wrong thing if I ever forget a "var" or "===".
For what it's worth, there are tools that can help you avoid the bad parts. JSLint won't let you forget a "var" or "===" ... and if you use CoffeeScript, it's not possible to forget "var" or "===", because there aren't any.
I'm not saying that there aren't better programming languages than Javascript. I'm just saying that there is a subset of Javascript which is really expressive and elegant.
That elegant, expressive subset is basically Lua. It's been able to jettison most cruft over the years.
I'm not a web developer, but every time I read/use Javascript, it feels like a broken fork of my favorite language. Javascript could have been that good, too. I like where Eich was going with it, but the browser wars etc. meant that shipping an early version made the most business sense, and design errors (which would have shaken out) got frozen in the spec.
It's not the case that the Web dooms us forever to use JS as it was in 1995.
That is simply false on a number of JS-specific points, but more generally: the Web's deployed-browsers-with-enough-market-share-to-matter intersection semantics moves over the years. It does not stay still or grow only compatibly. Bad old forms (plugins, especially, but also things like spacer GIFs used in pre-modern table layouts, not to mention old JS versions) die off.
So, cheer up! JS can't be Lua, but it doesn't need to be. Its job is to be the best it can be according to its species and genus, its body plan. Which may be related to Lua's, but which was not and will never be the same as Lua's, because JS and Lua live in quite different ecosystems.
A concrete example: Lua has coroutines now, but JS is unlikely to get them in the same way, interoperably. Some VMs would have a hard time implementing, especially where the continuation spans a native method activation.
This is a case where Lua's single-source implementation shines, but that's just not going to happen on the web, in variously-implemented, open- and closed-source (the latter including clean-room, for fear of patents) browsers. So, we're aiming for Pythonic generators at most.
If we go further than generators, I'll be surprised. Pleased too, don't get me wrong. However I doubt it will happen, because some on the committee do not want deeper continuations than generators, since greater than one frame of depth breaks local security-hat-wearing reasoning about what is invariant in JS's run-to-completion, apparently single-threaded execution model.
