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.
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.
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.
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.
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.
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".
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.
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.