21–30 of 57 posts
I absolutely love Elixir, but if this is the bridge you need to cross, just write it in Python in the first place.
It's 2026 and the LLMs score high on elixir, just write it in python and patch it over to elixir gradually
Earlier quoted context omitted.
It's 2026 and the LLMs score high on elixir, just write it in python and patch it over to elixir gradually
Or patch it over to python, I assume LLMs are even better at python.
See: autocodebench
https://github.com/Tencent-Hunyuan/AutoCodeBenchmark/tree/ma...
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…
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…
Earlier quoted context omitted.
Or patch it over to python, I assume LLMs are even better at python.
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...
Specific studies, as the one quoted, are a long way from original real world problems.
I feel like if you need to utilize a tool like this, odds are pretty good you may have picked the Wrong Tool For the Job, or, perhaps even worse, the wrong architecture. This is why it's so important to do lots of engineering before writing the first line of code on a project. It helps keep you from choosing a tool set or architecture out of preference and keeps you honest about the capabilities you need and how your…
Choosing a single tool that tries to solve every single problem can lead to its own problems.
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…
No. I would argue that popularity per se is irrelevant: if there are a billion examples of crap code, the LLMs learn crap code. conversely know only 250 documents can poison an LLM independent if model size. [Cite anthropic paper here].
The most important thing is conserve context. Succinctness is not really what you want because most context is burned on thinking and tool calls (I think) and not codegen.
Here is what I think is not important: strong typing, it requires a tool call anyways to fetch the type.
Here is what I think is important:
- fewer footguns - great testing (and great testing examples) - strong language conventions (local indicators for types, argument order conventions, etc) - no weird shit like __init__.py that could do literally anything invisible to the standard code flow
I feel like if you need to utilize a tool like this, odds are pretty good you may have picked the Wrong Tool For the Job, or, perhaps even worse, the wrong architecture. This is why it's so important to do lots of engineering before writing the first line of code on a project. It helps keep you from choosing a tool set or architecture out of preference and keeps you honest about the capabilities you need and how your…
It’s almost as though choosing a single-threaded, GIL-encumbered interpreted scripting language as the primary interface to an ecosystem of extremely parallelized and concurrent high-performance hardware-dependent operations wasn’t quite the right move for our industry.
I can't guess. Perl was once the "800-pound gorilla" of web development, but that chapter has long been closed. Python on the other hand has only gained traction since that time.
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…
I have one vibecoded ml pipeline now and I'm strongly considering just clauding it into Nx so I can ditch the python
You may run into some issues with Docker and native deps once you get to production. Don’t forget to cache the bumblebee files.