5 ms·

"There are two interesting contenders worthy of mention: Pijul, written in Rust" Why is it that every time something is written in Rust, it needs to be mention

"There are two interesting contenders worthy of mention: Pijul, written in Rust" Why is it that every time something is written in Rust, it needs to be mentioned, just as that the language of choice would make it magically much better? Version control is just a lot of bookkeeping so I doubt possible added performance (outside some well defined algorithms) can matter much.

zellyn 3y ago
I personally find the mention of the implementation language as part of a project description to be slightly interesting/informative, or at worst benign. Unlike the inevitable comments complaining about it. Mercurial, written in Python, definitely experienced performance problems. Hilariously, the first search result I found when searching for "mercurial performance python" is https://wiki.mercurial-scm.org/OxidationPlan https://wiki.mercurial-scm.org/OxidationPlan, which discusses reimplementing parts of Mercurial in — you guessed it — Rust.
- fifilura 3y ago
  Thank you! And informative. Some days are just like that. Your synapses trigger on something because of historical reasons.
  - michaelt 3y ago
    > Your synapses trigger on something because of historical reasons. When you read a product description written by someone who hopes to draw positive attention to the product, it'll usually draw attention to its most important and distinctive features first. For example, if you look up Stripe, you'll get "Stripe | Financial Infrastructure for the Internet - Stripe powers online and in-person payment processing and financial solutions for businesses of all sizes." If you look up Uber you'll get "Get a ride in minutes. Or become a driver and earn money on your schedule." Clang? "The Clang project provides a language front-end and tooling infrastructure for languages in the C language family". Ubuntu? "Ubuntu is the modern, open source operating system on Linux for the enterprise server, desktop, cloud, and IoT." When the place you usually see the product's best feature says "written in rust" it sounds like they're damning it with faint praise. Of course, not everyone follows the 'best feature first' pattern. For example, when asked about Stripe the first thing Wikipedia tells you is that it's dual-headquartered in South San Francisco, California, United States and Dublin, Ireland.
    - pmeunier 3y ago
      Wait, nobody in the Pijul team brags about being in Rust. If Pijul were written today it would probably be in Zig, for many reasons.
      - zellyn 3y 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 3y 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.
      - Lacusch 3y 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 3y 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.
  - zellyn 3y ago
    No worries. And sorry for my unnecessarily sharp response! :-)
yard2010 3y ago
Because language is everything. There is no such thing that sets the context such as language, whether a spoken language or a computer language. You would never understand the "true" meaning or words without knowing the language.
DarkNova6 3y ago
I believe this is twofold: 1. Unless you abuse Rust horribly, it is both memory-safe and fast (which to me implies a degree of quality, unlike Python which makes me more... apprehensive in using tools written in it) 2. Rust is still not a major language but has an enthusiastic community. Rustaceans like the spread the word!
- anonzzzies 3y ago
  > apprehensive in using tools written in it) Yes. I have that too; mostly due to the very low quality of code ‘hacked’ in the language. It is the (not so) new BASIC and everyone and their sister are launching things in it that should be considered ‘weekend side hacks’ at most, but are announced as the next best thing.
- gwd 3y ago
  3. Someone who deliberately chooses to use Rust is someone who cares enough about the program being correct to put up with the borrow checker and all that entails. This increases my expectation of the quality of the resulting program. 4. The resulting binary will be a static self-contained compiled binary. This means a) no cluttering up your environment with dependencies b) fast start-up time
  - GardenLetter27 3y ago
    Go also does the latter to be fair. If it weren't for Rust, I'd use Go. But Rust's development tools are incredible with rust-analyzer, clippy, etc.
    - gwd 3y ago
      Well yes, and I'm also more likely to install a random golang tool than a random python tool. :-)
    - marcosdumay 3y ago
      The one point on the list that Go doesn't automatically bring is #3. All the others are there. Also 5) it will keep working over time. I know that if it's in Javascript, it will take a while to make it run at all; in Ruby I've spent too long reading your site, it's already incompatible; in Python it will break in a couple of years; and in PHP it will keep doing what it promises, but I'll have to work again and again to keep it only doing what it promises.
