Can the ideas from DeepSeek Harness be transferred to Elixir eco?

I am a fan of DeepSeek (out of all of the LLMs I have tried, its ‘personality’ is more in line with what I like, humble, smart, rather than arrogant, smart - like I’ve found some of the others) and they’re obviously technically skilled with all their advances and innovations.

Why not? Why not give it a try and see? As José said, the BEAM could well be a perfect fit (imo) especially:

Designing a client-server architecture, similar to OpenCode, is basically a byproduct of the actor model (plus you get both IO/CPU concurrency)

The built-in distribution means you can easily isolate the brains (model + session) from the hands (sandbox + tools).

Those can definitely be built from scratch in other languages, but in Elixir the building blocks are basically part of the runtime.

The first agent I had even used is a tiny agent writtern in Elixir, as a learning product of ClaudeCode’s source code leak. However, Elixir’s eco has very poor support for Windows(esp somthing which related OS, like TUI), so it was abandoned when model can execute simple task with tool callings and I decided others finally.

DeepSeek’s development approach for harness, which extracts an extremely abstract and minimal core, has a strong sense of “taste”, what is honey to one is poison to another. I like it, frankly. I’ve recently been working on a similar project, but it’s not applied for harness(or agent) and it’s not as radical as DeepSeek.

I wanna build a SVS(Singing Voice Synthesis) Engine(or Editor) since high school. And currently the foundation(make user intervention(e.g. override pitch curve/phoneme timing/etc.) as 1st class and DAG-engine) has been laid, now I’m focusing on refining the UI and real-world engine(like UTAU or DiffSinger/NNSVS).

The overall idea is to make everything composable. For example, I designed the tuning system to be pluggable to accommodate microtones other than only 12ET(mainstream DAW and SVS Editor like Vocaloid/UTAU only support this without plugin), or ethnic music from certain regions. This took several months since May. It’s currently over(the core, see GES233/Coconut and its rebase core SynapticStrings/Tamal), but I haven’t found a killer feature that can answer “Why elixir” yet.

One possible vision is once the PoC’s complete, deploy it online, consisting of a main server and several computing nodes performing GPU-intensive tasks(but once face memory error, NIF will crashed BEAM machine). For all world, the virtual singer(downstream of SVS) community is small. As long as there are no serious architectural problems (or DDoS attacks), the editor itself only requires one server and it can handle it perfectally.

It seems like I’m the only one whose intersect SVS X Elixir.

Ideas aren’t worth much so feel free to implement it(if you want). After all, the workload of the editor cannot be accomplished simply by telling the Agent one prompt.

I tried to re-implement cordis since yesterday(see GES233/Dexterous).

All I did was just simply convert the paper into markdown and send it to the Agent(Kimi K3 & Kimi Code / DeepSeek Harness, I choose Kimi because DeepSeek’s API price increased so high, and I had Kimi Code’s subscription for a year). LOC for extisted components is just ~2k.

Currently, all except HMR have been achieved(My initial suggestion was to use the native Elixir/BEAM concepts instead of the Cordis’ wheel/components). I wanted to reference Phoenix.CodeReloaderat beginning, but its too coarse(required next request and recompiling whole BEAM). Also, BEAM’s hot reloading mechanism and Cordis’s design are philosophically compatible, but differ in detail. I have to make a trade off. And cross-node/instance hot reload is not currently being considered.

Its cleary that creating another agent similar to DSH is feasible, but I personally prefer to first use it to reimplement the editor I mentioned earlier and see how it running.