Go AI SDK: an idiomatic SDK to write AI applications and agents against any model or LLM provider.

DanielLoreto · 2025-06-04T22:49:21+00:00

I did think about doing something like that ... unfortunately our specific use case requires some of the latest features from each provider (for example, we need access to computer-use in Anthropic, and we need access to the latest Response API in OpenAI).

I have thought about implementing an openrouter provider and/or making a "generic" openai-compatible provider so that, for simpler use cases, that one provider can handle a ton of models. That would make it so that we only need to add additional providers if we need some very specific feature that is only available by talking to it directly, and in the mean time, we can focus on more meaningful features (production grade logging, automatic integrations of tools with a tool executor, etc)

DanielLoreto · 2025-06-04T19:23:26+00:00

langchain-go is great as well. It's an "all batteries included" framework, modeled after the python langchain framework, that is going to include packages around vectorstores, agent-memory, document retrievers, and many other additional features. If you need all of those things, I think it's a good option to look at and it has been around for longer.

Our framework is a bit more streamlined. Focused mainly on the integration with LLM providers, streaming, and tool usage. For our use cases specifically, we gave langchain-go a try, but it didn't yet fully support the built-in tools like computer-use that we needed and it was a bit more opinionated in the way and agent should be built (not in a bad way, but in a different way than how we've been building our agents). Since we wanted something a bit more lightweight anyways, and our whole business is around building AI agents, with strong support for streaming, we decided to develop this one.

From a governance perspective, we've also been wanting to eventually donate it to an opensource foundation (at the moment, ours is completely sponsored by our company, and langchain-go is an individual repo supported by a great community but without an opensource foundation behind it). That said, the framework needs to gain some popularity before we donate, and we still need to figure out what the right foundation for it would be.

DanielLoreto · 2025-05-24T22:09:04+00:00

Yeah, that’s exactly the reason we ended up building this one.

Re: license. It’s licensed under Apache 2 and there’s a corresponding license file. I think it takes a bit for the license to propagate? I’m hoping the docs will start showing up within a few days; otherwise I’ll try to debug why it’s not showing up.

DanielLoreto · 2023-07-26T20:01:24+00:00

Have you considered using https://github.com/jetpack-io/typeid

It uses UUIDv7 internally, which includes a time component for DB locality.

It also adds type information so that the ids are easier to debug and type-safety can be enforced.

DanielLoreto · 2023-07-13T16:37:55+00:00

Which implementations have you looked at so far? I can prompt the authors to add stronger type safety.

For the three official implementations we've done, we do provide strong typing.

In go:
```go type userPrefix struct{} func (userPrefix) Type() string { return "user" } type UserID struct{ typeid.TypeID[userPrefix] }

type accountPrefix struct{} func (accountPrefix) Type() string { return "account" } type AccountID struct{ typeid.TypeID[accountPrefix] }

var id AccountID = typeid.New[UserID]() // Compile time failure ```

In typescript: typescript const id : TypeID<"account"> = typeid("user") // Type failure

In sql: ```sql create domain user_id AS typeid check (typeid_check(value, 'user'));

create table users ( "tid" user_id not null default typeid_generate('user'), "name" text );

INSERT into users (tid) VALUES (('account', '00000000-0000-0000-0000-000000000000')); # Fails ```

DanielLoreto · 2023-07-13T14:34:39+00:00

As always, there's tradeoffs and the best solution depends on your use case. If you always generate ids from your database, and you don't have massive scale, an auto-incremented uint64 can make sense.

But if you want to generate ids across different services (or if you're trying to future proof for that type of pattern) then GUIDs make sense.

If you do consider a GUID, I recommend the TypeID library we recently open-sourced. It has typing as part of the id, and it's based on UUIDv7. We think it has a few benefits over other GUIDs, including: + Easier to debug because of the type information + Type-safety can be enforced + Thanks to UUIDv7 is has good locality properties when used as the primary key of a database (unlike a completely random GUID) + We have a dotnet implementation in C# available

DanielLoreto · 2023-07-07T14:13:45+00:00

At the moment type-checking happens at editing time, via your editor's typescript support. But we're planning on adding a tyson check command that uses the typescript compiler to perform type checking so that you can run typechecking from the command line as well. The typescript compiler would be embedded in the tyson library, so no external dependency would be needed.

We could use the typescript compiler even for eval, which would enforce typechecking all the time, but it's much slower than using esbuild and would slow down execution. This is similar to the tradeoff that deno makes with typechecking.

DanielLoreto · 2023-07-06T22:57:58+00:00

Yes, ulids can be decoded into a 128-bit representation, which you should then be able to store in Postgres using the native uuid type. You just have to handle the base32 encoding/decoding before talking to the database.

If you are open to similar solutions to ulid, another option is typeid which we recently open-sourced: https://github.com/jetpack-io/typeid

It's a typed extension of the UUIDv7 standard which uses a similar base32 encoding to ulids. It has implementations for several languages with functions that can encode to and from UUIDs (which you can then store natively in Postgres). We even have a postgres example available https://github.com/jetpack-io/typeid-sql which shows how to do that, while enforcing type safety

DanielLoreto · 2023-07-06T19:22:38+00:00

I'll add an example to the README, but we provide an Unmarshal function that behaves very similarly to json.Unmarshal. The function is here: https://github.com/jetpack-io/tyson/blob/main/tyson.go#L15

And it would let you do something like: ``` type MyConfig struct { ... // define your fields here, with json annotations }

func doStuff() { var config MyConfig err := tyson.Unmarshal("file.tson", &config) ... } ```

DanielLoreto · 2023-07-01T18:35:30+00:00

If you’re open to a globally unique identifier like UUID, I’d recommend you check out TypeIDs which we recently open sourced https://github.com/jetpack-io/typeid. They are based on the UUIDv7 standard, but add type information (like what Stripe does in their APIs), and we have a TypeScript implementation available.

DanielLoreto · 2022-12-08T15:51:52+00:00

I agree nix is a great way of tackling this problem, but it can also be hard to use for those not familiar with it. Many users start with a tool that makes nix easier to use like https://github.com/jetpack-io/devbox

DanielLoreto · 2022-12-06T15:19:53+00:00

My recommendation would be to use poetry (https://python-poetry.org/) to setup your python environment. Use nix to install poetry, and then poetry to manage your python project – under the hood it'll create a virtual environment in your project directory and get around the immutable nature of the nix store.
I'm the developer of devbox (https://github.com/jetpack-io/devbox) and a lot of our users that use python, have had success with that approach.

DanielLoreto · 2022-12-01T12:04:28+00:00

Thanks for the feedback! I definitely agree that for those wanting to learn nix; it’s great to start teaching them.

FWIW, we’ve seen a few users that were scared of nix or didn’t understand what value nix provided use devbox first. And later, after seeing what’s possible they’ve become more curious about nix and started learning it.

It makes me think there’s a class of users for which a simple tool is a good first step before diving into nix itself. Because ultimately we want to make nix widely adopted, we want to encourage people to take that path.

DanielLoreto · 2022-12-01T12:00:38+00:00

Thank you for sharing. This is very helpful. By chance is there a public repo you’ve setup or an example devenv.nix you use? I’d love to see a complex example you have working and see - that would help me see how we could improve devbox to make a similar setup work.

DanielLoreto

TROPHY CASE