4 ms·
Actually, I think there's a pretty good motivation behind this. When executing JS code in a browser, it runs inside a safe VM and can't touch any of the memory
by thegeomaster 12y ago
Actually, I think there's a pretty good motivation behind this.
When executing JS code in a browser, it runs inside a safe VM and can't touch any of the memory or variables that don't belong to it. However, the browser itself has to go through a lot of the abstractions and safeguards required by the kernel in order to run. Particularly, every syscall induces a context switch which costs a lot of CPU cycles. This happens on every operations that needs access to hardware, such as reading from a file or from a socket for IPC. Also, the kernel needs to update the MMU registers so it can map its own address space, invalidate the whole TLB, etc etc etc.
The basic idea here, it seems, is to avoid all these costs and build the system so the user can run nothing that isn't a VM. The VM will provide fail-safes and terminate offending code. This allows everything to run in a single address space and under ring 0, thus avoiding context switching.
This is beneficial to (and only to) code that we used to run under a browser or some kind of JS virtual machine (Node.JS servers come to my mind here). Web apps such as editors (Atom maybe?) or any other kind can now run natively and run way faster, which is very important on low-cost low-end machines, without all the overhead that they know pay twice (first to virtualize JS from everything else, and then to virtualize the browser processes). However, the raw performance that can be gained from writing fast C/C++ code will essentially be lost. The more JS code you were running before, the more a naked metal JavaScript OS will benefit you.
It's not clear to me if this will ever be necessary. What I just said is the justification of the idea, just from the top of my mind. Anyone feel free to correct me if I screwed up the argument :)
- serge2k 12y agoIt's a cool idea, why implement it in a shitty language?
- thegeomaster 12y agoBecause, sadly, everyone is hopping on the JavaScript bandwagon. But it's not as bad as it seems. There is CoffeeScript which is IMHO a considerably better language, and there is ClojureScript which brings the wonders of Lisps into JS. And for simple webapp logic I can tolerate JavaScript. It's also an uncomfortable but true fact that JavaScript is today one of the most-used languages in the realm of forward-driving forces of tech (that would be the startups). Most GitHub repos are in JS, too. However, the lack of integers will always be my pet peeve, and I really can't imagine how could someone arrive at such a horrible idea.
- TheZenPsycho 12y agobut coffeescript IS exactly javascript with a bad syntax translator. It' not a "considerably better language" it's the same language.
- fetbaffe 12y agoDepending on your use case, you can use Int32Array https://developer.mozilla.org/en-US/docs/Web/API/Int32Array https://developer.mozilla.org/en-US/docs/Web/API/Int32Array
- LunaSea 12y agoCoffeeScript is just an unreadable JavaScript version with additional bugs and a smaller community.
- fetbaffe 12y agoBecause almost all the other shitty languages already have projects like this.
- lallysingh 12y agoOK, so this is to generate, essentially VM images to run in a hypervisor? And is useful if you've got something like a node.js app that you want to run? I can see that. I don't see the argument for "security, reliability and performance." First for oxford-comma reasons, next in terms of comparison with a kernel written in other languages, and finally in terms of JS. But if you have to use JS, and you want to run something like a serving appliance VM, I can see how this could make things faster. Although calling in and out of native code should be quite fast on a JS engine, and using existing drivers and network stacks written in native code should be substantially faster, more reliable, and more stable than rewriting them in JS.