<div dir="ltr"><div dir="ltr"><br></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jun 1, 2023 at 9:10 AM Galen Charlton via Evergreen-dev <<a href="mailto:evergreen-dev@list.evergreen-ils.org" target="_blank">evergreen-dev@list.evergreen-ils.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi,<br><br>On Wed, May 31, 2023 at 11:08 AM Jason Boyer via Evergreen-dev <<a href="mailto:evergreen-dev@list.evergreen-ils.org" target="_blank">evergreen-dev@list.evergreen-ils.org</a>> wrote:<br>> I know "should we replace all of the 'C'?" wasn't really Bill's original question <br><div><br></div><div>... but I think this is the real question before us, or at least, close to it.</div></div></blockquote><div><br></div><div>I hesitated to start with "replace all the C", but you're right. Either we adopt it or we don't. Having a full investment plan is way better than waiting to see what sticks.</div><div><br></div><div>For my part, I'm all in. Replacing C is foremost on my mind, but once we're accustomed to using Rust, I could see it moving beyond the traditional C borders of "must be fast" into more general purpose API / utility coding. (For some things, anyway. It is decidedly not a rapid prototyping language).</div><div><br></div><div>For the curious, here's an implementation of the "open-ils.actor.get_barcodes" API based on my OpenSRF / Evergreen Rust code:</div><div><br></div><div><a href="https://github.com/kcls/evergreen-universe-rs/blob/main/evergreen/src/bin/eg-svc-rspub/methods.rs#L150" target="_blank">https://github.com/kcls/evergreen-universe-rs/blob/main/evergreen/src/bin/eg-svc-rspub/methods.rs#L150</a><br></div><div><br></div><div>It should seem familiar, Rust syntax notwithstanding.</div><div><br></div><div>But back to the topic at hand...</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>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.<br></div><div><br></div><div>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, <a href="https://crates.io/crates/websocket" target="_blank">https://crates.io/crates/websocket</a>, 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.</div></div></blockquote><div><br></div><div>Yes, the ecosystem is young and in flux. This could be a challenge, especially in the short term. A perfectly reasonable argument against going in too fast and half-baked.</div><div><br></div><div>I'm not so concerned about the number of dependencies, though. OpenSRF has about 27 Perl dependencies in the Makefile, plus whatever they depend on. It's to be expected, to some extent. And as the ecosystem matures, I would expect versioning conflicts to diminish. </div><div><br></div><div>I would also hesitate to compare Rust too closely to Node/Angular. I think we can agree that Node is kind of special :\ My node_modules directory has 815 package directories. And, for added fun, an additional 152 node_modules subdirectories within those packages. I mean...</div><div> </div><div>My main concerns, which are echoed in other responses to this thread:</div><div><br></div><div>1. Packaging / Release Building</div><div>2. Relative youth of the language and the ecosystem.</div><div>3. Community developer mindshare</div><div><br></div><div>The first 2 can be accomplished with time and effort. #3 requires a conscious decision on our part and, to some extent, should probably happen first. So I guess the REAL ;) question is: who wants to join my Rust Seal Strike Force 6 Team Thunder Brigade to learn the language and assess its viability as a general-purpose language for OpenSRF / Evergreen?</div><div><br></div><div>I really appreciate all the thoughts and feedback!</div><div><br></div><div>-b</div><div><br></div><div><br></div></div></div>