Correct if me I’m wrong, as best I can tell there aren’t any reasons to use
mix run --no-halt in production vs releases. The marginal value always outweighs the marginal cost.
I’ve seen a lot of folks think that using releases means you MUST have a separate build vs application server/image/whatever. Heroku is a good example. You have a buildpack that contains Elixir and you compile your app with mix. What is the marginal cost of using releases on heroku?
Just one extra command!
mix release, and then you run
./bin/myapp foreground instead of
mix run --no-halt
The marginal cost is low, what value do we get for that cost? There are some handy defaults surrounding remote console capability and
heart (although frankly I’m a bit unclear about in what scenarios it’s going to act).
The PRIMARY value though is that releases will eagerly load all of your application and dependency code, whereas mix does so lazily.
For projects with many dependencies, there can be a massive latency spike when you first get requests / jobs that occur after starting your app with mix while it loads all your code. This can cause timeouts and error cascades. Sure the supervisor trees generally restart but there are situations where you exceed supervisor restarts per second limits and you end up having enormous portions of your app restart.
Marginal cost / benefit: (handy defaults + EAGER CODE LOADING) / (one extra command)
Am I missing something? This seems like a hands down win for always using releases.