4 ms·

I appreciate that you're taking feedback seriously, and it sounds like you're making some good changes. But frankly, all my goodwill was burnt up in the days I

by causal 2y ago

I appreciate that you're taking feedback seriously, and it sounds like you're making some good changes. But frankly, all my goodwill was burnt up in the days I spent trying to make LangChain work, and the number of posts I've seen like this one make it clear I'm not the only one. The changes you've made might be awesome, but it also means NEW abstractions to learn, and "fool me once..." comes to mind. But if you're sure it's in a much better place now, then for marketing purposes you might be better off relaunching as LangChain2, intentionally distancing the project from earlier versions.

ctxc 2y ago
They were early to the scene, made the decisions that made sense at each point in time. Initially I (like many other engineers with no AI exposure) didn't know enough to want to play around with the knobs too much. Now I do. So the playing field has and is changing, langChain are adapting. Isn't that a bit too extreme? Goodwill burnt up? When the field changes, there will be new abstractions - of course I'll have to understand them to decide for myself if they're optimal or not. React has an abstraction. Svelte has something different. AlpineJS, another. Vanilla JS has none. Does that mean only one is right and the remaining are wrong? I'd just understand them and pick what seems right for my usecase.
- causal 2y ago
  You seem to be implying all abstractions are equal, its just use-case dependent. I disagree- some really are worse than others. In your webdev example, it would not be hard to contrive a framework designed to frustrate. This can also happen by accident. Sometimes bad products really do waste time. In the case of LangChain, I think it was an earnest attempt, but a misguided one. So I'm grateful for LangChain's attempt, and attempts to correct- especially since itis free to use. But there are alternatives that I would rather give a shot first.
  - mikeqq2024 2y ago
    What alternatives are you tring and how good/bad about those?
- int_19h 2y ago
  I don't think the choices made sense even back when they were made. LangChain always looked like an answer in search of a question, a collection of abstractions that don't do much except making a simple thing more complex.
hwchase17 2y ago
sorry to hear that, totally understand feeling burnt ooc - do you think theres anything we could do to change that? that is one of the biggest things we are wrestling with. (aside from completely distancing from langchain project)
- causal 2y ago
  I'm not sure. My suspicion is that the fundamental issue with frameworks like LangChain is that the problem domain they are attempting to solve is a proper subset of the problems that LLMs also solve. Good code abstractions make code more tractable, tending towards natural language as they get better. But LLMs are already at the natural language level. How can you usefully abstract that further? I think there are plenty of LLM utilities to be made- libraries for calling models, setting parameters, templating prompts, etc. But I think anything that ultimately hides prompts behind code will create more friction than not.
  - causal 2y ago
    Glad to hear that- sounds like I should give LangGraph a try after all
    - hwchase17 2y ago
      would love any feedback if you do!
  - hwchase17 2y ago
    totally agree on not hiding prompts, and have tried to stop doing that as much as possible in LangChain and are not doing that at all in LangGraph thanks for the thoughts, appreciate it
- chatmasta 2y ago
  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 retaining specialized behavior of each provider. But it’s not a leaky abstraction. The “chaining” part is a huge problem space where the proper solution looks different in every context. It’s all the problems of templating engines, ETL scripts and workflow orchestration. (Actually I’ve had a pet idea for a while, of implementing a custom react renderer for “JSX for LLMs”). Stay away from that. 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 deep on those. What you’re doing now is doubling down on your first success, even though it might not be the best solution to the problem (or that it might be a solution looking for a problem).

by causal 2y ago

ctxc 2y ago

They were early to the scene, made the decisions that made sense at each point in time. Initially I (like many other engineers with no AI exposure) didn't know enough to want to play around with the knobs too much. Now I do. So the playing field has and is changing, langChain are adapting. Isn't that a bit too extreme? Goodwill burnt up? When the field changes, there will be new abstractions - of course I'll have to understand them to decide for myself if they're optimal or not. React has an abstraction. Svelte has something different. AlpineJS, another. Vanilla JS has none. Does that mean only one is right and the remaining are wrong? I'd just understand them and pick what seems right for my usecase.

causal 2y ago
You seem to be implying all abstractions are equal, its just use-case dependent. I disagree- some really are worse than others. In your webdev example, it would not be hard to contrive a framework designed to frustrate. This can also happen by accident. Sometimes bad products really do waste time. In the case of LangChain, I think it was an earnest attempt, but a misguided one. So I'm grateful for LangChain's attempt, and attempts to correct- especially since itis free to use. But there are alternatives that I would rather give a shot first.
- mikeqq2024 2y ago
  What alternatives are you tring and how good/bad about those?
int_19h 2y ago
I don't think the choices made sense even back when they were made. LangChain always looked like an answer in search of a question, a collection of abstractions that don't do much except making a simple thing more complex.

hwchase17 2y ago

sorry to hear that, totally understand feeling burnt ooc - do you think theres anything we could do to change that? that is one of the biggest things we are wrestling with. (aside from completely distancing from langchain project)

causal 2y ago
I'm not sure. My suspicion is that the fundamental issue with frameworks like LangChain is that the problem domain they are attempting to solve is a proper subset of the problems that LLMs also solve. Good code abstractions make code more tractable, tending towards natural language as they get better. But LLMs are already at the natural language level. How can you usefully abstract that further? I think there are plenty of LLM utilities to be made- libraries for calling models, setting parameters, templating prompts, etc. But I think anything that ultimately hides prompts behind code will create more friction than not.
- causal 2y ago
  Glad to hear that- sounds like I should give LangGraph a try after all
  - hwchase17 2y ago
    would love any feedback if you do!
- hwchase17 2y ago
  totally agree on not hiding prompts, and have tried to stop doing that as much as possible in LangChain and are not doing that at all in LangGraph thanks for the thoughts, appreciate it
chatmasta 2y ago
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 retaining specialized behavior of each provider. But it’s not a leaky abstraction. The “chaining” part is a huge problem space where the proper solution looks different in every context. It’s all the problems of templating engines, ETL scripts and workflow orchestration. (Actually I’ve had a pet idea for a while, of implementing a custom react renderer for “JSX for LLMs”). Stay away from that. 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 deep on those. What you’re doing now is doubling down on your first success, even though it might not be the best solution to the problem (or that it might be a solution looking for a problem).