scolvin

This guy has nice hair.

Please report any panics, we'll fix them!

No one is going to let an LLM get prompted by end users to write python code I just run on my server, there's no real debate on that.

As discussed on twitter, v8 shows that's not true.

But to be clear, we're not even targeting the same "computer use" use case I think e2b, daytona, cloudflare, modal, fly.io, deno, google, aws are going after - we're aiming to support programmatic tool calling with minimal latency and complexity - it's a fundamentally different offering.

Chill, e2b has its use case, at least for now.

Can't be sure where this might end, but the primary goal is to enable codemode/programmatic tool calling, using the external function call mechanism for anything more complicated.

I think in the near term we'll add support for classes, dataclasses, datetime, json. I think that should be enough for many use cases.

this is pretty performant for short scripts if you measure time "from code to rust" which can be as low as 1us.

Of course it's slow for complex numerical calculations, but that's the primary usecase.

I think the consensus is that LLMs are very good at writing python and ts/js, generally not quite as good at writing other languages, at least in one shot. So there's an advantage to using python/js/ts.

ROFL.

I clearly didn't build pydantic "to take VC money" - I maintained Pydantic for 5 years before deciding to take VC money.

I wanted to build logfire and I didn't want to compete with or restrict our open source, we so built logfire.

Let's see on the investment; seems to be going pretty well so far.

We have a SaaS platform (Pydantic Logfire - General and AI observability), and we raised our Series A from Sequoia.

For good or bad, I think we're pretty "SaaS/vc/etc." already.

Correction, logging used to suck - now it's fixed https://pydantic.dev/logfire :-)

Pydantic creator here - I kind of agree with the article. I (obviously very biased) use Pydantic a fair bit, but there are places where it's the wrong tool and I use dataclasses, typeddicts or even tupleS a fair bit.

Sad about the Pydantic hater jumping on this to suggest it means you shouldn't use Pydantic at all, but I guess success (even open source success where you pay us nothing) comes with haters.

Thanks for the article.

Pydantic author here. We have plans for an improvement to pydantic where JSON is parsed iteratively, which will make way for reading a file as we parse it. Details in https://github.com/pydantic/pydantic/issues/10032.

Our JSON parser, jiter (https://github.com/pydantic/jiter) already supports iterative parsing, so it's "just" a matter of solving the lifetimes in pydantic-core to validate as we parse.

This should make pydantic around 3x faster at parsing JSON and significantly reduce the memory overhead.

See https://github.com/pydantic/pydantic-ai/issues/112 people have tried quite a few models.

Llama3.2 worked well and used <2gb ram

Interesting, but this doesn't support multiple tools with different arguments, or an arbitrary number of steps in the conversation. If you add that, you basically get PydanticAI.

Thank you so much!

Thanks. We won't be bulletproof on day one, but we'll get there.

Another advantage of OTel is you can always send your data somewhere else as a backup.

We'll offer self hosting for enterprise.

I want the entry level for "enterprise" to be much lower than some other companies in this space.

I think that's fair. It's a hard problem.

We could have called the company a completely new name and everyone would have been confused, or just called us "pydantic".

I think Pydantic being the company name, and a standalone entity, and there being other products is fairly common. I think if Logfire is successful, it will end up just being known as "Logfire".

You can send data from any OTLP endpoint, so yes.

I don't think we currently expose an easy way for you to send data to two (e.g. honeycomb and logfire), it it should be entirely doable, and if people want that, we can make it easy.

If anyone is mislead about whether Pydantic is Logfire or visa-versa, I'll eat my hat.

Other than that, see my answer to the other comment.

Pydantic creator here.

I understand why this might be your reaction, but let me just share my thoughts:

Can we build all the LLM things people want? Yes I think so, early feedback is that Logfire is already much more comprehensive than LLM specific solutions.

How is our solution any different? AFAIK:

* no one else offers opinionated wrapper for OTel to make it nicer to use, but with all the advantages

* no one else does auto-tracing (basically profiling) using import hooks the way we do

* no one else has dedicated instrumentation for OpenAI or Pydantic

* no one else provides metadata about python objects the way we do so we can render a semi-faithful repr of complex objects (Pydantic models, dataclasses, dataframes etc.) in the web UI

* no one else (except Sentry, who are doing something different) makes it really easy to start using it

* no one else lets you query observability data with SQL

In my mind, the obvious alternative would be to do the thing most OSS companies do, and build "Pydantic Cloud", then start adding features to that instead of the open source package. I didn't want to do that, and I don't think our users would like that either.

In the end I decided to build Logfire for two reasons:

1. I wanted it, and have wanted it for years

2. I think building a commercial product like this, then using OSS to spread the word and drive adoption is a really exciting way to incentivize us to make the open source as good as possible — good as-in permissive and good as-in well maintained. And it means that our commercial success is not in tension with the adoption of our open source, which has been a recurring issue for companies trying to capitalize on their open source brand.