HN user
CRDTs, deep hypertext, distributed systems.
http://replicated.live
@gritzko on Twitter, Telegram, Bsky
https://bsky.app/profile/gritzko.bsky.social
eddsa263/66a66a20ab3cb789d761c192ddcbb02f4567e382
JavaScript did this for the Web back in the day. I work on a malleable git-compatible SCM right now. First I put all the performance-critical parts into a native lib, then happily built my own git(hub) in JavaScript. Tastes differ, someone else may build it completely differently. I believe this is the right architecture for the LLM age.
LLM-is-a-compiler is indeed a simplistic approach. I wrote a rebuttal to the yesterday's Cursor post, may reuse it here https://replicated.live/blog/follow-up
The idea that a 835-page spec "just exists" and we run an LLM to implement it is completely flawed. Specs do not appear out of nowhere, they co-evolve with the code. If you have the code, why do you want to generate it again?
Good software is made as a product of numerous feedback loops and LLMs let you operate those loops faster. They do not supplement the entire process though.
In the end, a good product is a barrel of distilled feedback.
I am afraid the folks are still busy playing with familiar toys. "Let's extract more code out of LLM's inner layers!" SQLite we already have. That's where their "spec" came from.
The interesting frontier is elsewhere: how to fit it into the pipeline to build new useful things. I felt motivated enough to write a follow-up/reply post http://replicated.live/blog/follow-up
Back in my early career days, CPUs were clocked at 1GHz. That was 20-25 years ago.
Making a high-throughput revision control system is doable, there have been experiments here on HN with git-in-postgres etc. The question is, what is the actual bottleneck here?
I made a VCS for LLM assisted work, bootstrapping it on its own code as it was developed. In fact, if it did not really work, it would not even exist! In my experience, keeping track of things and evaluating them was the bottleneck and I focused on that https://replicated.live/blog/worktree Effectively, the question is "how to leverage human evaluation and feedback".
The Cursor people concluded their last post with "taste, judgement, and direction came from humans". Sounded surprisingly sane after "don't compile it, commit it faster" some paragraphs earlier.
2*128 is the UUID namespace, which is astronomical. That is like 21 letters. Making one sentence of Shakespeare by random search is strictly 0% chance. SHA256 is ~43 letters then. "LLM broke all of cryptography and creates random data to fit a hash" -- are we there yet? Random search does not work at this scale. In all their cases, they played with pre-existing well-studied software, so they had an embedded fitness function. An extremely detailed one.
Monkeys have been reading Shakespeare all their lives (training). Effectively, this is LLM uncompression. Hence, "in Rust, from nothing but its documentation" -- not entirely true.
might be relevant: https://martin.kleppmann.com/2025/12/08/ai-formal-verificati...
Thanks, fixed. The runtime[1] and the scripts[2] are the practical ones. I am separating the old repo[3] into submodules since submodule recursion became smooth in Beagle.
[1] https://github.com/gritzko/jab
I am the author. I am trying to limit one post to one page. Most people here are reading reasoning all day, I am afraid. Might get tired.
I also aspire to make one post a day. To be continued.
I have the last native Fujitsu laptop that is worthy of mention. I am a big fan. Fun story: about 5 years ago they decided to resume their laptop production, and the only practical way was to enroll old retired Japanese workers. I guess, the youth do not have the skill or/and do not want to bother. They made some batches, then I believe it ended.
Panasonic still makes laptops, enterprise use only, very expensive.
How is that relevant? Well, directly.
CommonMark spec[1] is laaarge and not formal (no grammar). StrictMark has block-level[2] and inline[3] grammars, 100+ and 200+ lines of Ragel code respectively. May parse with regexes too, and results will be identical.
[1] https://spec.commonmark.org/0.31.2/
[2] https://github.com/gritzko/beagle/blob/main/dog/tok/MKDTB.c....
[3] https://github.com/gritzko/beagle/blob/main/dog/tok/MKDT.c.r...
About five years ago I faced the fact no two Markdown implementations are fully compatible. I made StrictMark[1], which is a backwards-compatible Markdown dialect with a formal grammar (I use Ragel for parser generation btw). Takes 5-10 min with LLMs to make any implementation, cause formal grammar is unchanged. I use it, no one else does, which is not an issue cause it is backwards-compatible. GitHub renders it fine[3].
Solved my problems. Caused no inconvenience.
[1] https://web.archive.org/web/20210130000533/http://doc.replic...
[2] https://github.com/gritzko/beagle-journal/blob/main/wiki/Str...
[3] https://github.com/gritzko/beagle-journal/blob/main/wiki/Str...
May look mundane, but there is a funny trend. Git folks rediscover database internals from the first principles.
2010. I remember those times. I was doing these things for science in 2008. Performance-wise, PEX was much faster than DHT. At least, in my setting.
This year, I was giving it as an assignment to students. Does not take much time with LLMs.
The question is who maintains it. I think, LLM is the only practical option. In my agent rules, I tell it to maintain INDEX.md on each level. That takes 1 line of instruction and starting with an example file. Then, it self-maintains.
In the Beagle SCM, I am doing my best to simplify that flow, but that is only doable because Beagle has multi-project repos. Still, there are some difficulties with submodule recursion. In the git model, difficult to imagine this working smoothly.
Every Beagle command:
gritzko@spot ~/beagle $ be get
19:07 get ?#0ac49e6a
16:58 post ?0ac49e6a#POST-018 put:/post: banner on stdout
19:07 new beagle/test/be-post-put-banner.sh
19:07 upd dog/INDEX.md
...more stuff...
19:07 del test/post/01-bare-msg/01.put.err.txt
19:07 del test/post/01-bare-msg/02.post.err.txt
19:07 get abc?4222dfabFive is enough. Beagle uses five HTTP verbs: GET, POST, PUT, DELETE, PATCH. And it is syntax-aware.
Git vocabulary is workflow-based, i.e. "what we usually do". Unfortunately, the language grew complex and easy to mess up. The problem of NxN interactions: what happens if we do C between A and B?
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).
The most human-friendly thing is probably natural language. If so, it is LLMs who should have an intuition about the REST interface and its URI syntax. I personally would prefer to glance at it, but not to type it repeatedly. Especially, hashes.
So, the actual question is how to make this machinery un-screw-up-able. (Author)
https://github.com/gritzko/libabc/blob/main/Sx.h
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)
Nice experiment, but a bit expensive.
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.
I always post this https://www.rte-france.com/en/data-publications/eco2mix/powe...
I live on alpine, in fact.
That is interesting. I make LLMs write C with the general hope that a simpler language they can manage well. That is not entirely true, though. They reason about C fluently indeed. The problem is, Claude pumps lots of bad C into the codebase if left unattended for 5 min. So, I need some clean-up passes afterwards to get to some acceptable quality level (both by LLMs and my own eyes). At which point, Claude sees the problem clearly, for some mysterious reason. Also, I use a C dialect heavly influenced by Go (slices, generics, no smart tricks, virtually no malloc).
I think I did not get to that level yet where I trust Claude to create its own VMs. But one day I will.
What is the feasible way to test code against the matrix of compilers/oses?
https://en.wikipedia.org/wiki/Fundamental_theorem_of_softwar...
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.
That is the entire point, yes. Reasoning about layers of completely imaginary entities is what demotivates me about C++ and Rust. Meanwhile, hardware bits are very real (and getting more expensive recently). Having implemented slices and generics in C, now C++ feels like Vietnam flashbacks.
In this day and age, the value of C standard library is approaching zero. Is is basically an unfirm looping trajectory of CS thought left over 50 years. That amount of code can be recreated pretty quick today. So why bother. Unless it is a syscall or somehow specially treated by the compiler (memcpy etc), there is no special value in it.