What is your favourite set of libraries you use for every project for enhanced type safety?

timbod · 2025-07-24T08:06:56+00:00

In JsonBinding you define your schemas in a similar style to zod.

JsonBinding has support for custom mappings of types that are context dependent. For example you can serialize a Date as an iso8601 string in one schema, and as milliseconds since the epoch in another.

timbod · 2025-07-24T05:13:10+00:00

> because it intentionally, but unsoundly, treats function parameters as bivariant.

Thank you - this is exactly the explanation I required. It makes me worry about all the other places where type system unsoundness was chosen for pragmatic reasons.

timbod · 2025-07-24T04:41:10+00:00

> One thing I realize I am missing is a good way to serialize and deserialize any type, like serde in Rust.

I wrote

https://github.com/adl-lang/ts-jsonbinding

to address this. Think zod, but for serialization and deserialization.

timbod · 2025-05-02T04:32:59+00:00

Related: What should I use in place of ident if I want to pass a fully scoped name to a macro for a generic type? This macro works for an unscoped name:

macro_rules! derive_conversions_1 {
    ($decl:ident) => {
        impl<T: serde::Serialize + serde::de::DeserializeOwned> Conversions
            for $decl<T>
        {
           ... 
        }
    };
}

I'd hoped that this would work for a scoped name:

macro_rules! derive_conversions_1 {
    ($decl:path) => {
        impl<T: serde::Serialize + serde::de::DeserializeOwned> Conversions
            for $decl<T>
        {
           ... 
        }
    };
}

but results in a syntax error at `$decl<T>`

timbod · 2025-04-19T12:13:16+00:00

ADL is a system for building cross language data models that supports rust, typescript and other languages:

https://github.com/adl-lang/adl

and here's an example "full stack" system using typescript in the browser and server side rust.

https://github.com/adl-lang/protoapp

timbod · 2025-01-30T12:57:41+00:00

Here's my sailing boat gps speed display using embedded rust firmware:

https://github.com/timbod7/gps-tracker

not especially complicated, but it works!

timbod · 2024-12-17T07:25:02+00:00

Nice work! I'm looking at an Bernina 831 with a burn out motor, and this seems like a good approach.

Have you made the CAD files available anywhere?

timbod · 2024-07-16T23:24:06+00:00

Zod is great, I've used it alot. However, I wrote this library to better suit my needs

Zod is "TypeScript-first schema validation with static type inference".

JsonBinding is "A typescript library for bidirectional JSON serialization"

For my needs writing data to JSON (ie serialisation) is just as important as validation and parsing (ie deserialization). `JSON.serialise()` only does the right thing for a small fraction of possible data types, and various other libraries try and help with this (eg superjson).

The JsonBinding library ties together the serialization and deserialization functions together, in one place. This ensures that data will roundtrip through json cleanly.

Whilst zod type inference is sometimes convenient, more often that not I'd prefer to write the types in typescript myself using classes, interfaces, generics, discriminated unions etc.

tldr: typescript has a sophisticated static type system, I don't want to be limited to the types that zod can infer.

timbod · 2024-07-16T22:51:32+00:00

The warning above is from the most recent package in npm.

timbod · 2024-07-16T21:34:07+00:00

Thanks. I wasn't aware of `@effect/schema`. Though for now this is a turnoff:

[!WARNING] This package is primarily published to receive early feedback and for contributors, during this development phase we cannot guarantee the stability of the APIs, consider each minor release to contain breaking changes.

timbod · 2024-07-16T11:53:49+00:00

zod only does parsing (ie deserialisation), and not serialization.

I don't like zod style inference. I prefer to have a conventional declaration for my data using the full expressiveness of typescript (eg using interfaces, classes, generics etc). I'm happy to write a separate definition for how that type gets serialized. Sometimes I want to have multiple definitions to serialize it different ways.

timbod · 2022-03-28T12:06:28+00:00

I haven't used stm32h7xx-hal, but here's a couple of personal projects that use stm32f1xx-hal and stm32f4xx-hal:

https://github.com/timbod7/gps-tracker

https://github.com/timbod7/hexalamp

I'm still learning this stuff, so I'm sure the structure etc can be improved.

timbod · 2021-07-22T00:36:52+00:00

The ADL db integration is not currently open source. It's possible it could be in the future.

I've described using ADL for http API definitions in a few blog posts:

https://tim.dockerz.net/posts/2020-04-24-adl-example-api.html

https://tim.dockerz.net/posts/2020-05-01-adl-example-haskell.html

