This is something I have been working on as part of a larger project where we use it for programmatic test generation. This extended syntax allows the inclusion of type information within a document.

This means that after parsing, a user-defined deserializer can pick up the raw value and do anything with it (whatever it returns is included in the output of `parse`), and that a user-defined validator can allow or reject it with an error.

Documentation (mainly for deserializers/validators) is currently sparse since I'm somewhat busy with a deadline, the tests have many examples though. I plan to expand on it later.

Here is a glance at what it looks like: ``` { x: date "2001-01-01", // it can handle custom deserializers! y: 123n, // it can handle `BigInt` out of the box! z: /^I\sCAN\sPARSE\sREGEX$/im, // ...and also regular expressions! w: undefined, // ...and even `undefined`! } ```

There are more examples on GitHub!

I use CLion, I intentionally edited the Java VM settings to allow it to consume more memory.

It takes forever to analyse symbols for WebKit otherwise. WebKit is too massive to handle with the default memory limits.

Try writing a raytracer using a single thread, now try again with multiple threads working in tandem.

Trust me, I tried.

If you need that level of performance then JavaScript is the wrong tool for the job.

Node is mostly for request/response scenarios such as a web server or REST API server etc.

That's exactly what I'm trying to change. JavaScript should be the right tool for that level of performance. It has JIT compilers, now it needs concurrency, and it'll perform with the best of them.

Javascript has mostly web programmers as a community. I'm not sure they have the same mindset as people who normally try to wring out the most performance from their machines. Even QBasic programmers knew how to turn to machine code for more performance. Nowadays the culture is "megahertz are cheap". That is the kind of culture that leads to e.g. Microsoft making an IOT operating system for the PI that weighs half a gigabyte and does not do much. Or people thinking that a 1 Ghz system with 512MB of RAM is too slow and is only good for browsing the Web and a 300 MHz system with 128MB of RAM is useless nowadays. These were once called workstations back in the day.

If you're trying to push Javascript to its limits and make it comparable to C++, good for you. Just remember that JS has many flaws.If you're going down that road I'd much prefer you give the world a Turbo javascript that comes with an IDE like Turbo C and the requisite documentation that all fit on a single 1.44MB disk and which can compile to directly executable code that doesn't need any runtime.

For that specific problem you could use the upcoming addition to JS of SIMD for data parallelism while still in single threaded JS.

Yeah, they're all executing on different cores.

But why then are there skipped (empty) lines on the console (that seem to correspond to the parallel executions)? Strange behaviour.

This happens when there is no synchronization involved, the engine is printing line endings in a separate operation, so they come out weird like that. I'll add a mutex locking mechanism on console I/O at some point in the future.

I see. One advantage over web workers is that the DOM would be accesible so this could be used to speed up views rendering.

We said no, the lawyer told him so, he asked for direct contact details and we haven't heard anything from him yet.