Rust language bingings/code generation #51

Open
opened 2025-12-30 01:20:02 +01:00 by adam · 7 comments
Owner

Originally created by @WeetHet on GitHub (Feb 11, 2024).

I'm really interested in using this in my rust projects, any plans on supporting serde/code generation?

Originally created by @WeetHet on GitHub (Feb 11, 2024). I'm really interested in using this in my rust projects, any plans on supporting serde/code generation?
adam added the help wanted label 2025-12-30 01:20:02 +01:00
Author
Owner

@jclmnop commented on GitHub (Feb 12, 2024):

+1 for this

In the meantime we'd have to just use serde_json and export the .pkl to .json, then manually define all the types/structs etc again in code (which I guess is what we do with JSON/YAML anyway). Would be nice to just write the config and have it generate the types for us.

@jclmnop commented on GitHub (Feb 12, 2024): +1 for this In the meantime we'd have to just use `serde_json` and export the `.pkl` to `.json`, then manually define all the types/structs etc again in code (which I guess is what we do with JSON/YAML anyway). Would be nice to just write the config and have it generate the types for us.
Author
Owner

@holzensp commented on GitHub (Feb 13, 2024):

This is a totally valid ask and you're not the first to ask. The core team lacks bandwidth at the moment, so we can't make any promises about this in the foreseeable future. That said, community contributed Typescript bindings are approaching done after little more than a week.

If anyone wants to pick this up, I'm sure pol-community will be happy to host it (cc @jasongwartz, @jackkleeman). Support has been readily available on the discord channel they opened for this.

@holzensp commented on GitHub (Feb 13, 2024): This is a totally valid ask and you're not the first to ask. The core team lacks bandwidth at the moment, so we can't make any promises about this in the foreseeable future. That said, [community contributed Typescript bindings](https://github.com/pkl-community/pkl-typescript) are approaching done after little more than a week. If anyone wants to pick this up, I'm sure `pol-community` will be happy to host it (cc @jasongwartz, @jackkleeman). Support has been readily available on the [discord channel](https://discord.com/channels/1203282168764432384/1203394300940001353) they opened for this.
Author
Owner

@jackkleeman commented on GitHub (Feb 13, 2024):

I think I will probably work on this after Typescript

@jackkleeman commented on GitHub (Feb 13, 2024): I think I will probably work on this after Typescript
Author
Owner

@linux-china commented on GitHub (Mar 1, 2024):

Vote for Rusting binding:

  • Rust is friendly for JavaScript and Python: if Rust binding ready, it's easy to implement JS/Python binding, and other languages.
  • Browser friendly: WebAssembly
  • CLI friendly: now GraalVM native-image binary is 102M, maybe Rust binary is about 10M.
@linux-china commented on GitHub (Mar 1, 2024): Vote for Rusting binding: * Rust is friendly for JavaScript and Python: if Rust binding ready, it's easy to implement JS/Python binding, and other languages. * Browser friendly: WebAssembly * CLI friendly: now GraalVM native-image binary is 102M, maybe Rust binary is about 10M.
Author
Owner

@jackkleeman commented on GitHub (Mar 1, 2024):

CLI friendly: now GraalVM native-image binary is 102M, maybe Rust binary is about 10M.

This would require actually building a Pkl JIT interpreter in Rust. This is a much larger task. The goal with bindings is to create a type safe way to interact with the pkl binary (in server mode). In time, the bindings will be changed to use Pkl as a linked library instead of over exec - but this may still be quite large, and GraalVM based!

If someone wants to try and build a new interpreter for Pkl in Rust, they should absolutely go ahead, but it's definitely beyond me!

@jackkleeman commented on GitHub (Mar 1, 2024): > CLI friendly: now GraalVM native-image binary is 102M, maybe Rust binary is about 10M. This would require actually building a Pkl JIT interpreter in Rust. This is a much larger task. The goal with bindings is to create a type safe way to interact with the pkl binary (in server mode). In time, the bindings will be changed to use Pkl as a linked library instead of over exec - but this may still be quite large, and GraalVM based! If someone wants to try and build a new interpreter for Pkl in Rust, they should absolutely go ahead, but it's definitely beyond me!
Author
Owner

@SmolPatches commented on GitHub (Jun 17, 2024):

I'm brand new to PKL so take this with a sizable pile of salt but what would a binding to Rust entail? I am quite interested in knowing what goes in to making a typesafe / production language binding.
I imagine PKL could be made to leverage json serde to encode the Pkl types into rust at runtime, obviously this could fail if the structure of the JSON is not capable of being ingested by the particular structs / enums in Rust but is that not alright, we would just need errors to provide details on the problematic code.

@SmolPatches commented on GitHub (Jun 17, 2024): I'm brand new to PKL so take this with a sizable pile of salt but what would a binding to Rust entail? I am quite interested in knowing what goes in to making a typesafe / production language binding. I imagine PKL could be made to leverage json serde to encode the Pkl types into rust at runtime, obviously this could fail if the structure of the JSON is not capable of being ingested by the particular structs / enums in Rust but is that not alright, we would just need errors to provide details on the problematic code.
Author
Owner

@z-jxy commented on GitHub (Jun 19, 2024):

I'm brand new to PKL so take this with a sizable pile of salt but what would a binding to Rust entail? I am quite interested in knowing what goes in to making a typesafe / production language binding.
I imagine PKL could be made to leverage json serde to encode the Pkl types into rust at runtime,

This does work, sort of. You could technically call pkl eval file.pkl --format json and deserialize that output, but that would be more of a wrapper around the pkl binary than a binding.

The binding should be parsing the evaluator responses according to the spec. The task is mainly turning the binary encoding into a format that can be deserialized, which would include doing most of the work serde json does.

For example, evaluating this pkl file:

address = "127.0.0.1"
database {
    username = "root"
    password = "password"
}

would produce an output like this.

A good reference for how this is implemented is pkl-go. I also have a working binding for Rust

@z-jxy commented on GitHub (Jun 19, 2024): > I'm brand new to PKL so take this with a sizable pile of salt but what would a binding to Rust entail? I am quite interested in knowing what goes in to making a typesafe / production language binding. I imagine PKL could be made to leverage json serde to encode the Pkl types into rust at runtime, This does work, sort of. You could technically call `pkl eval file.pkl --format json` and deserialize that output, but that would be more of a wrapper around the pkl binary than a binding. The binding should be parsing the evaluator responses according to the [spec](https://pkl-lang.org/main/current/bindings-specification/index.html). The task is mainly turning the binary encoding into a format that can be deserialized, which would include doing most of the work serde json does. For example, evaluating this pkl file: ```pkl address = "127.0.0.1" database { username = "root" password = "password" } ``` would produce an output like [this](https://gist.github.com/z-jxy/3dae5edc82aa2e67dcf0ecb12b927737). A good reference for how this is implemented is [pkl-go](https://github.com/apple/pkl-go). I also have a working binding for [Rust](https://github.com/z-jxy/rpkl)
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/pkl#51