It's patronising and inaccurate, but it's common among people who think Javascript is a serious language.
It's patronising and inaccurate, but it's common among people who think Javascript is a serious language.
On the other, it had imprecise typing, no multiprocessing, and no access to the file system. Some of that has been fixed, but Javascript was designed by one person in a week to script web browsers and that's still painfully obvious.
Why do closures make a language "serious"? To me languages are just languages. Seriousness is defined the problem you are solving. Are flight controls serious? Probably. Is yet another small scale CRUD app serious? Probably not.
There is a lot of "serious" code written in every major language. There is a huge amount of "serious" code written in C and C++, and all of this without first class functions or lexical closures.
A "serious" language is indeed partially defined by its fitness for the stated job at hand, but also for how well it handles the often unstated requirements of productivity, security, maintainability, and robustness in the face of likely future needs. Languages that have more of the above features tend to do better at these unstated requirements.
What is and isn't a "serious" language can change over time depending on what we learn is important. C was a serious language for a while, but it has not been one for a couple of decades because of its non-support of anything remotely resembling security. C is still used because of its extreme portability, but it probably should be abandoned.
Conversely, languages that support first-class functions, lexical closures, and automatic memory management are now in the serious category because those things present huge improvements in productivity, maintainability, and robustness in the face of future changes. (I'll even go out on a longer limb and say that programmers who learn to think in terms of functional composition become more productive coders in any language.) Pure O-O languages are beginning to move in the non-serious direction because they cannot be readily parallelized in an era when parallel computing is the only way forward now that Moore's law is dead.
Javascript anticipated a couple of these features before other mainstream languages, and now it's moving beyond web browsers. So yeah, with some reservations I'd call it serious.
Nowadays I'd never write major code in a language that doesn't directly support most of the "serious" features I listed above; it would be too much of a hit to my productivity. It would feel like building a house with a hammer and nails when nailguns were readily available.
If I were writing embedded apps like flight controls today, I'd use Lisp for the high-level parts and Rust and maybe a bit of assembler for the low level parts.
The "serious" professional choice for my company (an OS vendor, with a focus on certifiable systems) is currently C. The tooling we use is for C, the expertise within my company is in C, and the industry that we work with understands and expects C.
At some point, the operating systems industry will transition to more modern languages. Rust is promising, but it is a long way from being a serious consideration for FAA certifiable projects.
Same for C++.
Javas functions aren't first class, but only to the extent that there's some syntactic sugar.
I can't tell if you think JS is not a serious programming language.