For many cases, writing assert is both trivial and effective, and prevents importing yet another fairly large dependency.

A little copying is better than a little dependency.

• Rob Pike

As the article (discovers?) Go does not, and has closed the discussion on, implementing TCO as "will not do."

I'm a little angry at the Go developer community for endlessly harping on Generics and letting TCO languish (the latter which led to this decision); it doesn't reflect well on the sophistication of the community.

This is a fantastic project, BTW. I've been using it for a ton of stuff for years and have never had a reliability issue. Multi-platform, even Android has a (third party) client (DroidFS).

We don't need testify... proceeds to write testify

This is how I learned, I stopped doing the TDD after a while but still a good resource.

https://quii.gitbook.io/learn-go-with-tests

Alex Edwards has a good book for web development

https://lets-go.alexedwards.net/

really didn't like them adding generics actually... :-)

Okay cool, just making sure you covered all your bases 🖖

Oops, missed that part. Ideally, this would be able to handle thousands of users

Yeah, I'll use one of the major email providers, I am aware of the risks of self-hosting email. And yes, I will implement some kind of push notification system, either through the browser or via a mobile app.

I'd carefully consider using email for this. If you're hosting the service, you might need to use one of the bigger email providers that already have reputation (unless you already have good IPs with good rep). Otherwise, you risk the emails sitting in spam and people's switches being flipped. If it is self-hosted, you'll probably need to explain the risks to users.

Given today's world of pocket computers, you might consider using push notifications of some kind. Or have a companion client that pokes an API and there is some kind of challenge/response.

I would have to store the users' cron jobs in a database, and then run some kind of loop on startup to start the cron jobs.

I was thinking I could offer the option to use cron, if not they can just select an option from a dropdown.

regarding my nonexistent readme, this is basically a digital dead man switch. The user sets an interval to send emails with a link to them , and if they don't click on the link for a few months, they get marked as dead and messages they specified beforehand get sent out to groups of users.

correct me if I'm wrong, but it seems like this wouldn't scale well

Are your users technical? If not, crontab syntax is definitely to be avoided. Instead, I'd offer some simple options like daily, weekly, monthly, etc. Then convert that syntax into crontab syntax.

I glanced at the repo, but there is no content in the README.md to get a sense of what your project is actually doing.

For processing cron, you should consider just using cron. You can setup a user specific to the process, use that user's crontab, and manage the entries. If the source of truth will be from the database, then you don't even need to read the crontab itself, only (over)write it on demand.

Depending of how complicated you want it to be of course.

I would implement it by using the basic goroutines, a wait group to keep track of the goroutines and sleep for the recurring duration.

Maybe a more optimal solution would be to use a workerpool.

Also what amount of emails are we talking about and what kind of recurring duration(1/hour or 1/year)