Viewing profile — dloreto

At our company we are building lots of AI applications and agents. We are a Go shop, so we've been using the official Go SDKs by OpenAI and an Anthropic ... but we kept running int…

I have a similar view to yours: as soon as you need variables, imports, functions or any other type of logic ... the existing "data-only" formats break down. Over time people eithe…

JSON + types + functions using TypeScript syntax. Makes it possible to use TypeScript as a configuration language for applications written in `go`, and soon `rust` and other major …

A follow up: 1. We've now implemented pretty thorough testing: https://github.com/jetpack-io/typeid-go/blob/main/typeid_tes... 2. I clarified the prefix in the spec Thanks for the …

We've now implemented pretty thorough testing: https://github.com/jetpack-io/typeid-go/blob/main/typeid_tes... Thanks for the feedback!

I hear you ... and I debated using either base58 or base64url. I do like the more compact encoding they provide. Ultimately I ended up leaning towards a base32 encoding, because I …

Thanks for the feedback! We have tests for the base32 encoding which is the most complicated part of the implementation ( https://github.com/jetpack-io/typeid-go/blob/main/base32/b…

The checksum idea is interesting. I'm considering whether it makes sense to add it as part of the TypeID spec.

The CLI tool will support encoding/decoding any valid UUID, whether v1, v4, or v7. We picked v7 as the definition of the spec, because we need to choose one of them when generating…

It's based on UUIDv7 (in fact, a TypeID can be decoded into an UUIDv7). The main reasons to use TypeID over "raw" UUIDv7 are: 1) For the type safety, and 2) for the more compact st…

That's how the type is encoded as a string, but type-safety ultimately comes from how the TypeID libraries allow you to validate that the type is correct. For example, the Postgres…

The stated downsides come from poor data locality when using mostly random UUIDs; but you can keep most of the benefits of a globally unique identifier, and retain locality, by usi…

Tools like Devbox: https://github.com/jetpack-io/devbox are making this way easier. Devbox is powered by nix, but it hides all of the complexity and makes it easier to use.

Depending on your use case, devbox ( https://github.com/jetpack-io/devbox ) could be what you're looking for. It is powered by Nix, but abstracts the nix language away, so that you…

The latest version of devbox allows pinning the sha of the nixpkgs repository to whatever you want. We don't yet allow pinning on a per-package basis within nixpkgs, but we're work…

Haven’t tried that yet. We started with using Docker directly because we were very familiar with it, and thought users might want to “preview” a dockerfile before asking devbox to …

The initial shell is slow: nix reinstalls a bunch of stuff the first time it runs. We’re planning to add a progress bar that makes that clear. Sorry for the hiccups – it is our fir…

It's likely you have not installed the pre-requisites: namely nix. Without nix, it can't find the package. That said, we'll improve the error message so that when nix is not instal…

Totally fair.

A clarification: the config file is currently exposed as plain JSON file. Cue is used internally because we use it to validate the schema after the JSON is parsed – but currently n…

The dependency on Docker only exists for when you want to turn your shell into a container – but it's not otherwise used when you're just running a shell locally. When writing java…

Yes, we use it internally for all of our development and plan to continue actively maintaining it. If there's enough interest from the community we would love to make it a Cloud Na…

Yes, internally it's using nix .. but it makes nix soooo much easier to use. With nix I've always struggled with the nix language and writing nix expressions. If you are comfortabl…