dloreto

5 ms·

1.
Show HN: Go AI SDK – A Unified Go API for LLMs(github.com)
4 points by dloreto 1y ago|0 comments
2.
by dloreto 3y ago
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 either invent new configuration languages that enable l
3.
by dloreto 3y ago
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 languages.
4.
TySON: TypeScript Object Notation. Use TS as an embeddable config language.(github.com)
6 points by dloreto 3y ago|3 comments
5.
by dloreto 3y ago
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 feedback!
6.
by dloreto 3y ago
We've now implemented pretty thorough testing: https://github.com/jetpack-io/typeid-go/blob/main/typeid_tes... Thanks for the feedback!
7.
by dloreto 3y ago
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 didn't want to pre-suppose case sensitivity. For exampl
8.
by dloreto 3y ago
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/bas... ) but your poi
9.
by dloreto 3y ago
The checksum idea is interesting. I'm considering whether it makes sense to add it as part of the TypeID spec.
10.
by dloreto 3y ago
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 a new random ID, and our opinion is that by default, t
11.
by dloreto 3y ago
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 string encoding. If you don't need either
12.
by dloreto 3y ago
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 PostgresSQL implementation of TypeID, would let you use a &quot
13.
Type-safe, K-sortable, globally unique identifier inspired by Stripe IDs(github.com)
418 points by dloreto 3y ago|221 comments
14.
by dloreto 3y ago
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 using UUIDv7. At jetpack.io we've been doing exactly that
15.
by dloreto 4y ago
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.
16.
by dloreto 4y ago
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 can use it like a "regular&qu
17.
by dloreto 4y ago
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 working on that.
18.
by dloreto 4y ago
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 build a container (we don’t have that yet, but can easily ad
19.
by dloreto 4y ago
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 first pre release version but feedback like yours helps us hard
20.
by dloreto 4y ago
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 installed it tells you you should install it.
21.
by dloreto 4y ago
Totally fair.
22.
by dloreto 4y ago
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 not exposed to users.
23.
by dloreto 4y ago
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 javascript there's often a desire to have "i
24.
by dloreto 4y ago
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 Native Computing Foundation project.
25.
by dloreto 4y ago
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 comfortable with nix itself, then it allows you to do a lo
26.
by dloreto 4y ago
Having a deterministic environment, but that is actually running on your laptop is so much better than working inside a docker container. Inside a container the file system is very slow, and you lose all of your other tools and shell alia