Python, for everyday scripting of everything.
Lua for embedding in C + C++.
My jaw drops with running JS on the server - Node and all that. Just because the JS JIT runs fast does not mean you should use JS outside of the browser.
Ive never seen a Node setup which could nto be done better, faster and safer than using Elixir/ErlangOTP.
This summer I spent a full month re-learning JS (I'm old). You may not be aware that many of the bad things in JS have been corrected or superseded by updates, particularly ES6. A lot of new/old programming capabilities have appeared too, and transpiling allows anyone to use modern JS without having to manually refactor for old browsers. There's even plans to introduce things like 'await' to the language, if you can believe it. So, over time your objections (tho valid) are becoming less and less relevant.
I'm not saying JS should be in servers because I'm not competent to judge. But Node is, as far as I can tell, not really meant as a server language but as an ecosystem for open source dev tools. For that usage it seems to be more than adequate. Node also has the huge advantage of running in a language known to millions, albeit many with only superficial understanding. It lowers the bar enough that almost anyone can contribute, which has caused an embarrassment of riches regarding tool selection, oy.
Finally, it ain't going away soon, due to browser inertia. That's why so much effort is spent on improving it. I'm betting in a few more years you won't see that much difference between JS and Python.
I’d guess you have never actually given it a good go. Most people who hold this opinion have always held this opinion (or heard it somewhere) and maybe hacked around with it in the past but tried to treat it like their primary language. Once you figure out which parts are “the good parts” and which parts to stay away from it is a really amazing, or at least interesting, expressive language.
"ES2016 formalised that into "promises""
Yeah whatever, more nomenclature buzzword bollocks lingo.
"we added language mechanisms that let a programmer call a function and asynchronously delay or wait for that function to complete"
So its basically threading in disguise. *yawn*
"The other big feature is shared memory."
Wow, cutting edge stuff! In 1980.
"It has evolved into the general-purpose programming language that advocates originally envisioned,"
You forgot its main use is breaking web sites - "web devs" - you do not need JS to display test, process a link click - your site should do that with JS enabled
And the extra delay in loading in all those huge frameworks just to do a bit of DOM twiddling, and (high) chance of some broken JS taht hogs memory and cripples performance.
There is very little need for lots of web site JS
And with JS enabled always the lottery of seeing what malware randonm ad js is trying to chuck at you.
So its basically threading in disguise.
No, not really.
Premises are Good Old Stuff: Promises.
Oh well, Java 9 is out, time to go steady.
"No, not really."
Yes really. If a program has more than 1 simultanious execution path its either threads or processes, take your pick. The end result ultimately is the same for the programmer. Sure, "promises" might mean you don't have to fiddle about with mutexes and whatnot but other than that there's no difference. Same wine, different label.
"Writing a web app in C++ is just stupid if you ask me"
Depends whats going on underneath. The client facing browser side is just the icing on the cake, it gets all the attention but there's usually a whole lot more going on below. If you need some fast DB access and industrial strength data processing then there's nothing wrong with using C++ especially since you don't have the VM overhead and memory hogging of Java or C#.
I'm posting this anonymously as I still work as a web dev and have for over 12 years.
I think JS is perceived as "cool" especially to a lot of younger developers. And it's started to make its way on to servers with things like Node, so also appeals to wannabe-sysadmin types who have made an alert on a web page before.
For me it just seems inappropriate for about 90% of the things it's used for. Or, there are better ways.
I believe the future is C/C++ in browser natively.
Regardless, 6 months ago I dove in using the latest node.js enabling all beta features and all the latest browsers, I wanted the full effect regardless of compatibility. I used zero libraries in the browser and only 2 core libs for node. Here's a short on what you're missing...
By core dependancies, I mean as in no depedacies on other libraries. Node libraries have HUGE dependcies on other libs if you don't watch out (look up the lib "Express", it's bloooooated). To be honest, node.js isn't bad as a server language once you stop using crazy libs like Express, but the pratice of intentionally crashing without any trusted way of validating input prior to crash becomes stunting.
The hype is justified for I believe that the ease of creating interactive widgets makes it tinkery fun. The real drawback is memory usage. I don't care if it's serial, parallel, interstellar or orgasmic... the memory usage of even a simple waveform analyzer after render is large. It all apparently comes down to the broswers' garbage collection, which more times than not, operates in JiT so memory comsumption just seems to linger regardless of what js methods you use on the graphical objects (drag'n drop is ok, just don't drag and drop graphical collections and expect even decent memory usage).
"I think JS is perceived as "cool" especially to a lot of younger developers." As it has a very low bar to use on the browser and now on the backend, it is easy to get involved with. Like back last century for me, for enhancing user interactions with lists. (woo)
"... and just seems really obsessed with it." That enabling immediate response to users can be rewarding and addictive for devs should be obvious. I'm surprised you haven't noticed.
"For me it just seems inappropriate for about 90% of the things it's used for. Or, there are better ways." Mmm, okay John Henry, don't have a heart attack.
"As it has a very low bar to use on the browser...."
Right there is the problem! jquery users who have no real footwork with memory managemen. Let us generalize that "low bar".
Have you ever noticed how anything graphically intense rendered by the browser isn't running in js? The bar isn't low, it might be as high as it gets in pure js. In fact, js performs so terribly slow as DOM reflow/repaint is a horrible design (no, I sadly don't have a better solution), they had to invent "workers" to make any real interaction even tolerable. So, maybe the bar isn't low or high, maybe it just doesn't exist.
"That enabling immediate response to users..."
Again, a jquery comment. The problem is your just bloating the browers references for what... drop down menus? The heart of interactive js can't be done with jquery (even jquery devs understand that, regardless of the newer native methods). Once you try to do actual interactive designs in js you will understand why strict libraries like ASM.js have arose (and will undoubtedly be replaced by Mozzilla's push).
And it's started to make its way on to servers with things like Node
Until something else comes along to keep the hyperactive scriptlers with learning challenges busy and the managers on "muh scale-out, scale-up asynchronous web-scale" hype-drenaline.
Meanwhile, normal people will do stuff that actually works.
Using threads, for one.
Unfortunately this fashion for making even static pages into 'web apps' is essentially born of crashing ignorance. For example, I found today an online shop which declared that in the interest of security "our shopping cart runs entirely on the client, so there's no server to hack". Where do they think the shopping cart code resides at rest? What happens if that repository is contaminated by malicious actors?
Until software development has been raised to at least the minimum standard of a professional engineering discipline we remain at the mercy of fools and ignoramuses. Dunning and Kruger rule!
Biting the hand that feeds IT © 1998–2019