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 [email protected] | [email protected] 706-447-6702 On Thu, Jun 1, 2023 at 5:34 PM Bill Erickson via Evergreen-dev < [email protected]> wrote: > > On Thu, Jun 1, 2023 at 9:10 AM Galen Charlton via Evergreen-dev < > [email protected]> wrote: > >> Hi, >> >> On Wed, May 31, 2023 at 11:08 AM Jason Boyer via Evergreen-dev < >> [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. >> > > 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 > > > _______________________________________________ > Evergreen-dev mailing list > [email protected] > http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-dev >
_______________________________________________ Evergreen-dev mailing list [email protected] http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-dev
