integration with Ruby

[brandondrew]

As someone who appreciates Ruby, @yorickpeterse, I hope you will appreciate my desire to use Inko along with Ruby.

Ruby has been around a long time, and has a solution for a large set of application needs. Concurrency has not been its strongest suit, however, and so Inko seems like it could be an ideal complement. Having Ruby available reduces fear that I'll run into a situation with Inko where I need to roll several of my own libraries that would have been available already for Ruby, and having Inko available reduces fear that I'll need to do some concurrent processing that Ruby is just not up for.

But the big question is: how well can Inko & Ruby play together?

I don't expect there to be a clear answer yet, but I would love to hear your thoughts on what you envision in the near, intermediate, and distant future.

I'd love to be able to use Inko for everything that Rust might be used for:

• build GPUI apps (or front-ends to Ruby apps at first, and maybe later pure Inko apps with GPUI UIs)
• build Tauri apps
• write extensions that make a Ruby gem or app blindingly fast

Do you envision any of these being supported? What else do you envision or hope for?

[yorickpeterse]

@brandondrew There are some challenges that mean it isn't possible to expose Inko code as a library to other languages, starting with these two issues:

• Don't pass the state and current process as arguments #617
• Allow passing pointers to Inko methods to C functions #693

I've been working on these issues the last few days, and hopefully can close them some time this week. This also makes it possible for C code to call back into Inko code, which in turn makes it possible to use libraries that rely on callbacks (e.g. most GUI libraries).

A bigger issue is that of setting up the runtime, and ABI stability. Inko requires some plumbing to be performed when a program starts, such as configuring the runtime library and spawning the necessary threads. If we want for people to write libraries in Inko that are exposed through a C interface, consumers of that library would have to call the necessary "bootstrap" function to get things going.

This also brings me to ABI stability: for this to work we need to adhere to at least some form of ABI stability. Even if the Inko methods are exposed using C types and opaque pointers, behaviour/semantics have a tendency to leak, so without a true stable ABI this is bound to lead to problems. While I see Inko having a stable ABI at some point, that's still a long way off.

Assuming we get all that working, there are still a bunch of unanswered questions:

• What if you load two different .so files providing code compiled with two different Inko versions, each using their own runtime?
• Would that even work? Assuming we'd have some sort of setup function, the symbols would conflict
• If we split the Inko runtime into its own .so we might be able to work around that, but for that we absolutely have to commit to a stable ABI
• The library sizes would end up being quite large due to them including the runtime, would people even be OK with that?
• Probably more I can't think of right now

Long story short: the goal is to make Inko a good language for writing applications. Writing libraries you can expose to other languages is something I'm not sure about just yet, and I doubt there will be any work done towards this in the next 5-10 years.

[brandondrew]

Thanks for the thoughtful answer!