Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why we no longer use LangChain for building our AI agents

octomind.dev

Post reply on HN
Print view View original

281–290 of 307 posts

Re: Why we no longer use LangChain for building our AI agents

#281

Post by manquer »

randomdata wrote: post #78
manquer wrote: post #54

Earlier quoted context omitted.

What GP means is it is a Programmable Interface, any interface you can interact against is an API. That means any programing complete language is an API, so are sign languages or human languages. While nobody does it , SQL implementations have network API, authentication, authorization, ACL/RBAC, serialization, Business logic all the things you use in RESTful apis can all be done with just db servers. You can expose…

SQL (as an API) and databases are orthogonal, though. In fact, I work on an application that uses SQL for its API even though it doesn't even have a database directly attached. All of its data comes from third-parties that only make the data available using REST services. In theory, the app servers that sit in front of those databases could just as easily use SQL instead of GraphQL. Even practically: The libraries ar…

I didn’t say it was a good idea , just elaborated that it is possible.

Even if it was easy and solved it all the things say GraphQL does it is still a bad idea .

Scaling app servers is relatively easy especially if stateless and follow some of the 12f principles, scaling SQL server horizontally is hard.

Multi master , partitioning, sharding even indexing very large tables , de-normalization is ripe with pitfalls and gotchas and many times what works for one app won’t work for the next , keeping the store simple and as less logic as possible saves a lot of pain

Re: Why we no longer use LangChain for building our AI agents

#282

Post by newzisforsukas »

int_19h wrote: post #267
newzisforsukas wrote: post #174

Earlier quoted context omitted.

You can implement a GraphQL service in anyway you desire. There is no inherent relation to the storage solution you use. GraphQL isn't anywhere close to being similar to SQL, so I find the desire for an analogy very confusing. To me, these are grammars for interacting with an API, not an API. To me, it is like calling a set of search parameters in a URL an API or describing some random function call as an API. The in…

What is your definition of API?

The normal definition, I believe.

A software interface between entities (components, programs, etc) that allows for communication between those entities.

What is yours?

Re: Why we no longer use LangChain for building our AI agents

#283

Post by chatmasta »

hwchase17 wrote: post #241
chatmasta wrote: post #239

Earlier quoted context omitted.

My advice is to focus less on the “chaining” aspect and more on the “provider agnostic” part. That’s the real reason people use something other than the native SDK of an LLM provider - they want to be able to swap out LLMs. That’s a well-defined problem that you can solve with a straight forward library. There’s still a lot of hidden work because you need to nail the “least common denominator” of the interfaces while…

> My advice is to focus less on the “chaining” aspect and more on the “provider agnostic” part a lot of our effort recently has been going into standardizing model wrappers, including for tool calling, images etc. this will continue to be a huge focus > My other advice would be to build a lot of these small libraries… take advantage of your resources to iterate quickly on different ideas and see which sticks. Then go…

Separating into smaller libraries is a smart move. And yeah, like you said, I might be bearish on the orchestration space, but at least you can insulate it from the rest of your projects.

Best of luck to you. I don’t agree with the disparaging tone of the comments here. You executed quickly and that’s the hardest part. I wouldn’t bet against you, as long as you can keep iterating at the same pace that got you over the initial hurdles.

Your funding gives you the competitive advantage of “elbow grease,” which is significant when tackling problems like N-M ETL pipelines. But don’t get stuck focusing on solving every new corner case of these problems. Look for opportunities to be nimble, and cast a wide net so you can find them.

Re: Why we no longer use LangChain for building our AI agents

#284

Post by int_19h »

randomdata wrote: post #273
int_19h wrote: post #264

Earlier quoted context omitted.

The "original sense" argument is frankly nonsense. Simula 67 was the original OOP language, predating Smalltalk, and it already had "classes" and "objects". It also looked a great deal like Java and the OOP parts of C++.

Simula 67 long predates OOP. Which, when you think about it, means that when OOP was coined it referred to a "message passing" paradigm, not "classes" or "objects". "Oriented" , not "object", was the operative word. Having objects does not make a language object-oriented, at least not as it was originally conceived. Simula 67, like Java, may fit into some newer OOP definitions that have come about over the years, but…

"Object-oriented" ipso facto refers to programming using objects. Simula had objects, and they were objects in the same exact way as Smalltalk objects are objects - a bundle of state with identity and behavior. Whether the exact term "OOP" was used by Simula authors is immaterial. The usual claim is that what makes Smalltalk special is message passing as opposed to method calls, but they are obviously isomorphic.

Re: Why we no longer use LangChain for building our AI agents

#285

Post by mike986 »

zby wrote: post #87

