Note: this blog post is out of date. For the latest SDKs, please see: www.docs.hedera.com/hedera/sdks-and-apis/sdks
We’re still so early in this journey we call Hedera Hashgraph. We just started opening up testnets to a wider audience of developers and boy did we learn some really cool things…things that have informed how we want to build our SDKs. Frankly, we need to make sure that developers absolutely love the SDK experience. So we’re getting smart and fun about building our SDKs with the help of those very same developers.
TL;DR — The Hedera SDK is written in Rust, compiled to C, then wrapped in your favorite language.
There are few fundamental guidelines to our SDK strategy:
1. One code-base to rule them all. We’re writing the core SDK in Rust. We chose Rust because it’s safer, faster, and compiles down nicely to C. This is great because we get Rust and C SDKs right out of the box. We can then wrap the C SDK in any language. These additional language interfaces will reference the same C artifacts, making it easier to enforce consistency between different languages, especially when it comes to things like cryptography, key management, account management, Protobuf API interfacing, and network config management.
2. “More languages” is more important than “more functionality”. We’re starting with 5–6 languages that will expose the most basic functionality to support micropayments. We’ll then build out functionality until each language’s SDK reaches a minimum viable product (MVP) state. Future MVP functions include file service, claims, smart contracts, multi-sig accounts, and some initial transaction and query validation. Those languages will include Rust (duh), C (duh), Go (wrapper), Python (wrapper), and Javascript/Node.js (wrapper).
3. Using a builder-pattern makes transactions more fun. We were tempted to build a very comprehensive and object-oriented SDK, but realized that trying to be “everything to everyone” is a failing strategy. SDKs are meant to make things easier, so let’s focus on use cases first. The builder pattern is more conversational (example below).
Example transfer transaction in Go
So what does this mean for devs?
Well, that depends on what you want to do. We see devs playing a role in a few ways:
1. Maybe you just want to use the SDK in your specific language. You are free to do so (assuming you get in queue for a testnet or have an account on mainnet). Grab the SDK for your language of choice and get to doing what you do best: building software. The one thing we would ask in return is for you to give us your feedback about how we can improve the SDK.
2. You may want to be more involved in the development of the wrapper for your preferred language. If that’s the case, find a GitHub issue (or raise one if none exists), fork the repo, do your worst (best), test it, and do a pull request. We will need your help maintaining the wrappers as the core SDK grows and evolves.
3. So you’re a disgruntled C/C++ developer, ready to make the leap to the safe world of Rust? We welcome you to “the core”. Core SDK development is in Rust and includes Protobuf interfaces, transports (gRPC & HTTP2), cryptography (key management, signing, and signature verification), transaction and query construction and pre-validation, error handling, network and node management, account management, and so much more. This is the heart of the SDK and needs sharp minds to set the stage for elegant patterns and pleasing developer experiences.
This is all still so early, but momentum is building nicely. Micropayments will be a reality very quickly, followed by a new model of trust for files, account claims, and smart contracts; all powered by the Hedera Hashgraph Platform. The future of all of this is in the hands of a passionate developer community using tools they love to solve problems that matter.
Get involved
GitHub: https://github.com/hashgraph
Portal: https://portal.hedera.com
