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

Bridging Elixir and Python with Oban

oban.pro

Post reply on HN
Print view View original

31–40 of 57 posts

Re: Bridging Elixir and Python with Oban

#31

Post by baseonmars »

dnautics wrote: post #20
HorizonXP wrote: post #14

Earlier quoted context omitted.

So I know these are just benchmarks, but apparently Elixir is one of the best languages to use with AI, despite having a smaller training dataset: https://www.youtube.com/watch?v=iV1EcfZSdCM and https://github.com/Tencent-Hunyuan/AutoCodeBenchmark/tree/ma... Furthermore, it's actually kind of annoying that the LLMs are not better than us, and still benefit from having code properly typed, well-architected, and split…

I don't think LLMs benefit from having code properly typed (at the call definition). It's costly to have to check a possibly remote file to check. The LLM should be able to intuit what the types are at the callsite and elixir has ~strong conventions that LLMs probably take advantage of

llms benefit greatly from feedback and typing/type errors are one of the fastest and easiest methods of feedback to give to an llm.

Re: Bridging Elixir and Python with Oban

#32

Post by ch4s3 »

Towaway69 wrote: post #26
dnautics wrote: post #22

Earlier quoted context omitted.

Don't assume. Empirically, they are not. (This post Feb 2026 may change in future yadda yadda) See: autocodebench https://github.com/Tencent-Hunyuan/AutoCodeBenchmark/tree/ma...

Reading that made me think how much that might be related to Elixir being very similar in syntax to Ruby. Do LLMs really differentiate between the two? Specific studies, as the one quoted, are a long way from original real world problems.

Having written a lot of both languages, I'd be surprised if LLMs don't get tripped up on some of Ruby's semantics and weird stuff people do with monkey patching. I also find Ruby library documentation to be on average pretty poor.

Re: Bridging Elixir and Python with Oban

#33

Post by ricketycricket »

Towaway69 wrote: post #26
dnautics wrote: post #22

Earlier quoted context omitted.

Don't assume. Empirically, they are not. (This post Feb 2026 may change in future yadda yadda) See: autocodebench https://github.com/Tencent-Hunyuan/AutoCodeBenchmark/tree/ma...

Reading that made me think how much that might be related to Elixir being very similar in syntax to Ruby. Do LLMs really differentiate between the two? Specific studies, as the one quoted, are a long way from original real world problems.

Here are some thoughts on it from José Valim: https://dashbit.co/blog/why-elixir-best-language-for-ai

LLMs absolutely understand and write good Elixir. I've done complex OTP and distributed work in tandem with Sonnet/Opus and they understand it well and happily keep up. All the Elixir constructs distinct from ruby are well applied: pipes, multiple function clauses, pattern matching, etc.

I can say that anecdotally, CC/Codex are significantly more accurate and faster working with our 250K lines of Elixir than our 25K lines of JS (though not typescript).

Re: Bridging Elixir and Python with Oban

#34

Post by techpression »

jongjong wrote: post #11

I don't see the point of Elixir now. LLMs work better with mainstream languages which make up a bigger portion of their training set. I don't see the point of TypeScript either, I can make the LLM output JavaScript and the tokens saved not having to add types can be used to write additional tests... The aesthetics or safety features of the languages no longer matter IMO. Succinctness, functionality and popularity of…

Your code doesn’t run anywhere? Running on the BEAM is extremely helpful for a lot of things. Also, I review my LLM output, I want that experience to be enjoyable.

Re: Bridging Elixir and Python with Oban

#35

Post by rozap »

markstos wrote: post #25
ananthakumaran wrote: post #10

We have a similar use case. All Elixir code base, but need to use Python for ML libraries. We decided to use IPC. Elixir will spawn a process and communicate over stdio. https://github.com/akash-akya/ex_cmd makes it a breeze to stream stdin and stdout. This also has the added benefit of keeping the Python side completely stateless and keeping all the domain logic on the Elixir side. Spawning a process might be slower…

