Tasks are most useful for failure separation or asynchronous execution for a piece of code. If your current process does need to do something, which is prone to fail, possibly even because of things outside of your control, but hopefully in the control of your user, then Tasks are a good way to start. Same if you want to quickly execute something concurrently to your current process, where persistance of the job doesn’t matter. All a task does is basically inline executed code, but wrapped in another process. Only the process starting the task should be interested in the result or failure of the started task – with the only exception being the optional task supervisor. Personally I’d even say a task should not be very long running as well, because it’s unlike a job queue not sticking around in case of it being stopped by external factors.
I’m with @benwilson512 here, that for emails a proper job queue is a better fit, because you can be more certain that the email will indeed be sent. Sending emails are something once the initial webrequest is successful your system is in charge to fulfill.
Tasks imo are more useful for code, where your system is not in charge if there are failures. E.g. take processing an user uploaded file. If the processing fails (and your code works correctly) your system cannot do anything to make it work. The user needs to fix the input from their side.
I’d like to make this a bit more concrete. A task is meant to be an alternative to using
spawn, but be otp conform (see
:proc_lib), so it can be properly supervised/shut down. With that it’s less likely to leak processes with tasks. A task therfore is more than “just a process” given it implements otp’s messages, but it’s like
spawn just meant to execute a piece of code and be done.