gwervc 3y ago
To prove that at least a single piece of novel software was ever written in it. It's an improvement over the decade we had here and elsewhere of people asking devs to rewrite their software with it; a phenomenon big enough to have it's own acronym (RIIR).
odiroot 3y ago
Maybe because it's also an attempt at marketing as well.
aredox 3y ago
The ancestor of pijul is darcs, whose main weak point was slowness. Git is very simple (simplistic) in its design (in use it is another story), patch-based VC isn't.
- zellyn 3y 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 3y 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.
jodrellblank 3y ago
> "so I doubt possible added performance can matter much." From the linked "Mozilla moving FireFox to Git" blog post: > "a Mercurial and a Git mirror of the Firefox source repository [...] I think I just wanted the speed that Mercurial was not providing. Not that Mercurial was that slow, but the difference between a couple seconds and a couple hundred milliseconds was a significant enough difference in user experience for me to prefer Git" > "as time was passing and the size and depth of the Mercurial repository was growing, these tools were showing their limits and were too slow for my taste, especially for the initial clone." > "My user experience with Mercurial had reached a level of dissatisfaction that was enough for me to decide to take that script from a couple years prior and make it work for incremental updates. [...] You could get a full clone of mozilla-central in less than half an hour, when at the time, other similar tools would take more than 10 hours (needless to say, it's even worse now)." > "the repository growth didn't take a break, and the Try repository was becoming an increasing pain, with push times quite often exceeding 10 minutes." And in the comments: > "There is at least one currently very active (but private) repository that is (much) larger than Mozilla’s at Jane Street. We (Octobus) are working with them to improve a lot of aspects of Mercurial’s speed."
lemper 3y ago
because it has nothing to offer so it appeals to certain audience. there, i said it. p.s., i know it's good stuff. but still.
_xerces_ 3y ago
Reminds me of an old joke among auto enthusiasts: "How do you know if someone drives a manual transmission? They'll tell you".
- pif 3y ago
  Only a kid may consider it worthy to mention driving a manual. Manual transmission is the natural state of things. If you can't drive manual, you can not drive.
  - fifilura 3y ago
    Are you from Europe?
    - pif 3y ago
      Yes, I am. Does it matter?
- munificent 3y ago
  The most profound dilemma in life is a vegan, rock-climbing, manual-driving, Crossfitter trying to decide what to tell you first.
  - fifilura 3y ago
    In Sweden she would tell you she is winter swimming.
quesera 3y ago
> Why is it that every time something is written in Rust, it needs to be mentioned Correspondingly: Why is it that every time it is mentioned that something is written in Rust, someone has to ask why it is mentioned? Two answers for your question: * Because Rust has some special qualities, and evangelism is real. * Because we, as the developer audience, afford some additional consideration to choices made by the developers of the open source tools we use. Sometimes because we contemplate making changes, or at least reading the code to understand behaviour better. No good answers to my question, unfortunately.
pmeunier 3y ago
I can answer that question, as both the author of Pijul and as someone most Rust zealots usually don't like very much. Nothing magical in Rust, at the time it was the only language that worked seamlessly on Windows and Linux, and made it easy to manipulate on-disk datastructures, which is what makes Pijul fast. The new take on version control that Pijul brings can be roughly described as seeing "files with conflicts" as a CRDT. It was therefore crucial to be able to manipulate complicated datastructure without loading anything, and Rust seemed to let us do that without having to do C++ and spend our time debugging allocation issues in our tricky algorithms, while never being really confident that we were done. The library I wrote for this, called Sanakirja, is actually faster than the fastest C equivalent, but this isn't because "Rust is magical", far from it.
- Sammi 3y ago
  Is there a good video introduction to Pijul? Is there an online tutorial where you are given small tasks to do in Pijul? I'm curious, but not willing to read in dept documentation just yet :)
LegibleCrimson 3y ago
Because mentioning it works. As somebody who uses many different languages professionally, I immediately assume projects written in Rust are more reliable, more robust, and more efficient. My own projects are higher quality when I can use Rust to implement them, despite having much more experience with most of my other languages. As a user experimenting with tools, ones written in Rust have justified these prejudices. They simply tend to be better. It's an effective advertisement. I'm a little confused why there's always someone who brings it up. It's not like programming language makes absolutely no difference. If it's written in C or C++ and it's relatively young, I'll expect it to be unstable and to have a clunky and unpleasant interface. If it's in Go, I'll expect much better in stability, but with a funky CLI. If it's Python, I know it uses argparse, so at least the CLI will be consistent. If it's Rust, I expect it to be fast, to have very few or no panics, to have no memory issues, to have zero null pointer problems, and to use clap for a very consistent, predictable, and good looking CLI. The language has built a good reputation; I'm shocked that commenters on HN have somehow avoided picking up on that and are perpetually surprised that it has a real audience.
sanderjd 3y ago
If it's closed source, it makes no difference what the implementation language is. But if it's open source, it matters because part of deciding which open source tools to use is considering whether you would or wouldn't be comfortable fixing issues or contributing features yourself. Rust in particular seems to have developed into a net positive signal in this consideration. But it's also useful information for people who see it as a drawback!
shp0ngle 3y ago
One of the reasons git got popular is that it's FAST. One of the reasons is that's in C.

