The syntax example didn't look any different to what I'd see in modern Java, C#, Go, Rust, LISP, etc. The syntax can make or break the language for some (Rust f

The syntax example didn't look any different to what I'd see in modern Java, C#, Go, Rust, LISP, etc. The syntax can make or break the language for some (Rust for me) but in the end, if you sit down and look at it, most languages in use today will be similarly easy to read (except Haskell). It's not better that the example isn't even JS itself but rather the only JS dialect I don't refuse to work with since it has a type system that is more solid than wet tissue paper. As the author themself admit, syntax is not important, so why bring it up? That genuinely seems like a way to A) bring up the argument and B) in case anyone refutes the argument being able to simply say "well it didn't matter anyway". --- Toolchains are another bad point. VSCode doesn't only exist for JS, it has support for other languages as well and I very rarely make use of it as JS IDE. If I need a third-party toolchain to fix up the most basic mistakes of the language's design I don't think the language under that mess will be terribly good. Other languages don't require an entire toolchain to provide a minimum of coding safety. People agree that writing in C is something hard and dangerous, it also needs an entire toolchain to achieve a minimum of "not segfaulting on startup". I should be able to simply take the first party language tools and use those to get to a point where my application starts and the correctness of my code not being coerced to false. --- While it is indeed commendable that JS has such a big community, I think the community still has lessons to learn. The churn in the ecosystem is beyond fantastical levels, not in a good way. When I pull in sqlite3 for my project I can be reasonably sure that this project will be maintained for the next 20 decades and I will be able to use sqlite3 in 20 decades without much problem. With JS dependencies I will always ask myself subconsciously if they're going to be maintained next week. I don't write software that runs for next week, software I write is intended to function for the next 20 decades. Of course it'll get patched and maintained but I don't want to switch out my underlying framework because Google decided that their JS code has become too boring after 4 months of work. The GraphQL examples is just an example of this. The tech is barely 5 years old, the tooling in all languages other than JS was extremely immature last I checked. Why should I bet on something like that to work and be maintained in 20 years? --- I'm getting a bit rant-y but I'll take this last paragraph to disagree with the conclusion too. Most languages have some bad design. Usually that is fixed in the language or by first party tooling. That's not my problem with JS. My problem with JS is that the moment I write JS I have to involve myself with the community of JS, a community that has laughed (!) and scoffed (!) at me for suggesting that I want to maintain software for a long time beyond $CURRENT_YEAR. The ecosystem and community of JS are rotten and flawed, that's why I don't use JS where I possibly can and if I do it's vanilla browser JS pushed through the minimum installation of typescript I can get away with.