I am always suspicious with frameworks. There are two reasons of that. First is that because of the inversion of control they are more rigid than libraries. This is quite fundamental - but there are cases where the trade off is totally worth it. The second one is because of how they are created - it often starts with an application which is then gradually made generic. This is good for advertising - you can always sh…

from the first glance of the example, it seems like the 1st use case is invoking a function (selected by chatgpt) and the 2nd use case is similar to instructor.

can you comment how your library differs from instructor (what yours can do that instructor can't and vice versa?)

thanks

Re: Why we no longer use LangChain for building our AI agents

#286

Post by randomdata »

int_19h wrote: post #284
randomdata wrote: post #273

Earlier quoted context omitted.

Simula 67 long predates OOP. Which, when you think about it, means that when OOP was coined it referred to a "message passing" paradigm, not "classes" or "objects". "Oriented" , not "object", was the operative word. Having objects does not make a language object-oriented, at least not as it was originally conceived. Simula 67, like Java, may fit into some newer OOP definitions that have come about over the years, but…

"Object-oriented" ipso facto refers to programming using objects. Simula had objects, and they were objects in the same exact way as Smalltalk objects are objects - a bundle of state with identity and behavior. Whether the exact term "OOP" was used by Simula authors is immaterial. The usual claim is that what makes Smalltalk special is message passing as opposed to method calls, but they are obviously isomorphic.

Simula is basically C++ before C++, and we know C++ is not OOP in the original sense. When OOP was first defined, it was quite explicitly noted that C++ is not OOP. Java's object model follows in the same vein as this lineage. These are not OOP languages, as originally conceived.

Furthermore, message passing was the defining feature of OOP. Of course it was. That is the distinction OOP was calling attention to – what made OOP different from the other object-based languages that had been around for decades beforehand. Nobody was going to randomly come up with OOP out of the blue to describe a programming model from the long ago past. Method calling may be superficially similar, but OOP was coined to call attention to what difference there is.

You are, of course, quite free to come up with your own redefinition of OOP that includes Simula, C++, Java, whatever you wish. You would not be the first. However, as we are talking about the original definition, whatever you want to define it as does not apply. It is not your definition that is under discussion.

Re: Why we no longer use LangChain for building our AI agents

#287

Post by resource_waste »

LangChain tutorials be like:

Go to foo_website and put your credit card to get their API. Then go to bar_website, get their API. Then go to yayeee_website and get their API. Then go to...

But unironically.

I actually counted 4 APIs in some 'how to' article. I ended up DIYing that with 0 APIs.

Whoever got into langchain planted their APIs. That is why it sucks.

Re: Why we no longer use LangChain for building our AI agents

#288

Post by siva7 »

sc077y wrote: post #186

Damn I built a RAG agent during the past 3 months and a half for my internship. And literally everyone in my company was asking me why I wasn't using llangchain or llamaindex like I was a lunatic. Everyone else that built a rag in my company used llangchain, one even went into prod. I kept telling them that it works well if you have a standard usage case but the second you need to something a little original you have…

Matches my experience as well. I tried langchain about a year ago for an app and had a pretty standard use case but even going a little bit of rail and i had to dig up layers of abstractions where it would have been much easier just using the original openai lib. So it might be beneficial if your use case is about offering many different LLM providers in your app but if you know you won't be swapping out the LLM provider soon it's usually better to not use such frameworks.

Re: Why we no longer use LangChain for building our AI agents

#289

Post by siva7 »

danenania wrote: post #222
w4 wrote: post #200

Earlier quoted context omitted.

I had a similar experience when LangChain first came out. I spent a good amount of time trying to use it - including making some contributions to add functionality I needed - but ultimately dropped it. It made my head hurt. Most LLM applications require nothing more than string handling, API calls, loops, and maybe a vector DB if you're doing RAG. You don't need several layers of abstraction and a bucketload of depen…

I haven't used LangChain, but my sense is that much of what it's really helping people with is stream handling and async control flow. While there are libraries that make it easier, I think doing this stuff right in Python can feel like swimming against the current given its history as a primarily synchronous, single-threaded runtime. I built an agent-based AI coding tool in Go ( https://github.com/plandex-ai/plandex…

Not really. There isn't much that langchain is doing in this regard. The heavy lifting is already done by the original libs like from openai which they use and the rest are just wrappers around their api calls.

Re: Why we no longer use LangChain for building our AI agents

#290

Post by dmezzetti »

An alternative is using txtai (https://github.com/neuml/txtai). It's lightweight and works with both local and remote LLMs.

Here is an example article that shows how to use OpenAI calls with txtai: https://neuml.hashnode.dev/rag-with-llamacpp-and-external-ap...

Post reply on HN