zellyn 3y ago

I personally find the mention of the implementation language as part of a project description to be slightly interesting/informative, or at worst benign. Unlike the inevitable comments complaining about it. Mercurial, written in Python, definitely experienced performance problems. Hilariously, the first search result I found when searching for "mercurial performance python" is https://wiki.mercurial-scm.org/OxidationPlan https://wiki.mercurial-scm.org/OxidationPlan, which discusses reimplementing parts of Mercurial in — you guessed it — Rust.

fifilura 3y ago
Thank you! And informative. Some days are just like that. Your synapses trigger on something because of historical reasons.
- michaelt 3y ago
  > Your synapses trigger on something because of historical reasons. When you read a product description written by someone who hopes to draw positive attention to the product, it'll usually draw attention to its most important and distinctive features first. For example, if you look up Stripe, you'll get "Stripe | Financial Infrastructure for the Internet - Stripe powers online and in-person payment processing and financial solutions for businesses of all sizes." If you look up Uber you'll get "Get a ride in minutes. Or become a driver and earn money on your schedule." Clang? "The Clang project provides a language front-end and tooling infrastructure for languages in the C language family". Ubuntu? "Ubuntu is the modern, open source operating system on Linux for the enterprise server, desktop, cloud, and IoT." When the place you usually see the product's best feature says "written in rust" it sounds like they're damning it with faint praise. Of course, not everyone follows the 'best feature first' pattern. For example, when asked about Stripe the first thing Wikipedia tells you is that it's dual-headquartered in South San Francisco, California, United States and Dublin, Ireland.
  - pmeunier 3y ago
    Wait, nobody in the Pijul team brags about being in Rust. If Pijul were written today it would probably be in Zig, for many reasons.
    - zellyn 3y 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 3y 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.
    - Lacusch 3y 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 3y 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.
- zellyn 3y ago
  No worries. And sorry for my unnecessarily sharp response! :-)

yard2010 3y ago

Because language is everything. There is no such thing that sets the context such as language, whether a spoken language or a computer language. You would never understand the "true" meaning or words without knowing the language.

DarkNova6 3y ago

I believe this is twofold: 1. Unless you abuse Rust horribly, it is both memory-safe and fast (which to me implies a degree of quality, unlike Python which makes me more... apprehensive in using tools written in it) 2. Rust is still not a major language but has an enthusiastic community. Rustaceans like the spread the word!

anonzzzies 3y ago
> apprehensive in using tools written in it) Yes. I have that too; mostly due to the very low quality of code ‘hacked’ in the language. It is the (not so) new BASIC and everyone and their sister are launching things in it that should be considered ‘weekend side hacks’ at most, but are announced as the next best thing.
gwd 3y ago
3. Someone who deliberately chooses to use Rust is someone who cares enough about the program being correct to put up with the borrow checker and all that entails. This increases my expectation of the quality of the resulting program. 4. The resulting binary will be a static self-contained compiled binary. This means a) no cluttering up your environment with dependencies b) fast start-up time
- GardenLetter27 3y ago
  Go also does the latter to be fair. If it weren't for Rust, I'd use Go. But Rust's development tools are incredible with rust-analyzer, clippy, etc.
  - gwd 3y ago
    Well yes, and I'm also more likely to install a random golang tool than a random python tool. :-)
  - marcosdumay 3y ago
    The one point on the list that Go doesn't automatically bring is #3. All the others are there. Also 5) it will keep working over time. I know that if it's in Javascript, it will take a while to make it run at all; in Ruby I've spent too long reading your site, it's already incompatible; in Python it will break in a couple of years; and in PHP it will keep doing what it promises, but I'll have to work again and again to keep it only doing what it promises.

gwervc 3y ago

To prove that at least a single piece of novel software was ever written in it. It's an improvement over the decade we had here and elsewhere of people asking devs to rewrite their software with it; a phenomenon big enough to have it's own acronym (RIIR).

odiroot 3y ago

Maybe because it's also an attempt at marketing as well.

aredox 3y ago

The ancestor of pijul is darcs, whose main weak point was slowness. Git is very simple (simplistic) in its design (in use it is another story), patch-based VC isn't.

zellyn 3y 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 3y 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.

jodrellblank 3y ago

