[Evergreen-dev] OpenSRF / Redis / Rust

[Bill Erickson]

On Thu, Jun 1, 2023 at 9:10 AM Galen Charlton via Evergreen-dev <
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> 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

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.evergreen-ils.org/pipermail/evergreen-dev/attachments/20230601/54608502/attachment.htm>