Let the Marie Kondofication of programming languages begin.
But one of Kondo's points is that "Only you can know what kind of environment makes you happy," i.e. there are no universals.
The entire reason we have people trying to cram JavaScript everywhere is that, for some reason, it sparks joy for them.
Hell, even going back, K&R vs Allman brace style was about what sparked joy. Color themes? Spark joy. At this point, I am convinced that the way to get a software developer to do anything is to just play on that need for joy.
Wait really? I feel like it's just "you literally have no choice for frontend" and the various side effects of that.
Some might say it's Stockholm syndrome, but then there's the Python developers doing the same thing everywhere. And the LISP enthusiasts. So unless there's a lot of Stockholm syndrome (although it's not out of the question when it comes to LISP), a lot of it is easily explained by "me like language here, me go put language elsewhere to keep language"
The easiest way to turn front end developers into full stack developers was to let them use the same language for everything, and it was easier to bring JavaScript to the server than to bring any other language to the web.
These days with WASM and JavaScript as compilation targets it might have been avoided, but it's already too late.
Anyway I rambled a bit but the point is "joy" has nothing to do with it.
Any decent developer can become competent with a new language in a matter of weeks, whereas making a large application with the wrong choice of language and tooling can become a maintenance nightmare. Given how difficult it is to verify JavaScript programs as "correct", its use on the server has always riled me up.
I'm only going to address NodeJS because I think that niche projects that target niche workloads are just unrelated.
I believe it does explain NodeJS. The idea is simple - your frontend engineers can own your edge services/ APIs. They're already heavily invested in JS and, at least at one point, there was a theory that unifying languages across frontend + edge made sense for other reasons.
Some people really just learn one language.
I think that's a gross oversimplification. My colleagues know JavaScript, TypeScript and ECMAScript, as well as YAML, HTML and CSS.
Works outside software development too.
https://survey.stackoverflow.co/2023/#section-admired-and-de...
Haskell, Scheme, OCaml, SML, Rust, Typescript, Smalltalk, Java, Scala, Common Lisp, Kotlin, C, C++, C#, Javascript, Forth, Delphi/Object Pascal, Turbo Pascal, Python, BASIC (various flavors), Fortran.
How about you?
The intent was never to deploy it using SML, it was to flesh out and formalize the design, and act as a specification for development of the full system.
The system was designed to run on a cluster long before the Kubernetes days, and so had to deal with many of the distribution, scaling, and concurrency issues itself, in addition to its business logic.
One of the experiences I had while working on that system was that at the time, I was reading "Monad Transformers and Modular Interpreters" - a seminal paper by Liang, Hudak, and Jones - and I thought I could probably quite easily implement the paper's approach using ML parameterized modules, instead of the Haskell typeclasses used in the paper. I tried it, and was soon disabused of that notion. Partly as a result of that, we wrote the distributed simulation engine for a later version of the system in Haskell.
Rust, Typescript, C++, Go, Java, OCaml, Python, Javascript, Matlab, PHP, SystemVerilog, CMake, C, Bash
Ok I will make this site. :)
It is really unsurpassed in that regard, which is probably partly why it is so popular in DevOps. If only the language was a bit better...
It's definitely not a bad language like PHP though.
When doing critical thinking, please set asides your own biases and try to understand that your own viewpoint is not always the correct one.
In some ways, Python is in fact worse than many of the mainstream alternatives - for example, it's not unusual for people to look to rewrite Python systems in some other language because of performance issues at scale. Same (if not worse) goes for Ruby.
To each their own, I suppose.
do_something(a_thing);
Others are infix: x = a + b * c;
And yet others are postfix: foo.frobnicate()?;
My sole braincell can't handle all that complexity, which is why I'll just stick with simple old Lisp.