I agree - LangChain is totally awesome and unlocks amazing new capabilities of LLMs (easily!), but the code itself is pretty awkward. No logging framework, for instance, and the strong typing enforcement with pydantic seems un-pythonic and brittle to me (what if I want to use a different kind of Mappable instead of a dict for something?). Still, great work overall and congrats to the team!

Indeed, the team has done momentum, community and probably other things well, congrats to them!

Whatever time pydantic is supposed to have saved me from making dumb mistakes, I've wasted 100x more trying to shoehorn stuff into some poorly thought-out schema.

For FastAPI, Pydantic ends up being part of the API contract. It's less about saving time and more about validating requests.

> what if I want to use a different kind of Mappable instead of a dict for something?

You can use custom field types either by using a `validator` with `pre=True` or a define a class with a `__get_validators__` classmethod.

But pydantic does have problems, imho it isn't strict enough & has given me the wrong types when using `Union`s a bunch of times. Rust's `serde` is the best tool for data modeling I've encountered. Defining custom encoding & decoding behavior is harder than it needs to be. The purely narrative documentation is easy to learn but difficult to reference.

I would agree that strict typing is unpythonic but in this case I think this is an outdated opinion of Python, one that it's been backpedaling on with type annotations &c. I think Python made perfectly reasonable decisions about this some 30 years ago, and they haven't aged well, which isn't even really a criticism as much as a consequence of it's enormous success. Python had outlived a lot of the ideas & attitudes about language design that went into making it, and carries them as scar tissue.