> "so I doubt possible added performance can matter much." From the linked "Mozilla moving FireFox to Git" blog post: > "a Mercurial and a Git mirror of the Firefox source repository [...] I think I just wanted the speed that Mercurial was not providing. Not that Mercurial was that slow, but the difference between a couple seconds and a couple hundred milliseconds was a significant enough difference in user experience for me to prefer Git" > "as time was passing and the size and depth of the Mercurial repository was growing, these tools were showing their limits and were too slow for my taste, especially for the initial clone." > "My user experience with Mercurial had reached a level of dissatisfaction that was enough for me to decide to take that script from a couple years prior and make it work for incremental updates. [...] You could get a full clone of mozilla-central in less than half an hour, when at the time, other similar tools would take more than 10 hours (needless to say, it's even worse now)." > "the repository growth didn't take a break, and the Try repository was becoming an increasing pain, with push times quite often exceeding 10 minutes." And in the comments: > "There is at least one currently very active (but private) repository that is (much) larger than Mozilla’s at Jane Street. We (Octobus) are working with them to improve a lot of aspects of Mercurial’s speed."

lemper 3y ago

because it has nothing to offer so it appeals to certain audience. there, i said it. p.s., i know it's good stuff. but still.

_xerces_ 3y ago

Reminds me of an old joke among auto enthusiasts: "How do you know if someone drives a manual transmission? They'll tell you".

pif 3y ago
Only a kid may consider it worthy to mention driving a manual. Manual transmission is the natural state of things. If you can't drive manual, you can not drive.
- fifilura 3y ago
  Are you from Europe?
  - pif 3y ago
    Yes, I am. Does it matter?
munificent 3y ago
The most profound dilemma in life is a vegan, rock-climbing, manual-driving, Crossfitter trying to decide what to tell you first.
- fifilura 3y ago
  In Sweden she would tell you she is winter swimming.

quesera 3y ago

> Why is it that every time something is written in Rust, it needs to be mentioned Correspondingly: Why is it that every time it is mentioned that something is written in Rust, someone has to ask why it is mentioned? Two answers for your question: * Because Rust has some special qualities, and evangelism is real. * Because we, as the developer audience, afford some additional consideration to choices made by the developers of the open source tools we use. Sometimes because we contemplate making changes, or at least reading the code to understand behaviour better. No good answers to my question, unfortunately.

pmeunier 3y ago

I can answer that question, as both the author of Pijul and as someone most Rust zealots usually don't like very much. Nothing magical in Rust, at the time it was the only language that worked seamlessly on Windows and Linux, and made it easy to manipulate on-disk datastructures, which is what makes Pijul fast. The new take on version control that Pijul brings can be roughly described as seeing "files with conflicts" as a CRDT. It was therefore crucial to be able to manipulate complicated datastructure without loading anything, and Rust seemed to let us do that without having to do C++ and spend our time debugging allocation issues in our tricky algorithms, while never being really confident that we were done. The library I wrote for this, called Sanakirja, is actually faster than the fastest C equivalent, but this isn't because "Rust is magical", far from it.

Sammi 3y ago
Is there a good video introduction to Pijul? Is there an online tutorial where you are given small tasks to do in Pijul? I'm curious, but not willing to read in dept documentation just yet :)

LegibleCrimson 3y ago

Because mentioning it works. As somebody who uses many different languages professionally, I immediately assume projects written in Rust are more reliable, more robust, and more efficient. My own projects are higher quality when I can use Rust to implement them, despite having much more experience with most of my other languages. As a user experimenting with tools, ones written in Rust have justified these prejudices. They simply tend to be better. It's an effective advertisement. I'm a little confused why there's always someone who brings it up. It's not like programming language makes absolutely no difference. If it's written in C or C++ and it's relatively young, I'll expect it to be unstable and to have a clunky and unpleasant interface. If it's in Go, I'll expect much better in stability, but with a funky CLI. If it's Python, I know it uses argparse, so at least the CLI will be consistent. If it's Rust, I expect it to be fast, to have very few or no panics, to have no memory issues, to have zero null pointer problems, and to use clap for a very consistent, predictable, and good looking CLI. The language has built a good reputation; I'm shocked that commenters on HN have somehow avoided picking up on that and are perpetually surprised that it has a real audience.

sanderjd 3y ago

If it's closed source, it makes no difference what the implementation language is. But if it's open source, it matters because part of deciding which open source tools to use is considering whether you would or wouldn't be comfortable fixing issues or contributing features yourself. Rust in particular seems to have developed into a net positive signal in this consideration. But it's also useful information for people who see it as a drawback!

shp0ngle 3y ago

One of the reasons git got popular is that it's FAST. One of the reasons is that's in C.