On 5/13/19 11:21 PM, William Brown wrote:
Hi all, So it's been a while since I pushed this, but again, I think I want to bring this up. I'd like to write the new logging backend in Rust. I'll start with a summary: Pros: * Faster development time due to stricter code correctness guarantees * Modern and safe language to lower number of bugs in implementation * Much better libraries for interacting with things like json and thread safety Cons: * Another language in the codebase ... * We need to learn it to work on it * Vendors need to be ready to build with the toolchain I've talked through some of these thoughts with Mark a bit, and I really think it's time we did this - or gave up on pursuing it. I have been running the rust enabled version of ds for a few years now with no issues. SUSE is also in a position where they are able to and ready to build DS with Rust (I'm assuming RH could easily also be brought to parity here). So the main barrier becomes us: the most common argument is we don't know enough or have enough experience. However I think this argument is flawed, in the fact that there are many parts of the code where we already only have 1 or 2 experts in that area - often when we look into a bug or a feature, we always have to learn new things, we have to read the code, understand even the unique styles of how that was written for the time, and then do work. This would be no different. I think we are all capable of learning and working with these tools. By this point, Gnome is looking into Rust as a mainline part of the desktop, Samba has started to look into it, Firefox is already shipping Rust components. I think that Rust is here to stay, and is not some passing trend. So what do we think? I think if there are no major objections I would like to do this in Rust. I'll also commit to providing C-Rust FFI documentation for the team, resources to help understand what's going on, and like always, I will be sure to comment all my code thoroughly as part of this improvement.
I'm okay with using Rust
— Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs _______________________________________________ 389-devel mailing list -- 389-devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to 389-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-devel@xxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________ 389-devel mailing list -- 389-devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to 389-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-devel@xxxxxxxxxxxxxxxxxxxxxxx
