Go and Java library beta out now and what’s next for IOTA client libraries
The full article was originally published by Jakub Cech on Medium. Read the full article here.
Golang has been making quite a noise the past few years. It’s open source, officially backed by Google, code is easy to write and maintain, and all while being very efficient at things like concurrency. Luca Moser has taken on the development of the IOTA Go library, and has made great progress at putting the library back in shape.
We are now releasing IOTA Go 1.0.0-beta with quite a few improvements under the hood:
- All the functions that were available in IOTA JS are now supported.
- Composable API.
- Functionality now available via different packages.
- Better error handling.
- Other missing functionality from IOTA JS.
- And much more — see the full release notes.
If you have any questions, let Luca or Jakub know in the #go channel on the IOTA Discord server.
The IOTA Java library is another library we consider crucial to support officially. It hasn’t been getting as much attention as it deserved in the first half of the year. But Brord van Wierst has been correcting this omission over the past few months. Brord is also a frequent contributor to IRI, but IOTA Java is now his main focus.
We are now officially releasing IOTA Java 1.0.0-beta, which brings it up to par with IOTA JS:
- All API functions, like checkConsistency and promoteTransactions are now available.
- Tips can be selected for reference in getBalance, and added a reference param to getTransactionToApprove. This allows you to spend directly from a not-yet-confirmed subtangle or tip, like you could in IOTA JS.
- See the full release notes.
Brord and Jakub are also easy to reach in the #java channel on the IOTA Discord server. Feel free to join the discussion there!
We have quite a few things in store for the future of client libraries. But of course we want you, the developers who work with the libraries or contribute to the code, to have a say as well. If you’re missing something in the libraries, please open an issue. Or, even better, open an issue and then make a PR!
One of the big things when it comes to working with libraries is persistence. The ability to store the state and manage addresses is the next big goal. This will take away quite a lot of the overhead the developer has to go through now. The current plan looks like this:
- Version 1.0.0-beta — where we are now, unified API implementation.
- Version 1.0.0 (out of beta) — Client libraries have built in persistence and improved documentation.
- Version 1.1.0 — Streaming API, we’re finalizing a design to make the libraries reactive, which we will soon share with the community for feedback!
And more to come!
Thanks to Chris Dukakis, Brord van Wierst, and Luca Moser for their efforts in getting these libraries ready for our developer community.