xeubie

There is an alternative to auto-resolution or fixing low-level git merge conflicts. In my git forge Haxy, I am detecting conflicts in local-first metadata and allowing you to fix them in the UI. This is possible because I am not doing a line-based merge; the issues are stored as a data structure, so I can see what specific parts are in conflict. This allows a much nicer form of conflict resolution than conflict markers in a text file. I demoed this here: https://www.youtube.com/watch?v=kkGUARj5Wdw and here's the project: https://github.com/xit-vcs/haxy

Yeah you should try it. I place a very big value on simplicity and code size but the combo you describe might have benefits.

I used this data structure in my immutable database (see profile) but eventually switched to a B-tree because I believe RRB trees are inherently flawed. If you do a large number of slices and concats, it is possible for the tree to contain so many gaps it that the tree grows so deep it can't be modified anymore. At first I thought it was a bug in my own implementation but I eventually found the same bug in rrb-vector, the clojure implementation (see CRRBV-14). In fact, the maintainer of that library reached the same conclusion I did and switched to B-trees: https://github.com/jafingerhut/core.btree-vector

Still, I have huge respect for Phil Bagwell and I make heavy use of his hash array mapped trie. But this issue with RRB trees makes it impossible for me to use them, especially for an on-disk data structure whose long lifespan makes it way more likely that the problem will eventually happen.

Blue badges were for government employees (like I was), and green badges were for private contractors. And yes they have a lot of math and physics guys; my own physics lecturer was in my orientation class, actually. He was there for quantum computing, which reinforces my point. The government can be good at pioneering unproven / uncommercialized technologies, but in general they are like a blunt weapon; the profit motive and lack of bureaucracy eventually makes the private sector far better for improving the technology later. In the case of LLMs, they didn't even originate in government, and I don't think there's any chance they are being developed there at a more advanced level.

I can't say what they're doing now because I worked for the NSA 15 years ago but the view of them as an omnipotent power is a product of Hollywood. The government is good at throwing an ungodly amount of resources at something to get a result through sheer attrition, and so they are often the source of original development of technologies. The private sector has always been much better at building a technology to greater sophistication and efficiency. There may be blue badgers in Fort Meade trying to train models but there is no chance they are competitive with the frontier AI companies. It's like saying the government has an amazing home-grown fighter aircraft that is beyond what Lockheed has ever made...they delegate that stuff to private companies for a reason.

Yes the article I linked mentioned d/with (speculative writes), and you are right that it is useful for testing -- but not much else, since it is purely in-memory. If you want to call that in-memory branching that's fine, I'll concede that.

My database supports persisted branching, but not just at the database level. You can "branch" (i.e., make a fast clone) data at any level, such as data for a specific user. Many production uses for this, not just testing, yet almost no database supports this. It uses the same HAMT algorithm that Clojure uses.

If each "branch" is read only, it's not a branch at all. The entire idea of branching implies that you can make changes on one branch, then switch to another branch and make changes to it. They start from the same point and grow in different directions, as the metaphor of branches on a tree depicts.

Surprisingly, neither Datomic nor XTDB support branching. See: https://blog.danieljanus.pl/datomic-forking-the-past/

I actually built my own immutable database which does support branching (see profile), so it seems like a huge miss that these ones don't. It's pretty much the main reason I would want an immutable database.

I really like it. API-first git repos without the limitations of a git service like github that are built primarily for humans. Looks like a competitor to code.storage by pierre.

Zig is a great choice. I spent the last three years working on my own git implementation in Zig (see my profile) and it's really the perfect language for this. It gives precise low level control and heavily emphasizes eliminating dependencies (like libc) which makes it perfect for web assembly.

What a banger of a release. The new `Io` interface was a huge breaking change for my project, but I made the transition. Zig seems to be pulling the same trick it pulled with allocators: just make it an explicit value that you pass around. Explicit allocators felt obviously right in retrospect, and so far this feels obviously right too.

Clojure's immutable HAMTs are still a superpower nearly 20 years later. They've been copied in pretty much every language as a library (I did so myself in Zig) but what really makes it work well in Clojure is the fact that they're built into the language, so the entire ecosystem is built around them. Libraries that were made independently usually fit together like a glove because they are all just maps/vectors in -> maps/vectors out.

True, git poorly imitated monotone's performance problems.

I think astronomers could measure the age of the universe in nano-Valhallas. Every year, it feels 50% closer to completion...

In all seriousness I'm happy with what Mr. Goetz and the team have done. Sealed interfaces (java 17) + exhaustive switch statements (java 21) means we now have union types in java! And instead of jumping on the async/await bandwagon we now have a more general solution that doesn't lead to API duplication (virtual threads). But Valhalla has been a veeery long time coming.