3 ms·

If there has to be a scripting runtime on a device that sits at a Lagrange point, I’d much rather have it be JavaScript than e.g. Python or Ruby. JS runtimes a

by pavlov 4y ago

If there has to be a scripting runtime on a device that sits at a Lagrange point, I’d much rather have it be JavaScript than e.g. Python or Ruby. JS runtimes are so widely used that they’re extremely well debugged and very fast. The language standard library is tiny, which means much less surface for bugs compared to the hulking default dependency monstrosities of those other languages. As long as you don’t use anything from the Node or web browser ecosystems, JavaScript is a great embedded scripting language. (Of course everything goes to hell if you bring in node_modules or try to support the bad APIs from browsers.)

codethief 4y ago
> As long as you don’t use anything from the Node or web browser ecosystems So what are you using then?
- campbel 4y ago
  You can write custom JS bindings for C++ with V8. So you could expose some functionality that way and then implement routines in JS.
- pavlov 4y ago
  Either custom embedding in a native app (JavaScriptCore or V8 directly, or a runtime wrapper abstraction like FB's JSI), or plain Node with extreme prejudice against anything from the npm pits of hell.
- mftb 4y ago
  JS, particularly in the era discussed here, only came with a small number of standard objects. The Host was expected to provide a series of Host Objects. In a browser these might be things like Window, Document and XMLHttpRequest. Scanning the linked article on the JWST it seems these might be things like Command and Telemetry, that would be written in C++, and then scripted in JS.
  - BeefWellington 4y ago
    Having worked on an embedded script engine that was JS-based at the time, this is exactly what we were doing. Basically the script host (C++ code) offered up specific sets of available objects to the engine that you could interact with and essentially trigger the C++ functionality from, passing in data, and such. It wasn't a fantastic experience at the time but luckily for us the stakes were pretty low as we were working on interactive mall map kiosk devices.
    - mftb 4y ago
      Yea, me too. Sounds like we've chewed some of the same, "programming dirt".
peanut_worm 4y ago
I think it is running a very old proprietary interpreter based on some old engine called ScriptEase.
halfmatthalfcat 4y ago
Do we need the constant npm/node_modules hyperbole? HN has an obsession with dogging the ecosystem and it's usually from those who have never shipped a large JS project, let alone understand how or why things are the way they are.
- cxr 4y ago
  > it's usually from those who have never shipped a large JS project What do you have to say to those who have? I have worked in large JS codebases that predate NodeJS's cannibalization of JS, and it's precisely why I deride the former—because I know from firsthand experience that it doesn't have to be the way that it is, and there are tons of people (too many) operating on the misconception that JS=Node (and inducing others to make the same mistake). Even this article from The Verge contributes misdirected scorn by linking, of all things, to... Maciej Cegłowski's talk about "The Website Obesity Crisis" (wat). It would be one thing if the person you were replying to had shown up to write "lol leftpad good luck", but that's not what's going on. It's the opposite of that.
  - halfmatthalfcat 4y ago
    You completely omit (conveniently) how browsers have evolved over the past decade, how business requirements have changed (and become more complex) and how npm itself (you could argue the entire JS ecosystem, along with language changes) has changed. Cool, things use to be easier when you were working pre-Node dominance but you weren't shipping the complex interaction patterns that have resulted in the ecosystem we have today. So frustrating to have conversations with those who have no perspective or context on the why and rest on their laurels of old when "things were easier". Good grief.
    - cxr 4y ago
      > You completely omit (conveniently) how browsers have evolved over the past decade Why would I talk about that? The article is about the James Webb Space Telescope, not the James Webb Browser. Aside from that, this is rooted at the mention of "node_modules", which is a NodeJS-ism; browsers don't even run NodeJS modules (unless you recompile them to standard JS), so browsers are doubly irrelevant... > and how npm itself (you could argue the entire JS ecosystem, along with language changes) has changed I didn't omit that. I was very explicit about NodeJS cannibalizing JS. > So frustrating to have conversations with those who have no perspective or context on the why and rest on their laurels of old when "things were easier". You seem to have me confused with someone else. (Talk about "context"!) Where does that quote from? It looks like you made it up.
Banana699 4y ago
No, actually. JS wasn't designed to be generally and minimally embeddable, it was a hack designed to be a embedded in a proprietary program with lots of bells and whistles. You can say that a thing doesn't have to be designed for something to do it good if the users are crafty enough, but then what's the point? Python or Ruby would have equally served the role, none of the 3 languages were designed to be lightweight embeddable. The point about JS runtimes having more eyeballs and corporate support than most other language is fair, but the actual facts in OP make it moot : JS is used because of, what else?, legacy reasons. The decision was made in 2003-2004. That's, I think, barely after or during the first standard of JS, and when all the runtimes available were very buggy and divergent in behaviour. In reality, there are plenty of interpreters you can embed and be very sure you're not making a mistake. Lisp and Forth are the top of that list, forth far ahead of lisp (literally designed to be used in embedded systems, and much simpler and lower-lever than most lisps). After that, there is Lua and Tcl, both explicitly designed to be embedded and extended, and lua specifically pushing words like "portable" and "lightweight" to the extremities. After that, you have Java (which runs on 3 billion devices!) and even Python, which has micro-variants running on higher end embedded Linux devices. JS is at around this tier.
- Yoric 4y ago
  I generally agree with you. However, note that JS, with all its warts, has the benefit that its security model has been studied in the harshest conditions for 20+ years. I can't think of any other scripting language that has been battle-tested nearly as much.
  - cxr 4y ago
    Not particularly relevant to this use case.
    - Yoric 4y ago
      Fair enough, I should have written "safety" instead of "security". Because you really don't want a script written by a end-user to crash down your $10B / 20 years of planned mission hardware.
dahfizz 4y ago
Except they are using an ancient, bespoke runtime. JS sucks, but V8 is an incredible piece of engineering. That is true. But they aren't using V8.
- svnpenn 4y ago
  V8 is a bloated hog that basically changes every time you blink. A maintenance nightmare in any sense of the word.
titzer 4y ago
As a former V8 engineer, I was actually relieved that they were not running V8. V8 would be overkill for their needs. > JS runtimes are so widely used that they’re extremely well debugged and very fast. This would be true if these systems weren't constantly changing, both because the language keeps evolving and the runtime techniques keep evolving. The truth is that JS runtimes are extraordinarily complicated pieces of software, and they have bugs, sometimes very subtle ones. Sometimes bugs have been hiding for years, and sometimes they are new. This despite being developed by some of the best engineers I have ever worked with, being daily pounded on by billions of people, and fuzzers with thousands of cores.
- Yoric 4y ago
  > This would be true if these systems weren't constantly changing, both because the language keeps evolving and the runtime techniques keep evolving. Seconded as a former SpiderMonkey engineer. As a safety guy, trusting an optimizing JIT is the stuff of my (professional) nightmares and the fact that the language keeps evolving, has semantics that very few people on Earth actually understand fully and that (very smart) developers keep cramming new optimizations within them. Oh, and add to that the fact that they're pretty much all written in C++, which is already the stuff of nightmares for safety professionals, and that they rely on garbage-collectors that need to walk both JavaScript and C++ heaps. I would trust a small, certified, non-optimizing implementation of a JS runtime much more than any of the juggernauts out there.
  - jancsika 4y ago
    Digression, just curious-- what do you think of Bellard's QuickJS?
    - jerrysievert 4y ago
      I'm not the v8 engineer, but I do maintain software that embeds v8. quickjs is a breath of fresh air compared to using v8. it's missing some features that v8 has (isolates, etc), but has an extremely fast startup, an api that doesn't change constantly, and is much much much smaller/easier to build.
NelsonMinar 4y ago
Lua might be a good choice for this application. I'm just glad there's a scripting environment at all instead of a bunch of custom compiled 16 bit C code.
bhedgeoser 4y ago
But JS bad!!!
insane_dreamer 4y ago
agreed on the runtime, but for non-engineers to write scripts in, Ruby would have been a better choice IMO; I also wouldn't call the Ruby runtime a hulking monstrosity (Python I agree is much more extensive)
- deleted 4y ago
  [deleted]
BeefWellington 4y ago
These systems were decided upon in 2003 according to the article, so that's a very different landscape when it comes to "well understood and debuggable" and the language features of the day. As for speed, yeah, that wasn't a feather in JS' cap in 2003. It was notoriously slow and awful in even cases where the script engine was embedded into decently written compiled code. V8 wasn't an option because it couldn't have been for another five years. Regarding the standard library being small, that's not really about the language but about the deployment of it. V8 offers standard library features you don't get in browser-based JS, you get different things in .NET Core vs .NET Framework, you get a different experience compiling C++ on glibC vs MSVC++'s STL, OpenJDK vs Oracle JDK, etc., etc. Those aren't strictly language features. You could take Python and rip out all of its standard library in order to have a more "pure" language approach. Clearly it met specific requirements that the engineers had as a scripting language than others, so it's getting the job done. I just don't think your overall points are actually based in the reality of Javascript as a language in 2003.

by pavlov 4y ago

codethief 4y ago

> As long as you don’t use anything from the Node or web browser ecosystems So what are you using then?

campbel 4y ago
You can write custom JS bindings for C++ with V8. So you could expose some functionality that way and then implement routines in JS.
pavlov 4y ago
Either custom embedding in a native app (JavaScriptCore or V8 directly, or a runtime wrapper abstraction like FB's JSI), or plain Node with extreme prejudice against anything from the npm pits of hell.
mftb 4y ago
JS, particularly in the era discussed here, only came with a small number of standard objects. The Host was expected to provide a series of Host Objects. In a browser these might be things like Window, Document and XMLHttpRequest. Scanning the linked article on the JWST it seems these might be things like Command and Telemetry, that would be written in C++, and then scripted in JS.
- BeefWellington 4y ago
  Having worked on an embedded script engine that was JS-based at the time, this is exactly what we were doing. Basically the script host (C++ code) offered up specific sets of available objects to the engine that you could interact with and essentially trigger the C++ functionality from, passing in data, and such. It wasn't a fantastic experience at the time but luckily for us the stakes were pretty low as we were working on interactive mall map kiosk devices.
  - mftb 4y ago
    Yea, me too. Sounds like we've chewed some of the same, "programming dirt".

peanut_worm 4y ago

I think it is running a very old proprietary interpreter based on some old engine called ScriptEase.

halfmatthalfcat 4y ago

Do we need the constant npm/node_modules hyperbole? HN has an obsession with dogging the ecosystem and it's usually from those who have never shipped a large JS project, let alone understand how or why things are the way they are.

cxr 4y ago
> it's usually from those who have never shipped a large JS project What do you have to say to those who have? I have worked in large JS codebases that predate NodeJS's cannibalization of JS, and it's precisely why I deride the former—because I know from firsthand experience that it doesn't have to be the way that it is, and there are tons of people (too many) operating on the misconception that JS=Node (and inducing others to make the same mistake). Even this article from The Verge contributes misdirected scorn by linking, of all things, to... Maciej Cegłowski's talk about "The Website Obesity Crisis" (wat). It would be one thing if the person you were replying to had shown up to write "lol leftpad good luck", but that's not what's going on. It's the opposite of that.
- halfmatthalfcat 4y ago
  You completely omit (conveniently) how browsers have evolved over the past decade, how business requirements have changed (and become more complex) and how npm itself (you could argue the entire JS ecosystem, along with language changes) has changed. Cool, things use to be easier when you were working pre-Node dominance but you weren't shipping the complex interaction patterns that have resulted in the ecosystem we have today. So frustrating to have conversations with those who have no perspective or context on the why and rest on their laurels of old when "things were easier". Good grief.
  - cxr 4y ago
    > You completely omit (conveniently) how browsers have evolved over the past decade Why would I talk about that? The article is about the James Webb Space Telescope, not the James Webb Browser. Aside from that, this is rooted at the mention of "node_modules", which is a NodeJS-ism; browsers don't even run NodeJS modules (unless you recompile them to standard JS), so browsers are doubly irrelevant... > and how npm itself (you could argue the entire JS ecosystem, along with language changes) has changed I didn't omit that. I was very explicit about NodeJS cannibalizing JS. > So frustrating to have conversations with those who have no perspective or context on the why and rest on their laurels of old when "things were easier". You seem to have me confused with someone else. (Talk about "context"!) Where does that quote from? It looks like you made it up.

Banana699 4y ago

No, actually. JS wasn't designed to be generally and minimally embeddable, it was a hack designed to be a embedded in a proprietary program with lots of bells and whistles. You can say that a thing doesn't have to be designed for something to do it good if the users are crafty enough, but then what's the point? Python or Ruby would have equally served the role, none of the 3 languages were designed to be lightweight embeddable. The point about JS runtimes having more eyeballs and corporate support than most other language is fair, but the actual facts in OP make it moot : JS is used because of, what else?, legacy reasons. The decision was made in 2003-2004. That's, I think, barely after or during the first standard of JS, and when all the runtimes available were very buggy and divergent in behaviour. In reality, there are plenty of interpreters you can embed and be very sure you're not making a mistake. Lisp and Forth are the top of that list, forth far ahead of lisp (literally designed to be used in embedded systems, and much simpler and lower-lever than most lisps). After that, there is Lua and Tcl, both explicitly designed to be embedded and extended, and lua specifically pushing words like "portable" and "lightweight" to the extremities. After that, you have Java (which runs on 3 billion devices!) and even Python, which has micro-variants running on higher end embedded Linux devices. JS is at around this tier.

Yoric 4y ago
I generally agree with you. However, note that JS, with all its warts, has the benefit that its security model has been studied in the harshest conditions for 20+ years. I can't think of any other scripting language that has been battle-tested nearly as much.
- cxr 4y ago
  Not particularly relevant to this use case.
  - Yoric 4y ago
    Fair enough, I should have written "safety" instead of "security". Because you really don't want a script written by a end-user to crash down your $10B / 20 years of planned mission hardware.

dahfizz 4y ago

Except they are using an ancient, bespoke runtime. JS sucks, but V8 is an incredible piece of engineering. That is true. But they aren't using V8.

svnpenn 4y ago
V8 is a bloated hog that basically changes every time you blink. A maintenance nightmare in any sense of the word.

titzer 4y ago

As a former V8 engineer, I was actually relieved that they were not running V8. V8 would be overkill for their needs. > JS runtimes are so widely used that they’re extremely well debugged and very fast. This would be true if these systems weren't constantly changing, both because the language keeps evolving and the runtime techniques keep evolving. The truth is that JS runtimes are extraordinarily complicated pieces of software, and they have bugs, sometimes very subtle ones. Sometimes bugs have been hiding for years, and sometimes they are new. This despite being developed by some of the best engineers I have ever worked with, being daily pounded on by billions of people, and fuzzers with thousands of cores.

Yoric 4y ago
> This would be true if these systems weren't constantly changing, both because the language keeps evolving and the runtime techniques keep evolving. Seconded as a former SpiderMonkey engineer. As a safety guy, trusting an optimizing JIT is the stuff of my (professional) nightmares and the fact that the language keeps evolving, has semantics that very few people on Earth actually understand fully and that (very smart) developers keep cramming new optimizations within them. Oh, and add to that the fact that they're pretty much all written in C++, which is already the stuff of nightmares for safety professionals, and that they rely on garbage-collectors that need to walk both JavaScript and C++ heaps. I would trust a small, certified, non-optimizing implementation of a JS runtime much more than any of the juggernauts out there.
- jancsika 4y ago
  Digression, just curious-- what do you think of Bellard's QuickJS?
  - jerrysievert 4y ago
    I'm not the v8 engineer, but I do maintain software that embeds v8. quickjs is a breath of fresh air compared to using v8. it's missing some features that v8 has (isolates, etc), but has an extremely fast startup, an api that doesn't change constantly, and is much much much smaller/easier to build.

NelsonMinar 4y ago

Lua might be a good choice for this application. I'm just glad there's a scripting environment at all instead of a bunch of custom compiled 16 bit C code.

bhedgeoser 4y ago

But JS bad!!!

insane_dreamer 4y ago

agreed on the runtime, but for non-engineers to write scripts in, Ruby would have been a better choice IMO; I also wouldn't call the Ruby runtime a hulking monstrosity (Python I agree is much more extensive)

deleted 4y ago
[deleted]

BeefWellington 4y ago

These systems were decided upon in 2003 according to the article, so that's a very different landscape when it comes to "well understood and debuggable" and the language features of the day. As for speed, yeah, that wasn't a feather in JS' cap in 2003. It was notoriously slow and awful in even cases where the script engine was embedded into decently written compiled code. V8 wasn't an option because it couldn't have been for another five years. Regarding the standard library being small, that's not really about the language but about the deployment of it. V8 offers standard library features you don't get in browser-based JS, you get different things in .NET Core vs .NET Framework, you get a different experience compiling C++ on glibC vs MSVC++'s STL, OpenJDK vs Oracle JDK, etc., etc. Those aren't strictly language features. You could take Python and rip out all of its standard library in order to have a more "pure" language approach. Clearly it met specific requirements that the engineers had as a scripting language than others, so it's getting the job done. I just don't think your overall points are actually based in the reality of Javascript as a language in 2003.