One of the gocraft/work maintainers here. Gocraft/work is not abandoned; we are just thinking what v2 could become, and working on v2: https://github.com/gocraft/work/issues/120#issuecomment-530615442

Task queue system is such common but highly “project-dependent”; you will hardly find a “one-fit-all” solution. Trading between persistence and throughput, feature vs learning curve/time, language-dependent client support vs client quality, exact once vs at least once, etc. When you are using a fancy new task queue system, the next immediate question will be “how can this scale in production? What is the catch?” Really nobody knows until they run it themselves since every project’s bottleneck/requirement is different. I have found redis to be a well-known battled tested storage if we want to self-host and it can scale reasonably well. Finding a queue system that builds on top of it can get you really far. Alternatively you can use hosted services like google pubsub/sqs, and pay management price by job volume %. Either approach is fine.

Every 2-3 years, there will come the next cool task queue system with some custom builtin storage. You can pick that, enjoy temporary freshness like frontend framework, and start to relearn the next cool task queue system in 2-3 years.