Is this part of a web server or some other system where you could end up spawning N python processes instead of 1 at a time?

I use a similar strategy for python calls from elixir. This is in a web server, usually they're part of a process pool. So we start up N workers and they hang out and answer requests when needed. I just have an rpc abstraction that handles all the fiddly bits. The two sides pass erlang terms back and forth. Pretty simple.

Re: Bridging Elixir and Python with Oban

#36

Post by OkayPhysicist »

Towaway69 wrote: post #26
dnautics wrote: post #22

Earlier quoted context omitted.

Don't assume. Empirically, they are not. (This post Feb 2026 may change in future yadda yadda) See: autocodebench https://github.com/Tencent-Hunyuan/AutoCodeBenchmark/tree/ma...

Reading that made me think how much that might be related to Elixir being very similar in syntax to Ruby. Do LLMs really differentiate between the two? Specific studies, as the one quoted, are a long way from original real world problems.

I suspect the biggest advantage Elixir has is the relative quality of the publicly available code. Approximately no one has Elixir as their first programming language, which keeps a lot of the absolute trash-tier code that we all make when first learning to program out of the training set. If you look at languages that are often people's first (Python, JavaScript, Java), only Java has an above average score. Of those three, Java's significantly more likely to be taught in a structured learning environment, compared to kids winging it with the other two.

(And Elixir's relationship to Ruby is pretty overstated, IMO. There's definitely inspiration, but the OO-FP jump is a makes the differences pretty extreme)

Re: Bridging Elixir and Python with Oban

#38

Post by Towaway69 »

ch4s3 wrote: post #32
Towaway69 wrote: post #26

Earlier quoted context omitted.

Reading that made me think how much that might be related to Elixir being very similar in syntax to Ruby. Do LLMs really differentiate between the two? Specific studies, as the one quoted, are a long way from original real world problems.

Having written a lot of both languages, I'd be surprised if LLMs don't get tripped up on some of Ruby's semantics and weird stuff people do with monkey patching. I also find Ruby library documentation to be on average pretty poor.

> I also find Ruby library documentation to be on average pretty poor.

That surprises me :)

From my time doing Ruby (admittedly a few years back), I found libraries were very well documented and tested. But put into context of then (not now), documentation and testing weren't that popular amongst other programming languages. Ruby was definitely one of the drivers for the general adaption of TDD principles, for example.

Re: Bridging Elixir and Python with Oban

#39

Post by dnautics »

baseonmars wrote: post #31
dnautics wrote: post #20

Earlier quoted context omitted.

I don't think LLMs benefit from having code properly typed (at the call definition). It's costly to have to check a possibly remote file to check. The LLM should be able to intuit what the types are at the callsite and elixir has ~strong conventions that LLMs probably take advantage of

llms benefit greatly from feedback and typing/type errors are one of the fastest and easiest methods of feedback to give to an llm.

Think about fitts law: the fastest place to click under a cursor is the location of the cursor. For an LLM the least context-expensive feedback is no feedback at all.

I think codebases that are strongly typed sometimes have bad habits that "you can get away with" because of the typing and feedback loops, the LLM has learned this.

https://x.com/neogoose_btw/status/2023902379440304452?s=61

Re: Bridging Elixir and Python with Oban

#40

Post by barrell »

ananthakumaran wrote: post #10

We have a similar use case. All Elixir code base, but need to use Python for ML libraries. We decided to use IPC. Elixir will spawn a process and communicate over stdio. https://github.com/akash-akya/ex_cmd makes it a breeze to stream stdin and stdout. This also has the added benefit of keeping the Python side completely stateless and keeping all the domain logic on the Elixir side. Spawning a process might be slower…

Similar use case as well. I use erl ports to spawn a python process as well. Error handling is a mess, but using python as a short scripting language and elixir for all the database/application/architecture has been very ideal
Post reply on HN