pmeunier (u/pmeunier)

pmeunier commented on Memory-safe, clean implementation of classic Posix "BC" calculator github.com/rustcoreutils/... · Posted by u/jgarzik

uecker · 2 years ago

I am still waiting for Rust people to do something new and innovative. I acknowledge that Rust itself is innovative, don't get me wrong, But where are the true proof-of-concept projects such as the Linux kernel, qemu, git, postgresql, vim, etc. of the Rust world? Rewriting code is a waste of time of time, fragments the eco system, and introduces new bugs. And with a new focus on memory safety and analysis tools and sanitizers evolving, a lot of C code will be made memory safe in the future without needing a rewrite in Rust.

pmeunier · 2 years ago

Many Rust projects have done cool new stuff. Alacritty is possibly the greatest terminal emulator on the market today. I'm not into cryptocurrencies, but Parity and ZCash are doing cool stuff in that space thanks to Rust.

I'm also the author of Pijul, a much simpler and more scalable (yes, both! why choose?) version control system, and of Sanakirja, an on-disk transactional allocator to write persistent datastructures (like B trees, ropes, radix trees, HNSW…).

pmeunier commented on Version Control Beyond Git soundbarrier.io/posts/git... · Posted by u/oneofthose

oneofthose · 2 years ago

Is there a design doc one could study? At a high level I understand how the fact that patches are commutative is elegant, but it seems to me there are performance impacts when, to get to a repository state, we have to apply many patches. Would love to read how pijul thinks about that.

pmeunier · 2 years ago

