So the idea here is to define actual operations that happen to the tree, formally. Those are a bit more complicated than the vanilla blob/tree/commit model, but still manageable. Six verbs is enough.

Overall, it all decomposes cleanly and uniformly. Workflow-based vocabulary becomes unnecessary (and a bit confusing) once you grasp that basic underlying model of orthogonal operations/concerns. Some parts still need work though, e.g. conveying the precise state of the tree (can't steal from git here).

So, the actual question is how to make this machinery un-screw-up-able. (Author)

Comments URL: https://news.ycombinator.com/item?id=48524534

Points: 3

# Comments: 0

https://github.com/gritzko/libabc/blob/main/S.md

ABC uses s[2] for slices, g[3] for gauges, b[4] for (ring) buffers. Also containers on top of those (heaps, hash sets, etc etc)

Comments URL: https://news.ycombinator.com/item?id=48494135

Points: 28

# Comments: 8

I work on Beagle, a git-compatible SCM [1]. I use ABC, Abstractionless C [2] dialect with slices, optional range checking, etc. So far, memory safety was the least of my concerns, frankly. Most of the thorny issues would be equally thorny in Rust (e.g. right now: reflog zeroed when VM ran out of disk space; must be some state machine issue or an OS level glitch). Also, forking off a C process (no runtime) is cheap enough that you actually want to do that more.

But, those are all technicalities. The key issue I see with the approach: the data structures and algos of git have been fanatically fine tuned for that particular application with those particular usage patterns. By very sophisticated low-level C programmers. So, quite likely, any other app/lib working with that store will always be a suboptimal fit. I would recommend read-only access only, esp for LLM code.

Meanwhile, git's underlying data model (blobs/trees/commits) is very simple and very much internet-standard level. Decoupling at that interface is so much easier with so much less issues looming.

May look differently from your vantage point though.

[1]: https://github.com/gritzko/beagle

[2]: https://replicated.wiki/blog/abc

My point, more or less. Of course, a heap is different from append-only array, on higher level. On lower level, these are bit strings. Which is handy, if you can send it over the network with exactly the same function, for example.

Comments URL: https://news.ycombinator.com/item?id=48265422

Points: 1

# Comments: 0

https://replicated.wiki/blog/abc

Comments URL: https://news.ycombinator.com/item?id=48258182

Points: 7

# Comments: 3

https://github.com/gritzko/libabc

In this day and age, the top problem is Claude bringing lots and lots of bad C into the code base. Takes a weekend to clear the week's mess.

https://github.com/gritzko/beagle

In a cleared codebase though all the usual C memory bugs are virtually non-existant. When did I see core dump last time? I do not remember. Thus feel no urge to use Zig or Rust.

- unless you are trying to sink it in mercury. then it floats

- unless it is an uranium bar

- go sink uranium bars in mercury yourself

On recent Intel and 64-bit ARM processors, data alignment does not make processing a lot faster. It is a micro-optimization. Data alignment for speed is a myth. // https://lemire.me/blog/2012/05/31/data-alignment-for-speed-m...

(while in the olden days, a program may crash on unaligned access, esp on RISC)