SaaSHub helps you find the best software and product alternatives Learn more →
Co-dfns Alternatives
Similar projects and alternatives to Co-dfns
-
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
-
-
Nim
Nim is a statically typed compiled systems programming language. It combines successful concepts from mature languages like Python, Ada and Modula. Its design focuses on efficiency, expressiveness, and elegance (in that order of priority).
-
-
-
-
-
-
tigerbeetle
Discontinued A distributed financial accounting database designed for mission critical safety and performance. [Moved to: https://github.com/tigerbeetledb/tigerbeetle] (by coilhq)
-
-
cloc
cloc counts blank lines, comment lines, and physical lines of source code in many programming languages.
-
-
-
-
-
medley
The main repo for the Medley Interlisp project. Wiki, Issues are here. Other repositories include maiko (the VM implementation) and Interlisp.github.io (web site sources) (by Interlisp)
-
-
-
-
NOTE:
The number of mentions on this list indicates mentions on common posts plus user suggested alternatives.
Hence, a higher number means a better Co-dfns alternative or higher similarity.
Co-dfns discussion
Co-dfns reviews and mentions
Posts with mentions or reviews of Co-dfns.
We have used some of these posts to build our list of alternatives
and similar projects. The last one was on 2026-05-24.
-
Mastering Dyalog APL
> At some point you get what APL is all about, and you can move on with life without too many regrets.
Unfortunately, this seems to be a common experience. A lot of smart people only engage with APL via toy puzzles, like you did, and bounce off because that gives no insight about how to use the language in real life. IME, to really start getting APL you need to write and rewrite a full application 20 times.
It helps to read code from the masters, too [0, 1, 2, 3, 4]. These all approach architecture in different ways: pedagogical FP style, OOP heavy, data-oriented design, event-driven state-machine, or a mix of the above.
[0]:https://dfns.dyalog.com/
[1]:https://github.com/Co-dfns/MicroUI-APL
[2]:https://github.com/Dyalog/ewc
[3]:https://github.com/Co-dfns/Co-dfns
[4]:https://github.com/Dyalog/Jarvis/blob/master/Source/Jarvis.d...
> As you can see, the famous prime generator is not even the Eratostenes' sieve, but a simple N^2 divisor counting computation.
Well, that's because you wrote a divisor function, not a seive. Arguably, the ease of typing an outer product (i.e ∘.|⍨⍳N) can tempt us into writing quadratic algorithms unnecessarily, but this is just an experience issue, IMO.
If we want a seive, we can just write a one directly:
p⊣{0⊣p~←1↓⍺×1+⍳⌊N÷⍺}⌿⌽⍬⍪p←1↓1+⍳N -
APL Interpreter – An implementation of APL, written in Haskell
> Array programming is similar to functional programming – the primary way to control execution involves composition of functions – but APL tends to encourage the reliance on global properties and sweeping operations rather than low-level recursion4.
This AoC solution is, indeed, quite the functionista! Better yet, it leans heavily into point-free expressions. The style is pretty popular amongst APL language enthusiasts and puzzlers.
That said, you actually see quite different APL styles in the wild:
- Pointed declarative style, also a popular with functional programmers (e.g. anything like this[0])
- Imperative, structured programming, very common in legacy production systems (e.g. this[1] OpenAI API interface)
- Object-oriented, also common in somewhat newer production environments (e.g. the HTTP interface[2])
- Data-parallel style (e.g. Co-dfns[3])
Heck, APL even has lexical and dynamic scope coexisting together. IMHO, it's truly underrated as a language innovator.
[0]:https://dfns.dyalog.com/c_match.htm
[1]:https://github.com/Dyalog/OpenAI/blob/main/source/OpenAI.apl...
[2]:https://github.com/Dyalog/HttpCommand/blob/master/source/Htt...
[3]:https://github.com/Co-dfns/Co-dfns/blob/master/cmp/PS.apl
- Co-dfns: High-performance, reliable, and parallel APL
-
Notation as a Tool of Thought (1979)
These are all cribbed from the Co-dfns[0] compiler and related musings. The key insight here is that what would be API functions or DSL words are just APL expressions on carefully designed data. To pull this off, all the design work that would go into creating an API goes into designing said data to make such expressions possible.
In fact, when you see the above in real code, they are all variations on the theme, tailored to the specific needs of the immediate sub-problem. As library functions, such needs tend to accrete functions and function parameters into our library methods over time, making them harder to understand and visually noisier in the code.
To my eyes, the crux is that our formal language is _discovered_ not handed down from God. As I'm sure you're excruciatingly aware, that discovery process means we benefit from the flexibility to quickly iterate on the _entire architecture_ of our code, otherwise we end up with baked-in obsolete assumptions and the corresponding piles of workarounds.
In my experience, the Iversonian languages provide architectural expressability and iterability _par excellence_.
[0]:https://github.com/Co-dfns/Co-dfns/tree/master
-
System Design of a Cellular APL Computer
My YAML loader[0] is where I first broke through the wall. It's still languishing in a relatively proof-of-concept state but does exhibit the basic design principles.
There's also a Metamath verifier that does parallel proof verification on the GPU. It's unpublished right now because the whole thing is just a handful of handwritten code in my notebook at the moment. Hoping to get this out this month, actually.
A DOOM port is bouncing around in my notes as well as a way to explore asynchronous APL.
I'm also helping Aaron Hsu in his APL compiler[1] for stuff adjacent to my professional work, which I can't comment on much, unfortunately.
Et hoc genus omne
[0]:https://github.com/xelxebar/dayaml
[1]:https://github.com/Co-dfns/Co-dfns
-
Ask HN: Should I learn COBOL at 14yo in 2025?
What a perceptive question!
Learning boring technology and invisible infrastructure definitely can pay dividends. I don't think it's worth learning in isolation, but if you also engage in the relevant communities (think mailing lists, in-person conferences, company events, etc.) then the effort pays good dividends IME.
I'm a bit biased, but I recommend looking at APL[0]. For one, it has a legacy almost as old as COBOL, with large pieces of European infrastructure running on the language. At the same time, it's cutting edge in both performance and the software architecture principles it encourages. Heck, APL even runs on GPUs these days [1], boasting a solid route for learning modern GPU programming as well.
Also, the company behind the leading APL implementation these days, Dyalog[0], has some of the friendliest outreach around, and their yearly conferences are some of my favorites to attend.
Disclaimer: I am kind of in love with APL as a greenfield development language. Feel free to email me personally if you have any questions. Address is in my HN profile.
[0]:https://dyalog.com/
[1]:https://github.com/Co-dfns/Co-dfns
-
Co-Dfns v5.7.0
Huh. This is the commit that introduces the register model: https://github.com/Co-dfns/Co-dfns/commit/f89919144f22441f21...
In the compiler, it's working with dense adjacency matrix representations, so this will be at best O(n^2) in whatever the relevant sort of node is (expressions? functions?). "at present is not optimized" seems a bit of an understatement here: I've never heard of these sorts of graph algorithms being possible with good asymptotics in an array style. In practice, I think any value of Co-dfns would be more in the fact that it emits GPU code than that it does it quickly, but this calls into question the value of writing it in APL, I would say (for what it's worth, I believe Co-dfns is still not able to compile itself).
The phrase "allocate all intermediate arrays" seems fairly confusing: what's actually being allocated must be space for the pointers to these arrays and other metadata, not the data of the array itself. As the data is variable-size, it can't be fully planned out at compile time, and I'm fairly sure the register allocation is done when there's not enough shape or type information to even make an attempt at data allocation. This change can only improve constant overhead for primitive calls, and won't be relevant to computations where most of the work is on large arrays. I think it's helpful for Co-dfns in a practical sense, but not too exciting as it only helps with bad cases: if this is important for a user then they'd probably end up with better performance by switching to a statically-typed language when it comes time to optimize.
Constant lifting within the compiler is pretty cool, I'll have to look into that.
-
Tacit Programming
And if anyone wants an absolute masterclass in tacit programming, have a look at Aaron's Co-dfns compiler. The README has extensive reference material. https://github.com/Co-dfns/Co-dfns/
- YAML Parser for Dyalog APL
-
HVM updates: simplifications, finally runs on GPUs, 80x speedup on RTX 4090
This always seemed like a very interesting project; we need to get to the point where, if things can run in parallel, they must run in parallel to make software more efficient on modern cpu/gpu.
It won't attract funds, I guess, but it would be far more trivial to make this work with an APL or a Lisp/Scheme. There already is great research for APL[0] and looking at the syntax of HVM-core it seems it is rather easy to knock up a CL DSL. If only there were more hours in a day.
[0] https://github.com/Co-dfns/Co-dfns
-
A note from our sponsor - SaaSHub
www.saashub.com | 16 Aug 2026
Stats
Basic Co-dfns repo stats
27
796
9.1
2 days ago
Co-dfns/Co-dfns is an open source project licensed under GNU Affero General Public License v3.0 which is an OSI approved license.
The primary programming language of Co-dfns is APL.
Sponsored
SaaSHub - Software Alternatives and Reviews
SaaSHub helps you find the best software and product alternatives
www.saashub.com