> Javascript doesn't have the size of build-in library. Golang is compiled and limited, blank spaces/tabs will kill a Python program. Ruby /rails is slower. I

> Javascript doesn't have the size of build-in library. Golang is compiled and limited, blank spaces/tabs will kill a Python program. Ruby /rails is slower. I have once heard an ancient prophecy (I think it's Greek) that says "Debating around PHP online summons the ghost of the dark behind your back" or something like that (I don't speak Greek, sorry). In the Client/Server world now days, the most of the time you only need one or two languages, one running on the Client side (JavaScript for example) and one running on the server (**, Go, Java, JavaScript etc). In that setting, JavaScript comes with the hard advantage of both-end compatibility, that gives you something like Server-side Rendering, which no other backend-only language could do, at least not "natively". If you have a foundation this good, people will build the library themselves when the language/runtime don't have it built-in. (the same is true when it comes to Swift/Dart/Kotlin. I bet there is someone/company out there writing both their app and their backend in Swift/Kotlin) For "backend-only" languages, it's largely down to personal/team preference. Some needs performance, some wants "write-friendly" (contains many factors). But the problem is, the market now days is saturated with better options that also do more things (often in a better way). When you bring all the options on the table, then suddenly that-language-the-name-we-shall-not-say started to look way less attractive. It's just that, comparison/competition kills things, no elite required.