On maintainence and future of lta-rs

Hi all, it has been awhile since I made any commits to this repo and some of you might be wondering what is the status of this project. At the current moment, the existing library has been working fine since 4 years ago. Nothing much has changed from LTA datamall with the exception of a few new APIs.

However, as with any async library in Rust (especially SDKs like this), having different client implementation for different IO styles is a maintenance burden and unfortunately there is not much we can do at the moment in Rust apart from having separate implementations. In this very repo I have tried to keep it async executor agnostic but that proved to be a challenge in Rust today.

That said, I have been experimenting with sans-io design and on the side am developing an OpenAPI generator that generates a sans-io ready client that is usable across different underlying backends (reqwest, ureq, blocking reqwest etc) while having NOT to maintain those dependencies. I strongly believe this is one of the best ways of building SDKs. An examplar of this is rusty-s3.

At the current stage, satay-rs is actually ready to pretty much generate all the LTA Datamall endpoints. However, the generation quality will not be on par with the quality of this crate. For the uninitiated, this crate is designed specifically for type safety, even in the absence of it from LTA Datamall. For example, MRT stations will be strongly typed enums in this crate as opposed to regular strings. In fact, the serialized structs and enums acts as ADDITIONAL documentation on the shape of data that is returned by LTA Datamall that they themselves do not document!

Perhaps it would be easier if I list down what are some of the goals and future of lta-rs are

Generated via OpenAPI

The crate should be machine generated (not LLM) via an OpenAPI generator including comments and documentation. Satay-rs alr supports this to some extend hence I will be focusing work on there with one of the main goal being to support lta-rs.

Runnable ANYWHERE

This crate should be able to run ANYWHERE, that includes things like microcontrollers. Back in 2022, I tried doing exactly that (albeit with a HAL which made it significantly easier) and managed to successfully run this crate on an ESP-32. Apart from ESP-32, I also want this library to be runnable across different IO execution style, whether it using work-stealing async runtime like Tokio or thread-per-core (TPC) style executor like Glommio or even sync using ureq WITH THE SAME API surface. New comers to Rust might not be familiar with this but there is an async runtime fragmentation in the Rust ecosystem and because of that most libraries default to implementing it only for Tokio. It is a pragmatic choice of course, but it is also the byproduct of this fragmentation.

Higher bar for type safety

I want the highest quality when it comes to type safety, down to the strings via NewTypes. This is also one of the specific goals of satay-rs and with the support of nutype . This goal is already achievable today and OpenAPI spec that utilises satay-rs extensions are able to generate code that is stricter. An example of this is BusStopCode. Instead of String, now it will be a strongly typed BusStopCode which guarantees that it will always be valid BusStopCode. At the moment Rust doesn’t support refinement types and this is one of the ways we can have something closer to it. As mentioned above regarding the existing crate already has a high bar for type safety, but I want to push the bar even higher because Rust has the necessary facilities for it.

Semi-automatic maintenance

Automatically updated via OpenAPI schemas and regular polling of LTA Datamall documentation. This already happens for some of my crates so this should not be a challenge.

So is this crate still maintained?

At the moment, maintenance mode only. No new features, only bug fixes until satay-rs is ready.

What is left for satay-rs?

Quite alot actually, at least to reach feature parity with the existing lta-rs crate

Is there any timeline for satay-rs?

I cannot promise anything, but given that I have recently shutdown my startup, I now have more free time. Of course at the moment am preparing for interviews and all that jazz but I should be able to dedicate time to satay-rs and by extension this crate. My hope is that by November I can reach feature parity with the existing crate

Is there any example of libraries that uses satay-rs today?

Yes. I also maintain nea-rs. It is fully generated using satay-rs. Fortunately, NEA APIs are actually much simpler compared to Datamall so there isn’t much support required on satay-rs side

Afterword

It has been a joy maintaining this library ever since I started it back in 2019 as a way to learn Rust as well as contribute to the growing ecosystem. I always thought that contributing library will draw people to the language as ecosystem is a big part of many peoples line of reasoning when choosing a tech stack. Today, Rust is a choice of many, especially with the help of LLMs lowering the bar to use Rust (Good thing!). Rust, in many ways has evolved since then and I have experimented with many different ways of doing this library and I believe I have landed on a vision that is finally good enough for me that is worth pursuing. I want nothing out of this monetary wise and am doing it just for the love of public infrastructure and for the love of the game