tigerbeetle
Co-dfns
Our great sponsors
tigerbeetle | Co-dfns | |
---|---|---|
44 | 19 | |
6,534 | 639 | |
45.5% | 2.2% | |
9.9 | 9.6 | |
6 days ago | about 16 hours ago | |
Zig | APL | |
Apache License 2.0 | GNU Affero General Public License v3.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
tigerbeetle
- Factor is faster than Zig
-
The Raft Consensus Algorithm
Maelstrom [1], a workbench for learning distributed systems from the creator of Jepsen, includes a simple (model-checked) implementation of Raft and an excellent tutorial on implementing it.
Raft is a simple algorithm, but as others have noted, the original paper includes many correctness details often brushed over in toy implementations. Furthermore, the fallibility of real-world hardware (handling memory/disk corruption and grey failures), the requirements of real-world systems with tight latency SLAs, and a need for things like flexible quorum/dynamic cluster membership make implementing it for production a long and daunting task. The commit history of etcd and hashicorp/raft, likely the two most battle-tested open source implementations of raft that still surface correctness bugs on the regular tell you all you need to know.
The tigerbeetle team talks in detail about the real-world aspects of distributed systems on imperfect hardware/non-abstracted system models, and why they chose viewstamp replication, which predates Paxos but looks more like Raft.
[1]: https://github.com/jepsen-io/maelstrom/
[2]: https://github.com/tigerbeetle/tigerbeetle/blob/main/docs/DE...
- Fastest Branchless Binary Search
-
CWE Top Most Dangerous Software Weaknesses
> There is no reason to use a memory unsafe language anymore, except legacy codebases, and that is also slowly but surely diminishing. I'm still yet to hear this amazingly compelling reason that you just need memory unsafe languages. In terms of cost/benefits analysis, memory unsafety is literally all costs.
Tell that to the authors of new memory unsafe languages (like Zig) and creators of new project in those languages (like https://tigerbeetle.com) :(
- Problems of C, and how Zig addresses them
- File for Divorce from LLVM
-
Zap – fast back ends in Zig
Seeing this, and the use of zig for https://github.com/tigerbeetledb/tigerbeetle I wonder if zig might become a good tradeoff vs rust for servers if in long term it's more readable and maintainable and with a different approach to quality.
I would also be interested to hear the compile time, binary size and memory usage of those example apps.
Looks like the underlying facil.io library hasn't seen any commits since 2021, so that's a bit of a red flag. https://github.com/boazsegev/facil.io
-
Significant examples of Zig software (June 2023)?
About three years ago, we had a thread called "Significant examples of Zig software?". Some time has passed, and there have been fairly large Zig code bases that have surfaced since, such as TigerBeetle (cc /u/eatonphil), or adoption at places like Uber.
-
I think Zig is hard but worth it
This is basically what I've come to do in the Zig scripts I write at work.
It took a bit of getting used to when I joined but we agreed as a team to have all meaningful scripts written in Zig not bash (for one, bash doesn't work on Windows without WSL and we need to support Windows builds/testing/etc.).
It makes about as much sense as any other cross-platform scripting option once I got used to it!
Some examples:
Docs generation: https://github.com/tigerbeetledb/tigerbeetle/blob/main/src/c...
Integration testing sample code: https://github.com/tigerbeetledb/tigerbeetle/blob/main/src/c...
Running a command wrapped in a TigerBeetle server run: https://github.com/tigerbeetledb/tigerbeetle/blob/main/src/c...
Co-dfns
-
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
I don't put a lot of stock in the "write-only" accusation. I think it's mostly used by those who don't know APL because, first, it's clever, and second, they can't read the code. However, if I remember I implemented something in J 10 years ago, I will definitely dig out the code because that's the fastest way by far for me to remember how it works.
This project specifically looks to be done in a flat array style similar to Co-dfns[0]. It's not a very common way to use APL. However, I've maintained an array-based compiler [1] for several years, and don't find that reading is a particular difficulty. Debugging is significantly easier than a scalar compiler, because the computation works on arrays drawn from the entire source code, and it's easy to inspect these and figure out what doesn't match expectations. I wrote most of [2] using a more traditional compiler architecture and it's easier to write and extend but feels about the same for reading and small tweaks. See also my review [3] of the denser compiler and precursor Co-dfns.
As for being read by others, short snippets are definitely fine. Taking some from the last week or so in the APL Farm, {⍵÷⍨+/|-/¯9 ¯11+.○?2⍵2⍴0} and {(⍸⍣¯1+\⎕IO,⍺)⊂[⎕IO]⍵} seemed to be easily understood. Forum links at [4]; the APL Orchard is viewable without signup and tends to have a lot of code discussion. There are APL codebases with many programmers, but they tend to be very verbose with long names. Something like the YAML parser here with no comments and single-letter names would be hard to get into. I can recognize, say, that c⌿¨⍨←(∨⍀∧∨⍀U⊖)∘(~⊢∊LF⍪WS⍨)¨c trims leading and trailing whitespace from each string in a few seconds, but in other places there are a lot of magic numbers so I get the "what" but not the "why". Eh, as I look over it things are starting to make sense, could probably get through this in an hour or so. But a lot of APLers don't have experience with the patterns used here.
[0] https://github.com/Co-dfns/Co-dfns
[1] https://github.com/mlochbaum/BQN/blob/master/src/c.bqn
[2] https://github.com/mlochbaum/Singeli/blob/master/singeli.bqn
[3] https://mlochbaum.github.io/BQN/implementation/codfns.html
-
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.
-
APL: An Array Oriented Programming Language (2018)
There are many styles of APL, not just due to its long history, but also because APL is somewhat agnostic to architecture paradigms. You can see heavily imperative code with explicit branching all over the place, strongly functional-style with lots of small functions, even object-oriented style.
However, given the aesthetic that you express, I think you might like https://github.com/Co-dfns/Co-dfns/. This is hands-down my favorite kind of APL, in which the data flow literally follows the linear code flow.
-
Franz Inc. has moved the whole Allegro CL IDE to a browser-based user interface. Incl. all their Lisp development tools. One can check that out with their Allegro CL Express Edition.
Which is, as far as I know, unused. (Similarly the gpu compiler.)
-
What would make you try a new language?
You might be familiar with iKe (grahics), SpecialK (GLSL) and Co-dfns. Also, I am working on bastardized APL for GPU – Fluent. Fluent 1 had backend implemented through Apple Metal Performance Shaders Graph and Fluent 2 has TensorFlowJS backend for now. I care more about having auto differentiation in the lang than running on GPU and do graphics, to be honest.
-
Who is researching array languages these days?
Aaron hsu did his dissertation on this topic (compiler, thesis), at indiana university in the us.
- Researchers Develop Transistor-Free Compute-in-Memory Architecture
-
Why APL is a language worth knowing
Stories please! What did the closures do to you?
Hopefully this won't be seen as too combative, but I feel like there are a few people in the array community giving me some pretty strong conclusions that they don't really have the experience to back up (Aaron wrote[0] 17 lines of array compiler, and says the low-abstraction approach he used is the only way to develop sustainably. Cool. I wrote[1] 350 lines of array compiler following his style, and I disagree[2]). At the same time, my experience only goes so far (there's no way I would have invented the array style compiler!), and clearly you arrived at these conclusions somehow. So is there a chance you'd share the observations that led you that way?
On my end, I was actually introduced to a little object-oriented programming in J when Henry suggested using it for a simulation project. I used it, but I don't think I really got it—just a weird way to organize data. And then in college I had to learn objects-only Java. Not good. But later I worked some with Node.js, and its module system was pretty nice: no name conflicts, easy to share code! Some way into BQN development, I figured out (with some help from a Common Lisp programmer) a way to add modules with an APL-y syntax, and something magic happened. I got objects[3] too! I think I've done about as much OOP in BQN as anywhere else, and I feel like I understand it a lot better now.
So, this is my experience with Lisp-family features and APL. Fits like a glove, programming is easier and more fun. I mix and match array, functional, and object-oriented styles however I want. Did I lose coherence? When I translate my old J code it comes out shorter and cleaner and without exec (".) everywhere. But I still don't get why I should want the language I use to not support mutability rather than just default to immutability. Did I fail to understand something in J when I had the chance?
[0] https://github.com/Co-dfns/Co-dfns
[1] https://github.com/mlochbaum/BQN/blob/master/src/c.bqn
[2] https://mlochbaum.github.io/BQN/implementation/codfns.html
-
Barriers to APL Adoption
Co-dfns feels like an academic project that I won't be able to figure out how to use.
What are some alternatives?
BQN - An APL-like programming language. Self-hosted!
chibicc - A small C compiler
tigerbeetle - A distributed financial accounting database designed for mission critical safety and performance. [Moved to: https://github.com/tigerbeetledb/tigerbeetle]
ngn-apl - An APL interpreter written in JavaScript. Runs in a browser or NodeJS.
uemacs - Random version of microemacs with my private modificatons
april - The APL programming language (a subset thereof) compiling to Common Lisp.
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)
maiko - Medley Interlisp virtual machine
zig - General-purpose programming language and toolchain for maintaining robust, optimal, and reusable software.
dex-lang - Research language for array processing in the Haskell/ML family
LevelDB - LevelDB is a fast key-value storage library written at Google that provides an ordered mapping from string keys to string values.
reshade - A generic post-processing injector for games and video software.