LambdaBuffers for Rust #108
bladyjoker
started this conversation in
General
Replies: 1 comment
-
|
Please follow our project board for this milestone at Lambda Buffers (view) |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
LambdaBuffers got funded by the Catalyst Fund10 round (as announced in #101) and our proposal lists Rust support as one of its first milestones.
Achieving this will enable us to seamlessly share types and their values between Rust and other supported languages. Whether it's to store and exchange JSON based configuration or Cardano dApp 'datums', the effort to do so will be effectively reduced to your devops automation and configuration (we provide Nix API to do exactly that). We don't want to spend time manually implementing various encodings in the 21st century, and we want to save you the trouble of doing that as well.
I want to briefly touch on the plans and known challenges that we are tackling to get Rust support.
Code generation
Two basic challenges we tackle here are:
LamValto target language translation step for each of the supported languages.LambdaBuffers Prelude for Rust
The LambdaBuffers Prelude package defines some basic types that could considered to be a common denominator between different programming languages. It also specifies a
Jsontype class, which is a principal encoding method that each ofopaquetypes listed in this module support.So, in order to have Rust support LB's Prelude, we need to:
MaybeandEither, are ubiquitous and part of the standard library (OptionandResult),lbr-prelude)lbt-prelude)@szg251 is already tackling this #103.
LambdaBuffers Plutus for Rust
Supporting LambdaBuffers Plutus package is integral to this project, as the gracious Catalyst funding we received is contingent to facilitating Cardano dApp development.
The development process here is basically the same as for the LB Prelude package, we'll just need to do a preliminary investigation to understand which library is best to use when mapping
opaquetypes that denote the foundationalplutus-ledger-apitypes, the choice is roughly between:uplccrateThe central LB type class in the Plutus package is
PlutusDatawhich denotes the, so called, 'Data' encoding which is the foundational value representation used in Cardano's Plutus application platform.Unlike the
lbr-preluderuntime library for the LB Prelude package, these encodings are already set in stone by Cardano specs and a reference implementations used is located in the Haskell library plutus-ledger-api. This means we don't have to provide PlutusData encoding implementations for all the 'opaque' types in the LB Plutus package, they're already available in the target language ecosystems and we can just (re)use that!We do however need to provide the
lbt-plutustestsuite to make sure our implementation derivation is sane!Beta Was this translation helpful? Give feedback.
All reactions