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.

Pydantic author here.

Pydantic won't change again significantly, so it won't be any effort to keep it up-to-date.

There were good reasons to make all the changes made in the V1->V2 upgrade, I think those are pretty clear.

I think Pydantic is popular because of it's extremely flexible/powerful while also being intuitive to get started with.

We've had one very small change within V2, related solely to typing. I think you're overblowing this.

That's simply not true. It's much faster than most similar libraries, 16x faster than DRF, 30x faster than Cerberus.

Msgspec is impressive in some ways, but there are good reasons to use Pydantic instead - for a start msgspec is written in a non-memory safe language by (mostly) one person, and is less widely tested than Pydantic.

Yes I think that's fair as the no-brainer use case.

I hope it can be do more powerful things too.

That's probably not a very good strap line - FastUI let's you declare new views and parts of views without writing any React, but the frontend if still just React, albeit optionally pre-built.

As far as I can remember it just seemed sensible to me at the time.

Yes, Pydantic does: https://docs.pydantic.dev/latest/api/standard_library_types/...

Author of Pydantic here, very sorry you've had problems migrating. We were very aware this was going to cause problems, and have done our best to make migrating easier. I truly believe that v2 will be a big improvement.

I think there are two things going on:

1. Python: Python's laxness doesn't make it easy to define strict APIs or know when you're breaking them. The lack of export controls also means defining what's in the API and what's not is hard. Also Python's strong introspection makes it possible to do crazy things further blurring the API boundary.

2. The ecosystem: with pydantic as an example - the library has grown enormously, more than I ever imagined from an experiment in a file in another project to a major library used by thousands of millions of developers, for a very wise range of applications. I never imagined that happening, do I didn't think all that hard about the interface at the beginning, or even at the v1 release. I also knew much less back then.

I'm not sure this kind of growth is very common in other languages except JavaScript.

(Written on my phone, sorry for typos)

Please please take a look at V2, both the code and the documentation (although I admit, the documentation for V2 isn't finished).

I (the developer of Pydantic) had many of the same frustrations with Pydantic V2 which is why I've spent so long rewriting it to try and fix these concerns.

In particular:

* we now have API documentation [1] * we have first class support for validating `TypedDict` which gives you a typing-valid dict representation of your data straight out of validation * we now have strict mode * we're working hard to define an exact spec for what validates to what [2] * we have a strict separation between public/private - everything private is in a `pydantic._internal` module, and we have unit tests that everything which can be publicly imported is explicitly public * we now use `Annotated[]` for defining custom validations/constraints, together with annotated-types [3] * the protocol for customising validation and serialization has been significantly improved [4]

I'd really love to hear your feedback on V2 and what more we can do to improve it - your feedback seem unusual reasonable for HN ;-) - please email samuel@pydantic.dev or create an issue/discussion if you have any thoughts.

1: https://docs.pydantic.dev/latest/api/main/ 2: https://docs.pydantic.dev/latest/usage/conversion_table/ 3: https://github.com/annotated-types/annotated-types 4: https://docs.pydantic.dev/latest/usage/types/custom/

¯\_(ツ)_/¯ - I get different results, see the PR.