[Evergreen-dev] OpenSRF / Redis / Rust

[Frasur, Ruth]

I have nothing to add other than the “Order of Rusty Evergreen” and the role of “assessor,” just brought me a moment of real joy.  Thanks.

Ruth Frasur (she/they)
Coordinator
Evergreen Indiana Library Consortium
Evergreen Community Development Initiative
Indiana State Library
140 N. Senate Ave.
Indianapolis, IN 46204
(317) 232-3691

From: Evergreen-dev <evergreen-dev-bounces at list.evergreen-ils.org> On Behalf Of Shula Link via Evergreen-dev
Sent: Friday, June 2, 2023 10:10 AM
To: Bill Erickson <berickxx at gmail.com>
Cc: evergreen-dev at list.evergreen-ils.org
Subject: Re: [Evergreen-dev] OpenSRF / Redis / Rust

**** This is an EXTERNAL email. Exercise caution. DO NOT open attachments or click links from unknown senders or unexpected email. ****
________________________________
I'm working through the Rust Tutorial right now, actually. I'd be interested in possibly joining the Order of Rusty Evergreen as an assessor.

Shula Link (she/her)
Systems Services Librarian
Greater Clarks Hill Regional Library
slink at columbiacountyga.gov<mailto:slink at columbiacountyga.gov> | slink at gchrl.org<mailto:slink at gchrl.org>
706-447-6702


On Thu, Jun 1, 2023 at 5:34 PM Bill Erickson via Evergreen-dev <evergreen-dev at list.evergreen-ils.org<mailto:evergreen-dev at list.evergreen-ils.org>> wrote:

On Thu, Jun 1, 2023 at 9:10 AM Galen Charlton via Evergreen-dev <evergreen-dev at list.evergreen-ils.org<mailto:evergreen-dev at list.evergreen-ils.org>> wrote:
Hi,

On Wed, May 31, 2023 at 11:08 AM Jason Boyer via Evergreen-dev <evergreen-dev at list.evergreen-ils.org<mailto:evergreen-dev at list.evergreen-ils.org>> 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.

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.

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).

For the curious, here's an implementation of the "open-ils.actor.get_barcodes" API based on my OpenSRF / Evergreen Rust code:

https://github.com/kcls/evergreen-universe-rs/blob/main/evergreen/src/bin/eg-svc-rspub/methods.rs#L150<https://protect2.fireeye.com/v1/url?k=31323334-50bba2bf-31367a34-4544474f5631-677b26bb3baa3dcf&q=1&e=f210b66a-fba6-40fe-8189-e5a4dc1440af&u=https%3A%2F%2Fgithub.com%2Fkcls%2Fevergreen-universe-rs%2Fblob%2Fmain%2Fevergreen%2Fsrc%2Fbin%2Feg-svc-rspub%2Fmethods.rs%23L150>

It should seem familiar, Rust syntax notwithstanding.

But back to the topic at hand...

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.

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.

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.

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...

My main concerns, which are echoed in other responses to this thread:

1. Packaging / Release Building
2. Relative youth of the language and the ecosystem.
3. Community developer mindshare

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?

I really appreciate all the thoughts and feedback!

-b


_______________________________________________
Evergreen-dev mailing list
Evergreen-dev at list.evergreen-ils.org<mailto:Evergreen-dev at list.evergreen-ils.org>
http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-dev<https://protect2.fireeye.com/v1/url?k=31323334-50bba2bf-31367a34-4544474f5631-edcc8c98585635d9&q=1&e=f210b66a-fba6-40fe-8189-e5a4dc1440af&u=http%3A%2F%2Flist.evergreen-ils.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fevergreen-dev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.evergreen-ils.org/pipermail/evergreen-dev/attachments/20230602/57f69769/attachment-0001.htm>