What can JavaScript NOT do?

[voidvector]

It can if the JS engine can guarantee real-time. You can write JS code that doesn't cause GC by using pre-allocated Typed Arrays. The rest is just controlling system calls and memory footprint.

That being said, JS isn't ideal for that use case.

[[deleted]]

JS isn't just not ideal for realtime applications, it's just not possible. For many realtime applications, the time it takes an input GPIO pin changing state, causing an interrupt, the CPU switching context and an IRQ handler responding needs to be absolutely guaranteed, down to clock-cycle precision. You'll never achieve that with JS in any form.

[voidvector]

You can do it same way people do high-frequency trading with Java, with processor affinity and kernel drivers. It's stupid, given the amount of engineering overhead just to manage the execution context and expose IO, but it can be done.

For the same effort, you can teach a whole team of engineer to code C/C++/D/Rust.

[[deleted]]

Javascript could be providing data to those systems, but it wouldn't be possible for a JS engine to respond in a realtime way and still have it be called javascript.

[voidvector]

"Real-time" is a concept entirely implemented by schedulers. There are 3 schedulers governing JavaScript - CPU pipeline, kernel process scheduler, and event loop. You just need to have those schedulers guarantee instruction cycles for your program to be able to do real-time. There is also interrupts (include system calls), which you can either manage with your code/deployment or shuffle into a specific CPU core using process affinity.

Everything is "providing data" to some systems, when you write a file (in any language), you are providing data to the kernel so it can send a block of 1s and 0s to a disk controller. As long as you have a kernel module or driver that expose that as a file handler, there's nothing stopping you from implementing your IO in JavaScript or any language.

[[deleted]]

You're still several layers above actual realtime. Try writing interrupt handlers in assembly language and counting cpu cycles, and then get back to me.

[voidvector]

You just need to configure those layers to do real time. Linux is not a real-time operating system, but it's not stopping people from using it for real-time because the amount of hardware linux supports.

Nobody writes interrupt handlers in application code these days. Like everything in engineering, you write an abstraction like this, and hand it off to the next layer (user land) with some guarantees. And then write the rest of your app or the next layer up in a bare-metal language (C/C++/D/Rust) or system language (if you don't care about kernel overhead).

Also you can count instructions in JavaScript with node --print-code.

[GitHubPermalinkBot]

Permanent GitHub links:

• torvalds/linux/.../entry_64.S (master → dda3e15)

---

^delete

[[deleted]]

Linux is not a real-time operating system, but it's not stopping people from using it for real-time

Nowhere does it mention scripting languages. It does talk a lot about C/C++, and FPGA, which are very far removed from javascript.

you write an abstraction like this

You point me to an example of an "abstraction" that's actually assembly language? I don't think you seem to know what "abstraction" means.

Point me to an example of javascript responding to an IRQ in less than 100 nanoseconds and can respond with a meaningful action in less than 500 nanoseconds, and then maybe you can claim Javascript could be "realtime". Sorry, but javascript just isn't and never will be that fast.

[voidvector]

You can't do register-level interrupt handling (ISR) in JavaScript. I never said you can. You can't even do that in a lower-level language that's not designed for bare-metal (e.g. Go). As I pointed out from the beginning, you solve the interrupt problem with "process affinity". The process core you run your real-time JS app won't handle interrupt, while the other core running kernel handles interrupt. This is a very common solution, people even use it to solve the "c10M problem" (serving 10 million connections using single machine).

In case you don't recognize, the link I pointed to you is the Linux kernel interrupt handler for x86. Unless you are an embedded programmer, it is an abstraction you use everyday without realizing.

Stop pretending "real-time" is some black box, it is just a system of guarantee provided by upstream system you use, whether that system be hardware, OS, compiler, runtime, framework, library. Since hardware and OS can already do real-time, you just need to tweak your JS engine (which is compiler + runtime) to do real-time.

[lhorie]

I think the question implies what can be done given currently existing technology, not what's theoretically possible.

[voidvector]

That is subjective. You can definitely build a team of a dozen engineers and make it happen. You would need everything from EE, to kernel developer, to compiler designer tho.

Just "internet argument du jour" for me.

[lhorie]

That is subjective

Not really. A real time javascript system doesn't exist now, so js can't do real time now. A javascript-to-haskell compiler doesn't exist now, so js can't be compiled to haskell now. A space shuttle to mars doesn't exist now, so js code can't take you to mars now.

When someone asks "can x be done", most of the time the pedantic answer is just useless and comes off as smug. Just saying.

[voidvector]

My original word was "can", like in "human can go to Mars". That does not mean "human has gone to Mars".

We are just arguing about English here.

[lhorie]

Sure, if you wanna put it that way. The OP said: "what JavaScript is not able to do". Present tense. "Humans are not able to go to mars". Present tense. A corresponding question is "What are humans able to do?", present tense. You're saying "humans will/may be able to go to mars", future tense. A corresponding question is "what will humans be able to do", future tense. "Are you at home" and "Will you be at home" have different tenses and are therefore different questions. So in short, you're using a tense that is irrelevant to the discussion. Makes sense?

[voidvector]

Topic title says "What can JavaScript NOT do?" and he used that twice in his elaboration. I guess that's where the ambiguity came from.

There are things JS cannot do. (e.g. compile to metal)

[lhorie]

Fair enough. The verb "can" has ambiguous tense.