Among all others processing most intuitive and easy to learn lib for creative programming. Are there any plans to rewrite it in Rust for better speed and Wasm compatibility in the future?
2 Likes
No idea, but I’d doubt there’ll be a rewrite. The speed argument is seriously questionable - depends where the bottlenecks are. But Graal coming to the JVM brings up at least the possibility of writing a Rust mode for Java Processing that runs on the JVM, and compiling directly to native code, and targetting Wasm.
3 Likes
I think best to rewrite it in D. It’s very similar to java in syntax, 10 times faster and very readable
1 Like
@kokoo D is nice, but there’s no way it’s that much faster than Java in general. That would make it 5-10x faster than C! And most Processing sketches will not be CPU bound inside Java code anyway.
Not a rewrite, but there’s an alternative:
3 Likes
Processing(Java) is based on JVM. If we want to ship Processing in Rust, we have to implement it natively, similar to p5.js and p5.py.
Or we can wait until there is a Rust interpreter in JVM. Then interprete Rust code in JVM (similar to https://github.com/processing-r/Processing.R). The speed is low in this way.
BTW, nannou is really promising. Is it possible to port nannou on wasm?
As I said above, Graal already allows running Rust (and other LLVM languages) on the JVM, and it is not slow! The overhead is ~10%.
1 Like