GraduateQuant

@JaneStreetGroup _might_ open sources a LLM trained for OCaml coding --- Actually it's more like I hope this will happen. I think they are the only one that is able to do this.

I think it makes sense to have some sort of "regularization" for LLM generated code to avoid "overfitting" test case failure. Some metrics could be: lines of code, nested level in a function, and etc.

A very good explanation of dune's mental model from dune's doc. Great read to pay off the study debt I accumulated from skipping the docs and resorting to help from LLM. dune.readthedocs.io/en/stable/expl…

Nice talk about OxCaml. Good to watch in combination with the @JaneStreetGroup tech blogs about OxCaml youtu.be/wbrELQrzwQk?si…

@samuelcolvin @japborst @aniketmaurya @permutans @pydantic I'd agree that the error message in this example is not very intuitive. I've seen similar errors dozens of times but almost every time my brain naturally focuses on the start of "Field required ..." and expect the most important bit (`age`) to come after.

@japborst @aniketmaurya @permutans @pydantic Humm, it's not really an apples to apples comparison - ty is a CLI so they control the output, can use ansi colors etc. pydantic is a library, so we don't have that flexibility.

why are pydantic errors so hard to understand

Here's a collection of useful patterns I've found after vibe-coding 150 different single-file HTML tools over the past couple of years simonwillison.net/2025/Dec/10/ht…

- having a separate set of assertions at each call site helps to ensure that refactoring around one call site doesn’t break the other

- We love the readability benefit of asserts so much that we even have a special maybe(condition); assertion, which is a no-op: it signals that the condition might be true at runtime, shining a spotlight on an otherwise non-obvious aspect of code

About design by contract: tigerbeetle.com/blog/2023-12-2… - One area where you do need first-class support for DbC is inheritance in object-oriented languages: derived classes can weaken the preconditions and strengthen the postconditions, and coding that manually does add boilerplate

A good read on how you can implement a snapshot testing library in any language. You just need some way to obtain the information about line number at ?runtime. I think there's no good snapshot testing tools in Julia and Haskell. Maybe I can make one? tigerbeetle.com/blog/2024-05-1…

My opinion on 2020+ AI: - Attention is all you need ❌ - Next token prediction is all you are ✅

@langchain I think when the market of "ai" building libraries matures, the absolute quality of engineering matters. My bet is on @pydantic ecosystem (pydantic-ai, logfire, pydantic-eval) Context: I work with both of them in my daily job.

@langchain In the end people boil down best practices and concepts that persist. and real innovation starts to emerge by composing primitive. I think that's when frameworks get less overwhelming. But it will still take a portion of the market as there are always new joiners.

Framework (eg @langchain) bundles with opinions or say views. It limits the action space so you feel you are guided (and it is). In the era of LLM everyone is desperate to use "ai" for something. I think that's one of the main reasons it gets wide adoption at the beginning.

Congratulations to LangChain. The less you think of their tech, the more impressive this raise is! But maybe this is a good time to remind everyone that there is a better alternative built on open standards and engineering rigor, that won't cost you more than your inference. Here's how to compare the LangChain and @pydantic Stacks: * if you want to use a proprietary tracing protocol, choose LangGraph and LangSmith; if you want to use OpenTelemetry, choose Pydantic AI and Logfire * if you want separate observability platforms for engineering and AI, choose LangSmith + Datadog; if you think AI IS engineering and you want one platform, choose Logfire * if you want to pay $500 per million traces (or $4,500 per million traces for increased retention), choose LangSmith; if you want to pay $2 per million spans, choose Logfire (yup, you read those numbers right) * If you think type safety is an annoying irrelevance, choose LangGraph; if you think type safety is extremely useful for human developers and table stakes for AI developers, choose Pydantic AI * If you know you're agent run will never take longer than ~10s and never need to survive a host restart, choose LangGraph; if you want to full durable execution with multiple backends, choose Pydantic AI * If you think evals should be deeply integrated with the platform you view them on, choose LangSmith; if you think your evals harness should be open source and standalone, then emit OTel, choose pydantic-evals and Logfire (This is a snarky post, but my congratulations are genuine. The LangChain team are clearly very effective at raising money, and marketing, and those are real skills. 🙌)