Composr – a Rust rewrite of PHP's package manager(github.com)
1 pointby rabbiveesh5 hours ago1 comment
  • rabbiveesh5 hours ago
    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)
    • embedding-shape5 hours ago
      > 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?

      • rabbiveesh4 hours ago
        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)

        • embedding-shape4 hours ago
          > 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)

          Seems strange to me to want to develop PHP applications without running PHP locally, but I guess I'm a "old school" programmer by now.

          But yeah, doing PHP development on macOS hardware is kind of sucky, because of the virtualization/filesystem issues. Same applies on Windows too. Not sure how developers are not all on Linux yet, the performance difference is so stark, even given the exact same (compatible) hardware. Oh well...

          • rabbiveesh3 hours ago
            The not having PHP locally installed is a reasonable decision - if your dev environment is dockerized, then you can debug it for everyone at the same time (I have wrangled many MANY local envs in my day, and I prefer it this way). Of course, for the same price you can enbug it - we had an issue that we changed the image for clickhouse when bitnami stopped hosting their image, and the new image was dumping all sorts of statistics and logs, and then eventually bloated >10GB of the stuff, leading to crashloops which ate up ALL of the virtual CPUs in the docker virtual machine. but i digress
      • rabbiveesh4 hours ago
        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.