I built this a while ago b/c composer is written in php for (almost) no reason. Rust is faster, and it's also Rust.
The goal was to cover the annoying bits of working on a php project - install and autoload generation. Install is parallelized via rayon, as is autoload generation.
It's so fast that i stuck it in a git hook and stopped thinking about it. The former behavior was never run install or autoload because it was too slow (especially when docker is involved)
> b/c composer is written in php for (almost) no reason.
It's written in PHP because obviously it's for the PHP ecosystem, sounds like a really good reason. Secondly, PHP is a much simpler language to learn and write than Rust, sounds like a pretty good second reason.
With those two reasons, plus the reason that composer isn't by any way slow today, nor do you deal with thousands of packages in a project like NodeJS, the very good reason of "why not just PHP" appears as well.
Leading me to ask more questions about why spending the time to write and maintain a Rust version of a PHP packager that already works OK and fine, when the existing package manager also been written in the language the users who use it know?
> because it was too slow (especially when docker is involved)
This makes it sound like you wrote this entire project just because you had Docker misconfigured, or maybe you're on Windows which struggles with many files?
The experience where I was working was that nobody would run dump-autoload in their dev environment because it would take upwards of five minutes. This was even after solving all of the surprises that we had with our docker setup.
In our case, the docker issues were somewhat endemic, because different people would touch parts of the local setup, without realizing what downstream consequences there would be.
Part of the preference is being able to run on the host without installing PHP, so you don't pay the virtualization boundary tax (we were on Mac, so it's small but not nothing)
Part of the reason i didn't just pick PHP also was that I was testing a workflow where I would let claude write the whole thing, while just making sure to validate it externally.
My experience with agents writing PHP was less than stellar - there are a lot of sharp edges that humans don't realize. Rust is a lot more reliable when you need to change a bunch of things, cuz it simply won't compile (and helpfully so) until you get it right.
I built this a while ago b/c composer is written in php for (almost) no reason. Rust is faster, and it's also Rust. The goal was to cover the annoying bits of working on a php project - install and autoload generation. Install is parallelized via rayon, as is autoload generation. It's so fast that i stuck it in a git hook and stopped thinking about it. The former behavior was never run install or autoload because it was too slow (especially when docker is involved)
> b/c composer is written in php for (almost) no reason.
It's written in PHP because obviously it's for the PHP ecosystem, sounds like a really good reason. Secondly, PHP is a much simpler language to learn and write than Rust, sounds like a pretty good second reason.
With those two reasons, plus the reason that composer isn't by any way slow today, nor do you deal with thousands of packages in a project like NodeJS, the very good reason of "why not just PHP" appears as well.
Leading me to ask more questions about why spending the time to write and maintain a Rust version of a PHP packager that already works OK and fine, when the existing package manager also been written in the language the users who use it know?
> because it was too slow (especially when docker is involved)
This makes it sound like you wrote this entire project just because you had Docker misconfigured, or maybe you're on Windows which struggles with many files?
The experience where I was working was that nobody would run dump-autoload in their dev environment because it would take upwards of five minutes. This was even after solving all of the surprises that we had with our docker setup.
In our case, the docker issues were somewhat endemic, because different people would touch parts of the local setup, without realizing what downstream consequences there would be.
Part of the preference is being able to run on the host without installing PHP, so you don't pay the virtualization boundary tax (we were on Mac, so it's small but not nothing)
Part of the reason i didn't just pick PHP also was that I was testing a workflow where I would let claude write the whole thing, while just making sure to validate it externally. My experience with agents writing PHP was less than stellar - there are a lot of sharp edges that humans don't realize. Rust is a lot more reliable when you need to change a bunch of things, cuz it simply won't compile (and helpfully so) until you get it right.