A big part of the difference it that in a typical web application in most other languages, you'll think of your system in two parts: web and background.
With an Elixir/Erlang you tend to think of the web as just one interface to the application itself. The idea of background jobs in those contexts somewhat goes out the window when you have an environment where spinning up millions of processes at the same time is the expectation and not a terrifying scaling scenario.
Think of responding to an incoming web request as just another job, essentially.
Because everything is just message passing and there is no global state, the restart just looks like a function call. The supervisor will start a new process calling the function with the arguments that were passed to it when it was created.
Here's an example that will try to explain things.
https://medium.com/@tylerpachal/let-it-crash-creating-an-exa...
Also, I discovered your blog. Good stuff!
Currently reading your Insanity with Elixir + Phoenix post at http://www.brightball.com/articles/insanity-with-elixir-phoe....
I'm definitely open for new ways because the whole Sidekiq approach does work but it's a very brittle system. Not because it's a bad tool, but there's just so many moving parts and a million things that need to happen at many layers for it to all work.
Do you happen to have a blog post or code sample that ties together creating a production-ready "Elixir job"? Out in the wild it's reasonable to expect to have code fail for reasons you can't control and being able to control what happens when that does or how it re-tries is important.