Is there any plan on rewriting Cryptomator to Rust?
I suppose the benefits of coming off JVM, with better performance, safety and stability.
Maybe even easier implementation of further features like adding support to U2F/FIDO2 keys, etc…
I think this would make Cryptomator even more sought after. As anything with rust, seems to give a better feel/usage, that’s considering every new tool replacing older ones. Surely it can bring more interest from outside.
To be honest, at least me (and I dont think that’s only with me), when I see something written in java, I usually try to see if there is another better option. Maybe due to expectancy of being buggy, even though I know that’s not dependant on the stack itself. What I mean is that doesnt feel that there is trust behind it.
Sigh, i guess, sooner or later, someone would have asked the question. Here is the short answer:
So, to answer your question:
No.
Rewriting a project like Cryptomator is a huge task, requiring tremendous effort. You see, Cryptomator is not just this one github repo. There are several repositories (around 8 currently, with a bunch already archived), each serving a specific purpose in the Cryptomator Desktop app. You don’t only need to rewrite the deskop app, you would also need to rewrite all those libraries (or come up with better ideas ). The tooling needs to change too, you need people who are able to write Rust and people who manage this whole rewrite. Surely, it can be done with the right amount of resources (including people, time and tools), but currently, this is out of scope.
That said, we work on changing the architecture of Cryptomator, such that each unlocked vault runs in its own process. This would allow to write a rust-based Cryptofilesystem executable and call it from the whatever-language GUI of Cryptomator.
And regarding
You suppose wrong. First of all, you can programm nonsens in every language. Changing the language does not magically prevent logic errors like “first i eat the banana, then i peel it”. These rely on other factors like the testing strategy, peer reviews, project management.
Second, the greatest benefit of Rust is memory safety. Additionally, due to borrowing, concurrency problems are mitigated, if not resolved. But in comparsion to Java, the first benefit is void, since due to external memory management by the garbage collector, Java is also memory safe. And for the second one, Java has excellent tools for handling concurrency (see the concurrent package) and works continously to improve the situation (see structured concurrency).
And third, to speak about performance, i’d like to link a discussion on the officail rust forum and comment specifcally:
Of course there is room for improvement and i myself believe, that writing OS integrations with Rust would increase performance. But there are smaller screws to turn for a higher benefit.
). The tooling needs to change too, you need people who are able to write Rust and people who manage this whole rewrite. Surely, it can be done with the right amount of resources (including people, time and tools), but currently, this is out of scope.