Hi there!
Is anyone aware of any attempts/plans by LangChain to support julia?
Any answer will be greatly appreciated!
Best!
Alex
2 Likes
Thanks for the response! In general, am wondering whether for such use cases one should simply use Python directly instead of Julia and if there is any benefit at all trying to use Julia, especially for such autonomous workflows, such as LangChain.
It depends on the workflow. How much of the code is in Python and how much of the code being executed is in C? If you’re running a lot of computational or numeric loops in Python, then Julia may be advantageous for example.
Hi mkitti,
Alex’s actual question has gone unanswered.
Even a newbie like me knows that one can call nearly anything in Python from Julia. Some of us can’t learn 50 programming languages and be good at any of them.
Are there any known plans for LangChain to support Julia directly?
1 Like
That seems like a question only the developers of GitHub - langchain-ai/langchain: ⚡ Building applications with LLMs through composability ⚡ can answer, assuming this is the LangChain in question.
1 Like
“I don’t know” is always a correct answer. 
Yes, I agree, the horse’s mouth is a very good place to start.
Ask LangChain?
2 Likes
A question worth considering is what would it look like if LangChain supported Julia? What do you actually want?
1 Like
I will also agree with @mkitti. It is a lot of work to replicate the functionality unless there is a specific advantage for the rewriting.
PythonCall.jl with CondaPkg.jl are doing a great job providing access to Python packages, and it is relatively easy to wrap your mind around the use of data living in two “workspaces,” especially if you have a collaborator that understands both Julia and Python.
2 Likes
There is already a few Rust reimplementations of langchain that look like they might be viable (the main advantage of rust is that it’s low level enough that it can deeply integrate/target multiple language VMs like py03, node, as well as other ecosystems like .net and jvm). I wonder if the gradual maturation of jlrs would provide a quick way to provide langchain-like support for julia: [ANN] jlrs 0.18: export code written in Rust à la CxxWrap
1 Like
Since LangChain does not seem to support Julia directly, “What would it look like if LangChain supported Julia?” is the next right question to ask, I think.
What I would like to do is not something particularly interesting to people outside academia; namely, to experiment with chains-of-thought and use arxiv’s API for interrogating research papers.
These two packages are good, indeed! And the key is, indeed, to be able to comfortably switch between the two “workspaces”.
I was just wondering whether someone has already done the dirty job and replicated the functionality on a separate package, as happened with the Transformers.jl package.
The ideal scenario for me is to find a direct Julia package which could help me avoid issues related to type consistency, dependencies on Python packages that need to be installed, and possible performance bottlenecks among others.
I don’t know if LangChain has plans to support Julia; since it doesn’t seem needed. You can already do all you want with LangCain by calling it in Python, using e.g. PythonCall.jl, just as you can call to (or from) any other Python library with it.
I’m trying to clarify for myself what LangChain is, and what it’s useful for, so and I actually asked (Bing) AI, and it answered referencing LangChain’s Wikipedia page: “It is not specifically designed for programming languages. However, it can be used for code analysis.”
Now, for code analysis the LLM used may or may not be good for Julia, but that seems independent of LangChain. I think you can use just any LLM, and some seemingly support Julia, e.g. latest state-of-the-art Google PaLM 2 seems to, at least they benchmark it relating to Julia and a few other programming languages.
LangChain is “written in Python and JavaScript”, I think it’s misleading, as you either use Python only (e.g. with Julia) or the other JavaScript implementation, if running on the web. That seems to be the reason to have two official implementations, not that no other language is usable, with either. [Julia can actually compile to JavaScript, so for the web you might use that implementation; or actually call Python, since it’s also possible to use Python on the web by now.]
You could also use implementations, e.g. those in Rust (I doubt better yet, or easier to call):
Isn’t jlrs mature? It doesn’t really matter, rather what matters, does it work (for this)? If jlrs (or any code) is not mature, you can pin versions.
It’s really easy to make a wrapper for Python code, but note, it’s not really needed because you can just use Python code directly with PythonCall.jl. So what’s the point? You use CPython in either case (same with Mojo…), and if you really want to avoid CPython (there’s not reason PythonCall installs it for you) you can’t use Python code now (except by translating it to Julia with the tool available, but don’t recommend doing that), then it would be better to use Rust code.
Thank you. That was a helpful review.