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

51–57 of 57 posts

Re: Bridging Elixir and Python with Oban

#51

Post by dnautics »

flippant wrote: post #30
dnautics wrote: post #18

Earlier quoted context omitted.

I have one vibecoded ml pipeline now and I'm strongly considering just clauding it into Nx so I can ditch the python

I did exactly this in early 2025 with a small keyword tagging pipeline. You may run into some issues with Docker and native deps once you get to production. Don’t forget to cache the bumblebee files.

No problem. It's an SLM, I have a dedicated on-prem GPU server that I deploy behind tailscale for inference. For training, I reach out to lambdalabs and just get a beefy GPU for a few hours for the cost of a Starbucks coffee.

Re: Bridging Elixir and Python with Oban

#52

Post by victorbjorklund »

mrcwinn wrote: post #16

I absolutely love Elixir, but if this is the bridge you need to cross, just write it in Python in the first place.

So if your app is 99% elixir but 1% is easier in Python because a lib you should rewrite the whole app? Makes no sense. Do you think Python devs rewrite everything in C if they have a small part that needs to use C instead of Python?

Re: Bridging Elixir and Python with Oban

#53

Post by victorbjorklund »

languagehacker wrote: post #13
geooff_ wrote: post #8

Earlier quoted context omitted.

I disagree, using python for a web-server and something like celery for background work is a pretty common pattern. My reading of this is it more or less allows you to use Postgres (which you're likely already using as your DB) for the task orchestration backend. And it comes with a cool UI.

That's not the sort of architecture I'm referring to. I'm specifically talking about splitting your application layer between Elixir and Python.

Wait until you find out about some people not writing pure python apps but also have some code in JavaScript. Crazy to mix more than one language in one machine.

Re: Bridging Elixir and Python with Oban

#54

Post by perrygeo »

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…

> Succinctness, functionality and popularity of the language are now much more important factors.

Not my experience at all. The most important factor is simplicity and clarity. If an LLM can find the pattern, it can replicate that pattern.

Language matters to the extent it encourages/forces clear patterns. Language with more examples, shorter tokens, popularity, etc - doesn't matter at all if the codebase is a mess.

Functional languages like Elixir make it very easy to build highly structured applications. Each fn takes in a thing and returns another. Side effects? What side effects? LLMs can follow this function composition pattern all day long. There's less complexity, objectively.

But take languages that are less disciplined. Throw in arbitrary side effects and hidden control flow and mutable state ... the LLM will fail to find an obviously correct pattern and guess wildly. In practice, this makes logical bugs much more likely. Millions of examples don't help if your codebase is a swamp. And languages without said discipline often end up in a swamp.

Re: Bridging Elixir and Python with Oban

#55

Post by jongjong »

dnautics wrote: post #39
baseonmars wrote: post #31

Earlier quoted context omitted.

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

This is well put. If the LLM gets the type wrong, then we're already discussing a failure scenario with a feedback loop involving back-and-forth changes.

LLMs are not really good at this. The idea that LLMs benefit from TypeScript is a case of people anthropomorphizing AI.

The kinds of mistakes AI makes are very different. It's WAY better than humans at copying stuff verbatim accurately and nailing the 'form' of the logic. What it struggles with is 'substance' because it doesn't have a complete worldview so it doesn't fully understand what we mean or what we want.

LLMs struggle more with requirements engineering and architecture since architecture ties into anticipating requirements changes.

Re: Bridging Elixir and Python with Oban

#56

Post by dnautics »

jongjong wrote: post #55
dnautics wrote: post #39

Earlier quoted context omitted.

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

This is well put. If the LLM gets the type wrong, then we're already discussing a failure scenario with a feedback loop involving back-and-forth changes. LLMs are not really good at this. The idea that LLMs benefit from TypeScript is a case of people anthropomorphizing AI. The kinds of mistakes AI makes are very different. It's WAY better than humans at copying stuff verbatim accurately and nailing the 'form' of the…

> The kinds of mistakes AI makes are very different.

I think that's a bit extreme. If a programming language has good ergonomics for a short attention span human, it will likely be better for an LLM too.

However, to make good predictions about what an LLM will or will not be good at you should have a good "theory of mind" for the LLMs that will in some ways be different from a human.

Re: Bridging Elixir and Python with Oban

#57

Post by pantsforbirds »

When rust was still a fairly new language i remember using capn'n proto to communicate between some rust code and python as a way to experiment with handing off performance critical tasks to a compiled language.

I wonder how well a similar approach would work with elixir + python. Elixir obviously has very easy process isolation, but I think you'd be stuck using a NIF approach for Elixir, which probably removes any reason to try capn'n proto over just protobufs?

Post reply on HN