graaljs

The GraalJS license is apparently similar to MIT: https://github.com/graalvm/graaljs/blob/master/LICENSE "The Universal Permissive License (UPL), Version 1.0" And about the UPL: https://tldrlegal.com/license/universal-permissive-license-1... "... including an explicit patent grant, clear ability to relicense ..."

Hasn't Nashorn been superseded by GraalJS? Is this just for those who are stuck with Nashorn, or will there be new development? GraalJS is ECMASCript 2020 compatible and is said to rival V8 on performance, so I would've thought it the obvious choice for new projects going forward. https://github.com/graalvm/graaljs Edit: found more info about this release in the initial announcement: https://mail.openjdk.java.net/pipermail/nashorn-dev/2020-Oct...

> Can someone please give a sober explanation of what GraalVM, is and how Truffle works? GraalVM is basically a JVM with a new compiler, the Graal compiler. Truffle is the language implementation framework for GraalVM and designed to build AST interpreter. The Graal compiler can optimize Truffle ASTs through partial evaluation (see "One VM to rule them all" paper [1]), and produces machine code directly without using Java bytecode as IR. > how do JS semantics get expressed in a Java VM? Graal.js comes with a parser for JavaScript code that generates a Truffle ASTs for a given JavaScript program. JS semantics are defined within the AST nodes (see [2]). > What does a getProperty instruction look like? I think getProperty is implemented in `CachedGetPropertyNode` [3], but I am not sure as there are multiple other property-related nodes. > Ho

Bear in mind Deno isn't the only competitor. GraalJS can run all NPM modules on top of the JVM, in fact it supports both "pure" running JS on top of the JVM and also provides a mode in which it replaces V8 in the original Node binary, for extra compatibility with e.g. native extensions. This gives you at least three major tech wins: 1. Interop with the entire Java ecosystem and also as other Graal languages improve, with them too (e.g. Graal's Ruby support is pretty great, Python is maturing) 2. Extremely efficient and scalable pauseless garbage collectors. 3. Ability to do shared-memory multi-threading by sharing Java objects between workers. And soon via Project Loom there'll be very light weight fibers too i.e. you can write your code in a fully blocking style, no promises or async/await, but it'll be just as efficient as Node. It can

This benchmark mainly measures the performance of the HTTP parsing and database libraries, often in a suboptimal default configuration. In node land, they're admittedly not amazing, but nothing about the language prevents them from being better. For example, for a long time, the only reason that node was slow on these benchmarks was the built-in URL parser. Replacing it with this carefully written module https://www.npmjs.com/package/fast-url-parser resulted in 2x improvements on the benchmark. I haven't looked closely at the situation nowadays but I imagine its still quite similar with lots of low hanging fruit lying around and stalled due to backward-compatibility concerns. For proof find "es4x" in the benchmark list, which basically replaces the entire stack of HTTP parsing and database libraries with the ones from vert.x and runs JS o