graphtage VS GJSON

I'm not familiar with Pijul, and haven't finished watching this presentation, but IME the problems with modern version control tools is that they still rely on comparing lines of plain text, something we've been doing for decades. Merge conflicts are an issue because our tools are agnostic about the actual content they're tracking.

Instead, the tools should be smarter and work on the level of functions, classes, packages, sentences, paragraphs, or whatever primitive makes sense for the project and file that is being changed. In the case of code bases, they need to be aware of the language and the AST of the program. For binary files, they need to be aware of the file format and its binary structure. This would allow them to show actually meaningful diffs, and minimize the chances of conflicts, and of producing a corrupt file after an automatic merge.

There has been some research in this area, and there are a few semantic diffing tools[1,2,3], but I'm not aware of this being widely used in any VCS.

Nowadays, with all the machine learning advances, the ideal VCS should also use ML to understand the change at a deeper level, and maybe even suggest improvements. If AI can write code for me, it could surely understand what I'm trying to do, and help me so that version control is entirely hands-free, instead of having to fight with it, and be constantly aware of it, as I have to do now.

I just finished watching the presentation, and Pijul seems like an iterative improvement over Git. Nothing jumped out at me like a killer feature that would make me want to give it a try. It might be because the author focuses too much on technical details, instead of taking a step back and rethinking what a modern VCS tool should look like today.

[1]: https://semanticdiff.com/

[2]: https://github.com/trailofbits/graphtage

[3]: https://github.com/GumTreeDiff/gumtree

Vielleicht mal https://github.com/trailofbits/graphtage abchecken

Graphtage: A semantic diff utility for JSON, HTML, YAML, CSV, etc\ (42 comments)

Someone made a benchmark of serialization libraries in go [1], and I was surprised to see gobs is one of the slowest ones, specially for decoding. I suspect part of the reason is that the API doesn't not allow reusing decoders [2]. From my explorations it seems like both JSON [3], message-pack [4] and CBOR [5] are better alternatives.

By the way, in Go there are a like a million JSON encoders because a lot of things in the std library are not really coded for maximum performance but more for easy of usage, it seems. Perhaps this is the right balance for certain things (ex: the http library, see [6]).

There are also a bunch of libraries that allow you to modify a JSON file "in place", without having to fully deserialize into structs (ex: GJSON/SJSON [7] [8]). This sounds very convenient and more efficient that fully de/serializing if we just need to change the data a little.

--

1: https://github.com/alecthomas/go_serialization_benchmarks

2: https://github.com/golang/go/issues/29766#issuecomment-45492...

--

3: https://github.com/goccy/go-json

4: https://github.com/vmihailenco/msgpack

5: https://github.com/fxamacker/cbor

--

6: https://github.com/valyala/fasthttp#faq

--

7: https://github.com/tidwall/gjson

8: https://github.com/tidwall/sjson

```

I don't think there is a way to sort an array, though. However, there is an option to have keys sorted. Personally, I don't think there is much annoyance in that. One could just pipe `jj` output to `sort | uniq -c`.

[0]: https://github.com/tidwall/gjson/blob/master/SYNTAX.md

I’m using GJSON, so far so good!

If the fields you need are just a small subset of the whole json, maybe https://github.com/tidwall/gjson might be of use to read only those (using jsonpath) without needing to create complete corresponding structs.

Thank you for the reminder, it's never too much of it :) Didn't say it, but the code was pprof-iled many times and i can really say it's well optimized. I use own libraries with on-the-fly equations (sums, avgs, emas, stds, ...) wherever possible and also made custom json parser as json messages are in fixed format, so the parser is about 10x faster than gjson. I optimized it to the point that I avoided using maps, and rather iterate via slice where ever possible.

You are right, for learning purposes this fit my needs, but I can imagine an approach similar to this repo: https://github.com/tidwall/gjson

https://github.com/tidwall/gjson is a relatively sensible library if this is something you need to deal with and the structure is actually unknowable.