- Published on
Update on smaws development - October 2025
- Authors

- Name
- Chris Armstrong
Preparing for ICFP OCaml Workshop 2025
I'm still in the process of preparing my presentation for the ICFP OCaml Workshop 2025 in Singapore. I'll be presenting on smaws, an AWS SDK for OCaml and Smithy code generator.
While I will be covering a little bit about the Smithy IDL and the internals of the code generation process, I'll actually be focussing more on the design of the SDK itself, as I think this is a bit more interesting from a programming language perspective. My hope is that the talk will be interesting enough to those attending (and there are some big names from the OCaml community on the speaker list, which is honestly a little intimidating!).
smaws has always been a hobby project, and something lacking use in production (as far as I can tell). It's my intention to improve it to the point that I can use it in side projects and actually prove out its usage, but for now its been a useful playground for learning OCaml more deeply and testing out ideas about interface design in a functional lanugage.
Trying out new schedulers
A decision I made early on in the development of smaws was to use eio as the scheduler for the SDK. I always wanted to support multiple schedulers and HTTP libraries, but couldn't quite find the right combination of OCaml language constructs that would make it user-friendly.
awsm generates different libraries for each async library, and ocaml-aws uses a shared runtime passing the service module as a parameter, but I still wanted to create something relatively transparent to the end-developer that avoided difficult language features.
For similar reasons I also wanted to avoid functors, as they tend to "infect" the whole codebase, and I could see them getting out of hand and bleeding into the interface of the service SDKs themselves (beyond just being difficult to work with and reason about).
It always seemed pretty obvious that none of this would be necessary with OCaml 5's schedulers because they don't cause function colouring like lwt and async.
However, I think I've found a way to make it work with first-class modules that is relatively unobstrusive, so that the end-developer shouldn't need to worry about it. I have a prototype working with the httpcats library that operates with the miou scheduler, which you can find here1.
Footnotes
I'm not sold on the API design yet, but I think it's a good start separating out the scheduler specific portions into separate modules. ↩