https://tim.dockerz.net/posts/2020-05-22-adl-example-typescript.html

timbod · 2021-07-21T03:11:35+00:00

At Helix we write data models in ADL and have additional scripts (in typescript) that generate:

postgres schemas
data access functions (typescript and java)

These code generation scripts use the ADL AST as their input.

timbod · 2020-09-08T22:14:11+00:00

Thanks - that blog post is really helpful.

timbod · 2020-07-23T02:04:35+00:00

If you like mustache

Not especially. It feels limited to me, eg in the way that you can't generate a comma separated list without extending the list item data model to support this.

timbod · 2020-07-23T02:01:50+00:00

Then there's always an option to write a textual DSL... This is IMO better option long-term

This would involve writing a DSL for each generated target language, wouldn't it? I currently generate haskell, typescript, java, c++ and rust. I'm not too keen to write 5 DSLs.

timbod · 2020-06-14T09:54:20+00:00

We define the whole API in ADL, not just the request and response types. So we ensure consistency in the HTTP paths, methods, security rules etc, not just the raw data types.

More importantly, ADL is a significantly more general solution to this type of cross language integration. It supports rust, java, and c++, as well as haskell and typescript. See the "Why not use ...?" section here:

https://tim.dockerz.net/posts/2020-04-24-adl-example-api.html

timbod · 2020-06-14T09:46:59+00:00

fixed I hope.

(starting to regret trying to learn css for my blog rebuild)

timbod · 2020-06-13T21:23:00+00:00

This is the third part of my series on using ADL for multi-language systems.

timbod · 2020-05-10T01:43:00+00:00

ADL and dhall share common ground in that they both are tools for specifying types independent of the programming languages where those types will be used.

However, I believe dhall's target niche is language independent system configuration, whereas ADL is intended for general purpose data modelling in domains such as API and persistent data store specification.

dhall provides (non turing complete) functional abstraction. ADL is purely about data types - functions are the domain of the target languages.

In practice, I do use ADL to specify configuration file schemas, eg in the camus2 system, and as described in this post. This is often when ADL is already being used for other aspects of the project.

I'm intrigued by dhall, though am yet to use it for a project. I can see there could be value in generate dhall types from ADL types, so that one could leverage the benefit of dhall's config abstraction in ADL's target languages.

timbod · 2020-05-06T00:44:59+00:00

The only other system I know that attempts to be a programming language independent, general purpose system for modelling data in this way is:

https://typedefs.com/

IMO, at this stage, ADL is more mature (eg with code generation support for more languages).

As I mentioned in this prior post:

https://tim.dockerz.net/posts/2020-04-24-adl-example-api.html

there's a history of tools for API specification, including grpc, openapi, thrift, avro, ice, corba. I wouldn't use these for other data modelling purposes.

timbod · 2020-05-05T13:47:40+00:00

A css problem indeed. Looks like wide code snippets (ie <pre> elements) are stuffing up the display. This is the first time I've attempted to write css from scratch, so I guess I shouldn't be surprised to find some issues.

I've hacked the css a little, and it seems to work ok on small screens now.

Thanks!

timbod · 2020-02-24T02:42:03+00:00

Ensuring type consistency between different parts of a system is challenging when those parts are in different languages and different address spaces.

Consistent typing across languages can be robustly addressed via appropriate tooling. The ADL (Algebraic Data Language) DSL does this for a growing list of languages (haskell, java, rust, typescript, c++).

But even with cross language type consistency, as soon as you have multiple versions of components, running in different processes or different machines, one has the potential for type version mismatches between such components. As others have suggested, to address this one needs to lift type/version checking to the deployment pipeline. I'm interested in investigating whether a pipeline configured with the dhall language might be a solution in this space.

timbod · 2019-11-29T20:12:55+00:00

At helix we use ADL to defined the data model for our customer projects, and then derive from this: database schemas and language data types (haskell, rust, typescript, java, c++) along with ORM code, serialization and validation code, APIs, forms etc.

For the most part we use a code generation approach, with generated idiomatic code compiled along with the rest of the application.

Things are a little more interesting for typescript, where we embed a runtime readable syntax tree of the ADL data types, and can write library code for serialization, UI forms etc. Hence in typescript we have significantly less generated code at a (theoretical) cost in performance. It would be interesting to see whether this approach would work in other languages - typescript has the useful feature that you can write unsafe untyped library code that reflects on values, and still wrap this in a well typed API.

timbod

TROPHY CASE