This is indeed one of the issues of Pijul, but patch application is extremely fast, which makes it easy in the vast majority of cases (we don't apply patches to files directly, but to an on-purpose on-disk datastructure).

We also have a tag features, allowing you to pinpoint versions and go back instantly, and we have plans to make that feature even lighter on disk space.

pmeunier commented on Grace Version Control System github.com/ScottArbeit/Gr... · Posted by u/davedx

IshKebab · 2 years ago

> There have been lots of projects over the last 10+ years that have been riffs on "It's Git, but <better in this way>", but none of them have really caught on beyond a small, admittedly passionate group.

I don't think so. The only ones I know of are Pijul and Jujitsu which you mentioned. They're both quite new.

> you're already doing centralized version control; you're just doing it with a confusing distributed version control UX

Sort of... But actually, as soon as you go offline it's distributed.

Anyway I think more alternatives is always better and lots of the issues you listed in the readme definitely need solving, so good luck!

pmeunier · 2 years ago

> The only ones I know of are Pijul and Jujitsu which you mentioned. They're both quite new.

There are other Git frontends like Jujutsu: Gitless, StackedGit, GitButler, Sapling…

Even the idea of "SVN is the next Git" (which is the thing here) isn't quite new, PlasticSCM did it already.

Nothing like Pijul though, defining the actual problem carefully and rigorously, then actually solving it.

> Sort of... But actually, as soon as you go offline it's distributed.

Even online is distributed: Google Docs needs stuff from distributed computing such as OTs and CRDTs.

pmeunier commented on GNU Stow needs a co-maintainer savannah.gnu.org/bugs/ind... · Posted by u/nequo

lillecarl · 2 years ago

This is where a VCS like Pijul or Darcs would shine, since patches commute across "branches" without a new hash.

pmeunier · 2 years ago

One of the motivations behind Pijul was to manage custom versions of Nixpkgs while still benefiting from upstream commits. One issue that's hard with Git is that when you also want to contribute multiple changes back, you have:

1. A branch pointing to the latest nixpkgs head.

2. A branch with commit A (let's say commit A introduces a new package to nixpkgs).

3. A branch with commit B (changing some config file).

4. A branch currently at in use for your own machines, with branches 2 and 3 rebased on top of branch 1.

Every time you do anything, you'll have to remember the flow for getting the commits fetched/rebased. Which is fine if you have a DevOps team doing exactly that, but isn't too cool if you are anything other than a large company.

In Pijul, you would have a single channel (branch sort-of equivalent) and two patches (A and B) instead, which you can push independently from each other at any time if you want to contribute them back.

Darcs does the same but wouldn't scale to Nixpkgs-sized repos.

pmeunier commented on GNU Stow needs a co-maintainer savannah.gnu.org/bugs/ind... · Posted by u/nequo

lillecarl · 2 years ago

It's not intended as a dotfile manager replacement, but a Git replacement.

As long as the patches don't conflict its fine and dandy, if there's a collision you record a resolution that fixes the conflict

pmeunier · 2 years ago

Also, the conflict resolution is just another patch (Pijul patches aren't just regular diffs, they have a lot more information), so should you decide to merge it back upstream after all, you can also cherry-pick the conflict resolution along with the conflicting patch, and also without changing the hash.

pmeunier commented on A History of Source Control Systems: SCCS and RCS experimentalworks.net/pos... · Posted by u/todsacerdoti

HexDecOctBin · 2 years ago

> Systems like SVN, Mercurial & Co all seem to mostly do the right thing for the user with minimal knowledge on the user side.

I have an another blog idea for you: what are these "right things"? I have used Mercurial a bit when I was new to programming, and back then Git and Mercurial seemed more or less the same with different command names. Today, I almost exclusively use (and hate) Git, but I find it hard to see what alternatives there would be in DVCS space, other than something lie Darcs/Pijul (perhaps my imagination has been stunted by too much exposure to Git). It will be great to have someone with the knowledge lay it out comprehensively and explicitly, so that the next generation of VCS developers will be able to build upon it.

pmeunier · 2 years ago

IMHO there are different ways to design a version control system:

1. The SCSS/Git way, aka the hacker way: look at what we can do with existing stuff, and use that to build something that can do the job. For example if you're one of the world's expert on filesystem implementations, you can actually produce a fantastic tool like Git.

2. The mathematician's way: start by a model of what collaboration is, and expand from there. If your model is simple enough, you may have to use complex algorithms, but there is a hope that the UI will match the initial intuition even for non-technical users. Darcs did this, using the model that work produces diffs, and conflicts are when diffs can't be reordered. Unfortunately this is slow and not too scalable. Pijul does almost the same, but doesn't restrict itself to just functions, using also points in the computation, which makes it much faster (but way harder to implement and a bit less flexible, no free lunch).

3. The Hooli way: take an arbitrary existing VCS, say Git. Get one of your company's user interviewer, and try to please interviewees by tweaking the command names and arguments.

The tradeoff between 1 and 2 is that 1 is much more likely to produce a new usable and scalable system fast, but may result in leaky abstractions, bad merges and hacks everywhere, while 2 may have robust abstractions if the project goes to completion, but that may take years. OTOH, method 3 is the fastest and safest method, but may not produce anything new.

So, I am the main author of Pijul, and I also don't quite see how to do much better (I'm definitely working on improvements, but not technically radical). But the causal relationship isn't the one you may be thinking: it is because I thought this was the ultimate thing we could have that I started the project, not the other way around.

pmeunier commented on Twenty years is nothing deprogrammaticaipsum.com/... · Posted by u/ingve

zellyn · 2 years ago

I'm fascinated by this. I like both Rust and Zig, but I would have guessed that for the kind of complex data structure manipulation required for CRDTs and other clever algorithms Pijul employs, the degree reliable correctness Rust gives you would win out. Are you doing something (like entity-component models?) that disables much of Rust's smarts? Or is it just that much more pleasant to program in Zig?

pmeunier · 2 years ago

I've done very little Zig, so this may not be very informed. Indeed we don't use Rust intrinsically that much. With associated type constructors, Rust would be the best language (I know of) to write Pijul in. Without it, most of the polymorphism uses macros anyway. Zig or Rust would make little difference for Sanakirja I believe, and this is where the entire CRDT thing is done.

pmeunier commented on Twenty years is nothing deprogrammaticaipsum.com/... · Posted by u/ingve

zellyn · 2 years ago

I think the algorithms and data structures in Pijul have been carefully designed to be fast over a decade, and one of the original points of departure was making high-level decisions to facilitate performance. I know performance optimization in a lazy language is a special art, but I don't think it's Haskell vs Rust that makes Pijul fast. I'm sure the author can weigh in here.

pmeunier · 2 years ago

Yes indeed, we would not have started Pijul without the hope that at least theoretically, patch-based designs could be faster than snapshots. "Patch-based is slow" without any other argument is not a very informed claim, Pijul is actually faster than Git in some cases (in fact Pijul is faster where it matters most IMHO: large files and/or large repos, conflicts and blames). Not because we're better at tweaking C code (we're definitely not!), but because we designed our datastructures like theorists, and only then looked at how (and whether!) to implement things. One advantage we had over Linus is that we had no time pressure: we could well use Darcs, Git, or Mercurial to write Pijul initially (we used Darcs, actually), and it didn't matter much if we failed.

It took a little bit of work to get that down to actual fast code, for example I had to write my own key-value store, which wasn't a particularly pleasant experience, and I don't think any existing programming language could have helped, it would have required a full linear logic type system. But at least now that thing (Sanakirja) exists, is more generic, and modular than any storage library I know (I've used it to implement ropes, r trees, radix trees…), and its key-value store is faster than the fastest C equivalent (LMDB).

Could we do the same in Haskell or OCaml? As much as I like these two languages, I don't think I could have written Sanakirja in a garbage-collected language, mostly because Sanakirja is generic in its underlying storage layer: it could be mmap, a compressed file, an entire block device in Unix, an io_uring buffer ring, or something else. And the notion of ownership of the objects in the dictionary is absolutely crucial: Sanakirja allows you to fork a key-value store efficiently, so one question is, what should happen when your code drops a reference to an object from the kv store? what if you're deleting the last fork of a table containing that object? are these two the same thing? Having to explain these to a GC would have been hard I think.

I wouldn't have done it in C/C++ either, because it would have taken forever to debug (it already did take a long time), and even C++-style polymorphism (templates) isn't enough for the use of Sanakirja we have in Pijul.

remember the "poop" paper about mmap for databases, right? Well, guess what: having a generic key-value store implementation allowed me to benchmark their claims, and actually compare congestion, throughput, speed between mmap and io_uring. Conclusion: mmap rocks, actually.

pmeunier commented on Twenty years is nothing deprogrammaticaipsum.com/... · Posted by u/ingve

zubairshaik · 2 years ago

I am personally surprised that TFA didn't mention either jj or Sapling [0] given its emphasis on how both Git and svn were both made to be backwards compatible!

[0] https://github.com/facebook/sapling

pmeunier · 2 years ago

Not the same category of tools: Pijul and Fossil have radically different designs, whereas jj is a Git frontend, and Sapling a Mercurial fork.

pmeunier commented on Twenty years is nothing deprogrammaticaipsum.com/... · Posted by u/ingve

Lacusch · 2 years ago

As somebody who's interested in both languages and follow zog development relatively closely I'm interested in these many reasons. Can you give a few example of zig features or other reasons that would be useful for Pijul over Rust?

pmeunier · 2 years ago

It's mostly about Rust adding lots of features I am not interested in, and not adding the ones I need for the project. Sanakirja was hard to write in Rust, not a single concept of the language matched what I needed, in the end I had to write tons of macros, and the API is hard to use. Zig would have probably made it more natural from the beginning.

There are other things related to the community/zealots/Mozilla/Rust foundation, but I'm not sure this is the proper place.

Edit: Git zealots are worse than Rust zealots, I attribute this to Git being "harder to learn" (i.e. never really does what people think it does) than Rust.