Luke Boswell (Nov 24 2022 at 09:05): Luke Boswell (Nov 24 2022 at 09:05):Can a Roc package also include platform code to share implementation details?
I was thinking through how to share code between platforms easily. I would like to use Rust code from cli in the tui platform I have been messing around with. Is there a good way to do this? This had me thinking, how will packages share side-effects across platforms in the future? Can we/should we use roc glue to assist with building a Rust crate which provides package specific implementation details?
This also feels similar to a recent video I watched with the development of WASM. Is there a Roc equivalent to the component model similar to that being developed for WASM? Does the current Roc platform/package specific integration concept align with this model of software development?
For example; imagine I want to write a library for generating markdown documents. It has a simple API maybe something like this;
interface Markdown
exposes [Elem, writeToFile]
imports []
Elem : [
Heading1 Str,
Heading2 Str,
Text Str,
]
writeToFile : Str (List Elem) -> Effect {}
I would like to generate Rust bindings for this using glue. Then implement the writeToFile side-effect and potentially other processing of the data. For example I might just use std::fs::File::write_all() for example. Then I import my Rust library into tui-platform and integrate with my platform, taking advantage of the new features that I didn’t have to write from scratch. I might vendor the Roc interface module so now any apps developed with my platform can target that and have a simple easy to use experience.
The above idea needs a lot of work. I can see a lot of rough edges, but I thought I would pose the question anyway to see if there is any prior research or design around this, or advice that will save me some headaches...
Anton (Nov 24 2022 at 09:10):I would like to use Rust code from cli in the tui platform I have been messing around with.
I think publishing a rust lib on crates.io (or github to get started) is the way to go here.
Richard Feldman (Nov 24 2022 at 09:50):it's a good question!
Richard Feldman (Nov 24 2022 at 09:50):we've talked about this a lot in the past, and the short answer is that the current plan is to - very intentionally - not introduce any language-level changes to Roc for use cases like this
Richard Feldman (Nov 24 2022 at 09:51):it's already possible to share host code using the host language's code-sharing capabilities (e.g. in Rust's case, splitting out a crate of shared logic and then importing it in both platforms)
Richard Feldman (Nov 24 2022 at 09:52):and then the corresponding Roc code can just be copy/pasted
Richard Feldman (Nov 24 2022 at 09:53):I think we should start with this system, because it's the simplest from a language perspective
Richard Feldman (Nov 24 2022 at 09:54):it's possible that the benefits of a more complex system would outweigh the cost of complexity, but in this particular case I'm very skeptical of that
Richard Feldman (Nov 24 2022 at 09:54):so I want to try sticking to the current set of tools for sharing code between platforms, and watch how the ecosystem evolves!
Folkert de Vries (Nov 24 2022 at 10:14):btw rust allows dependencies with a github link, so you don't even need to publish officially to use rust code in multiple projects
Last updated: Jul 26 2025 at 12:14 UTC