Sure. Language design is has tradeoffs but Javascript makes a lot of unforced errors, cases where the consensus was already established and Javascript went against it. (In fairness it was a single-application scripting language written by one guy in three days, not a language carefully designed for general-purpose use by a panel of experts).

Non-lexical scoping is awful, everyone knows it's awful. Recent versions added a better-scoped "let" which is progress in a way but now means you have two different kinds of declarations with very different kinds of scoping. "this" in Javascript is just entirely useless, confusing semantics that resemble no other remotely mainstream language. "Prototypal inheritance" is a mistake, again no other mainstream language uses it for good reason, and again newer versions of Javascript have added "class" to correct this but that leaves the language with two radically different ways of accomplishing the same thing. "undefined" manages to be an even worse version of the billion-dollar mistake, null; errors become apparent even further from where they occur ("foo is not a property of undefined" failures a long way away from whatever caused the value to be undefined), where what you want is fail-fast. Extremely loose value coercion at runtime is terrible for large programs in a language without a type system; even at the time Javascript was first created, Python or TCL knew this. (Perl didn't, but avoided the worst of the problems by not having so much operator overloading, e.g. using . for string concatenation). Indeed lack of any kind of type system is pretty indefensible in a general-purpose language these days, even Python's getting type hinting, though this was less common knowledge back when Javascript first came out. The language is far too dynamic for working with mixed security contexts even though it's the most popular language for that very use case, forcing browsers to resort to crude sandboxes and coarse-grained permissioning instead (e.g. you can give a site access to your webcam/microphone, at which point all the ads running on the page have access too). And there are a bunch of small usability niggles (the "wats" you see talked about), none of which is important in isolation, but developer-friendliness does add up.

Rust is a pretty conservative ML-family language design: where it differs from OCaml it's because of deliberate design decisions. (In fairness some of Javascript is descended from Smalltalk which was more respected at the time than it is now). Really most of what Rust does ought to be table stakes for language design (and it kind of is, looking at e.g. Swift or even Kotlin), should have been since the 1970s when ML came out: to quote Wikipedia, "Features of ML include a call-by-value evaluation strategy, first-class functions, automatic memory management through garbage collection, parametric polymorphism, static typing, type inference, algebraic data types, pattern matching, and exception handling. ML uses static scoping rules." (Rust may appear not to have exceptions, but ML "exceptions" have more in common with Rust's panic/recover than with Java-style exceptions). These things are small and simple but very useful and general, and allow you to push a lot of work out into libraries written in plain old "userspace" Rust code (though this would be much more true if the language had HKT, grumble grumble) rather than having to "bolt on" ad-hoc features at the language level. The only novel-for-mainstream language-level feature in Rust is its ownership tracking (i.e. the borrow checker), which is about the right amount of innovation for a programming language to have, and by all accounts is working well. Good language design is as much about leaving things out (of the language itself, pushing them into userspace code) as it is about putting things in.