FFI / Interop Examples

[pckilgore]

First off, this is so cursed, and so perfect, major kudos for building it.

Can you give some examples about the FFI to Go and how one might say, incrementally adopt this to run alongside go files. Or just your future thinking here? Understand that might be raw.

I'm thinking about how, say, F# interacts with C#. Or OCaml interacts with C.

Also I'd love to help out.

[ivov]

Glad you like it!

For clarity to other readers, interop with the Go stdlib is documented with examples in the reference. Interop with Go third-party packages is upcoming work.

As for incremental adoption alongside existing Go files, I have some thoughts but they are not ready to discuss publicly yet. When the time comes I'd like to post them as an RFC, assuming there's user interest in participating.

And thanks for the offer to help! At this early stage, your feedback would be most valuable: what feels intuitive, what does not, bug reports, sharp questions, etc. are genuinely the most useful contributions right now.

[alexatcanva]

As for incremental adoption alongside existing Go files, I have some thoughts but they are not ready to discuss publicly yet. When the time comes I'd like to post them as an RFC, assuming there's user interest in participating.

I spent a few hours last night playing around with Lisette, and I was wondering what the options were for interop with Go files themselves. I quite like the approach that Gleam has with JS and Erlang interop. Perhaps that's something we could take a look at for inspiration?

On this note - great work with Lisette, I think it's a fantastic space to explore between Rust and Go, being able to piggy back off of Go's extensive std library and it's overall simplicity definitely positions Lisette to land in a pretty quick-yet-powerful spot.

[enquora]

Rather than attempting direct integration of Lisette code with existing Go, we find ourselves looking for natural seams along existing command boundaries and using Lisette where correctness is essential—domains in which OCaml and friends are the otherwise natural fit.

This is accomplished by developing the Lisette code as separate applications and running as sub-processes, communicating via stdio. This allows comfortable exploratory development and testing, even at the cost of minor performance and runtime efficiencies. These become informal modules, designed for consumption as libraries once the Golang interop story has fully stabilized.

This is being used for the porting of an entire language toolchain: from discrete elements to an omnibus orchestration application—modeling the Go toolchain itself. The parser is already implemented as a tree-sitter, deployed as a dynamic library. The compiler and linker/packager is obviously a natural fit for Lisette. Orchestration and the top-level command surface are handled by Go.

The strategies used by both Hashicorp and Tailscale are used as models here: Both are exemplars of the Go ecosystem, with Serf and Tailscale/tsnet both being consumable as libraries while also being shipped as full applications which wrap that library functionality.

While deep FFI may come, it can do so at its natural pace, giving the author space to concentrate on edge cases surfaced by broader usage of the language’s core functionality.

The Lisette language is itself a godsend to the Go ecosystem for problem domains where assurance of correctness is vital.