It's not something I'm eager to build off of, for a few reasons:
- Rainbow strives to be consistent with official Arc, in the sense that they can be used to run the same programs. It goes out of its way to implement Arc's warts, making it a more complicated language than it has to be.
- Rainbow.js strives to be consistent with Rainbow, this time in the sense that their code can be maintained side-by-side. I've gone out of my way to make the JavaScript code similar to the original Java code, even if it would have been easier to use more first-class functions or dynamic JavaScript compilation. And if I see a bug, I take note of it but I don't fix it.
- By necessity, I implemented some of the primitive I/O operations in terms of asynchronous JavaScript I/O. This opens up a window for other JavaScript code to run while the side effect is executing. I find it unclear how to make this consistent with either Rainbow or official Arc; both of them support preemptive threading, and yet neither of them spells out exactly which moments in the program are possible preemption points.
- I was only able to develop Rainbow.js because Rainbow was mostly stagnant. But the converse worries me: Since I developed Rainbow.js, it will take more work to update Rainbow (or Arc) because multiple implementations must follow along with the update. Seems standards processes are slow and frustratingly arbitrary for a reason. :)
