Rust bindings

[turboladen]

I've been using tree-sitter for a Rust-based LSP implementation for Ruby that I've been working on for fun for a couple years now. TS has its pros and cons, so I recently started looking into yarp, and now think it'd be nice to try it out in my project.

To get an idea of effort required, I forked this repo and started working on the bindings, and now that I've got low-level stuff wrapped, I think I'd like to keep moving forward with it. My question is, though: should I keep it here, in this repo, or create a new repo? Is there any interest in having these bindings here? I'm not a point in my life where I could commit to being super active with maintenance, but if there's enough community interest, maybe that's fine?

Thoughts?

[kddnewton]

I certainly don't mind taking a look in a PR! I've heard of other interest for this as well, so I would say please open a PR and we can discuss.

[turboladen]

Sweet! Ok, some questions then...

It's conventional, when wrapping functionality from a C library, to first provide a crate that's just the bindings--one that resembles the C API (kinda similar to calling attach_function with the ffi gem); then another crate that uses the first crate that provides a nice, ergonomic API (like the yarp gem). IIRC, the convention exists to allow for various implementations of the latter.

For my part, I'll want both of those, but my implementation of the Rust-y ergonomic crate might not be what everyone wants at this level (not that I'm planning on doing anything weird). ...so I wonder if you have any thoughts here?

I could do:

1. Just yarp-sys (the bindings crate), then make my own yarp crate in a separate repo.
2. yarp-sys and yarp crates here
3. Just yarp here.

My thoughts:

• I'd argue for 1 or 2, but could see an argument for 3.
• Doing just yarp-sys would probably imply to the world that you're not interested in maintaining anything Rust-y at a higher level here. ...but maybe that's not a bad thing?
• Doing both crates here seems like it'd provide all the Rust-y things for all the Rust devs. ...but is also more to maintain.
• I could do a PR for yarp-sys soon, after a bit of tidying up and testing, but could see needing some additions to that while working on yarp.
• An implementation of a yarp crate will probably still take a chunk of time (a month? Months?) if I'm the only one working on it.

Thoughts? Should I put up a PR just for the bindings (yarp-sys) or wait till there's more?

[kddnewton]

I would say let's get yarp-sys going, and then we can discuss the other options. I think my answer on whether or not yarp would live in this repository depends on its size/complexity.

[turboladen]

Okay, #1093 is up.

[turboladen]

Sounds good to me! I expect I can have something in the next few days.

…

On Mon, Jun 26, 2023 at 9:27 AM Kevin Newton ***@***.***> wrote: I would say let's get yarp-sys going, and then we can discuss the other options. I think my answer on whether or not yarp would live in this repository depends on its size/complexity. — Reply to this email directly, view it on GitHub <#1068 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABCVOSFYWO4MMWZPXPA5ITXNGZ5PANCNFSM6AAAAAAZSS2EZ4> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[eregon]

FWIW, another possibility I thought of is Rust could use the serialization API like Java. Then you would need very few bindings to the C codebase, and it might be easier to use too because everything would be allocated by Rust. But of course it might be a little bit slower.

[lopopolo]

My understanding was that the serialization API was made for ease of integration across a JNI boundary. No such limitation exists for Rust code interacting with C APIs.

Is the intent that only MRI has access to the C API? Would you also suggest for mruby to go through the serialization API?

As an author of a Ruby written in Rust, I would prefer to have access to the same APIs that MRI does.

[eregon]

My understanding was that the serialization API was made for ease of integration across a JNI boundary. No such limitation exists for Rust code interacting with C APIs.

Not really, it's also used for the Ruby API for instance (#1112), and it's designed to be portable and convenient to use for all languages.

I wrote in more details at #1093 (comment).
The problem is there is no well-defined public C API right now, and that PR already depends on way too much internals.
I also think it's way more convenient to use the API if using serialization with proper Rust types vs unsafe { node.statements } everywhere.