DAGWorks Inc. reposted this
A #Burr user shared this video https://lnkd.in/gie9N6TG with me on the "problem with frameworks". Worth a watch. I 💯% agree with the take home. The "coupling problem" is the reason why people graduate out of frameworks like LangChain & LlamaIndex. You become overly coupled and then find yourself overtime asking why am I using this? It's not that the framework authors did this maliciously, it's just that they optimized for their needs, in this case for POCs, which is not the same as long lived maintainable code. That's why we see people either build their own frameworks, or they hopefully discover #hamilton & #burr and realize that there are frameworks that allow "loose coupling" that don't get in your way (as a platform person and framework author we optimize for maintainable code - and the user who shared the video agrees and is why they use Burr). A good example of this is FastAPI - very easy to not couple your business logic and iterate quickly no matter the age of the code. So how can you tell where a framework lies on the spectrum of tight coupling versus not? Some tests: (1) How many "objects" do I need to use from the framework to couple the logic I want to happen? The fewer the better. E.g. with #hamilton by default it's 0. With #burr it's just 1 and that's due to state for edge transitions, but that's easy to decouple from. (2) How many framework imports do you need to get something to run? The less the better - consider #burr vs LangChain using #langgraph (see image). If you're feeling framework pains, or are curious on how it can be done right, checkout the links in the comments, or comment yourself/tag someone who you think would like this post. #python #opensource #genai #llmops
CEO @ DAGWorks Inc. | Co-creator of Hamilton & Burr | Pipelines & Agents: Data, Data Science, Machine Learning, & LLMs
1moLinks: - https://github.com/DAGWorks-Inc/burr (agents) - https://github.com/DAGWorks-Inc/hamilton (pipelines/tools) - Subscribe to our blog - https://blog.dagworks.io