I agree with Galen. I'll add that my impression of Rust is that there's a lot of interest among developers but that it's not widely adopted or fully mature yet. I worry that our community is under-resourced for keeping up with dependency treadmills, and I'd want to feel confident that the investment is worth the tradeoffs in this case. So I am not necessarily opposed, but hesitant. That said, I do like Blake's point that adopting Rust could make the project more appealing.
Anecdotally, my sense is that C experience is not super rare (it still seems much more common than Rust experience to me). I am a lot more concerned about Perl than I am about C ... but this is probably not the thread for that discussion. :) Whichever language the community chooses, I am excited about the Redis development! I'm glad Bill has been pushing this forward. Jeff ________________________________________ From: Evergreen-dev <[email protected]> on behalf of Galen Charlton via Evergreen-dev <[email protected]> Sent: Thursday, June 1, 2023 6:09 AM To: Jason Boyer Cc: [email protected] Subject: Re: [Evergreen-dev] OpenSRF / Redis / Rust Hi, On Wed, May 31, 2023 at 11:08 AM Jason Boyer via Evergreen-dev <[email protected]<mailto:[email protected]>> wrote: > I know "should we replace all of the 'C'?" wasn't really Bill's original > question ... but I think this is the real question before us, or at least, close to it. If we move forward with the Rust router and websockets gateway and, two years from now, we find that that's all there is that's written in Rust, in my opinion it would not have been worth the concrete deployment and packaging issues we would run into, especially on Debian. Rust and Cargo are very much a moving target, and whatever you think of Debian's approach to packing the Rust build environment, Debian's notion of a stable version of Rust is clearly not new enough as compared to the rest of the Rust ecosystem. Now, it's not the end of the world if we have to live with using rustup to deploy on Debian, but that _is_ a tradeoff. Similarly, the crate ecosystem is in great flux. One of the things I discovered when I put Bill's branch out for a test drive today is that one of the major dependencies of the Rust opensrf-websockets code, https://crates.io/crates/websocket, is now effectively deprecated - in part, because one of _its_ dependencies _will_ break in future versions of Rust. Again, not the end of the world, as alternative libraries are available, but we _will_ have a dependency treadmill to deal with similar to the Node and Angular stuff. It looks like there are at least 101 dependencies among the entire Rust opensrf project. Consequently, if we want a "better C", Rust clearly has a lot to offer - but going down that path needs to be more about a full investment, not a technology experiment that makes a couple components of OpenSRF be different from the rest of the code. Regards, Galen -- Galen Charlton Implementation and IT Manager Equinox Open Library Initiative [email protected] https://www.equinoxOLI.org phone: 877-OPEN-ILS (673-6457) direct: 770-709-5581 This message originated from outside the M365 organisation. Please be careful with links, and don't trust messages you don't recognise. _______________________________________________ Evergreen-dev mailing list [email protected] http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-dev
