I think it's more about ease of use and developer experience. I agree that in the current state servicer is a proxy to systemd, anything you can do here you can do on systemd. Later down the line I will try to support process managers on Mac and Windows.
I'm happy see this question "Why not use systemd" finally being asked. Apparently the people on NPM (2 million weekly downloads for pm2) ~~disagree~~ don't care. `pm2 start` just works, not everybody is a system admin. There are a bunch of threads around asking for a pm2 for Rust or golang. This tool tries to address this segment.
You can be a linux veteran still benefit with some commands like `ser status` which will only show the services you created, not the wall of text shown by `systemctl list-units`. CPU and Ram usage is thrown in as a bonus so you don't need to run a separate command. It's a neat trick that uses no database. The services end with `.ser.service`, this way we only see the units that servicer created. Run `ser which` and you'll get the unit and service file destination.
I'm happy see this question "Why not use systemd" finally being asked. Apparently the people on NPM (2 million weekly downloads for pm2) ~~disagree~~ don't care. `pm2 start` just works, not everybody is a system admin. There are a bunch of threads around asking for a pm2 for Rust or golang. This tool tries to address this segment.
You can be a linux veteran still benefit with some commands like `ser status` which will only show the services you created, not the wall of text shown by `systemctl list-units`. CPU and Ram usage is thrown in as a bonus so you don't need to run a separate command. It's a neat trick that uses no database. The services end with `.ser.service`, this way we only see the units that servicer created. Run `ser which` and you'll get the unit and service file destination.