Phoenix is frankly a lot more than Rails. If you pop open observer on a running phoenix app (:observer.start), you'd see that it's actually a collection of dozens of processes. The power of phoenix is that it's really just those processes running on BEAM in a dependency tree, so you can easily extend that and add more processes to the startup list. My phoenix app that's running in production isn't just a rails replacement; it also has long-running genserver processes for caching, communicating with key/value stores, etc, with supervisors to recover gracefully from crashes.

If you're looking for cool Elixir applications that aren't web-oriented, look into the Nerves project (http://nerves-project.org/).

>I would love to see more cookbook examples of using Elixir but NOT as a Ruby/Rails replacement.

I would love to see more examples that get away from web dev with Elixir. While it's great with the Phoenix framework there is so much more to Elixir than that. Trying to deploy an elixir daemon has been a pain and I haven't found much around that. There is escript and distillery and while I haven't tried distillery for non-phoenix apps, escript works but deploying is still a pain.

Hey, I've went through the "trouble" of using continuous deployment with elixir and distillery.

Since the project I'm working on is open source, you can see how I've done it. It's still far from perfect but maybe it could be a place to start.

Elixir app is on https://github.com/hackerexperience/helix. You'd probably be interested on `lib/release.ex` and `rel/`.

For the ci, our infrastructure playbooks are at https://github.com/hackerexperience/infrastructure, and you probably want to look at `roles/{helix, erlang, elixir}`.

Hit me up if you have questions our would like to discuss further. Email is on profile.

Btw, here's a great presentation about the topic: https://youtube.com/watch?v=H686MDn4Lo8

Thanks for this, I'll take a look and definitely hit you up if I have questions.

Dockyard (where Chris McCord works) is currently hiring staff to improve Elixir deployment, so hopefully we will see something that addresses this issue soon enough: https://dockyard.com/press/releases/2017/09/08/dockyard-hiri...

Setup deployment takes some time so I prepared blog post and an example Phoenix app how to do it with edeliver, distillery and Ansible playbooks http://blog.lunarlogic.io/phoenix-app-deployment-with-ansibl...

We spent some time with friend doing research and trying to connect all pieces to make it work.

Thanks for the link, but the issue is deploying non-phoenix apps. There are tons of documentation (well relatively tons) on Phoenix app and deployment but console apps in Elixir have very little around that I have found.

FWIW, deploying a non-Phoenix app with distillery is exactly the same as deploying a Phoenix app.

Thanks, I wasn't sure if that was the case.

For what it’s worth, the collaborative to do list is giving you an example of websockets with channels. Channels dedicates 3 server side processes per socket IIRC. One for the connection, one to supervise the connection and one to represent the user state for that connection. That’s only possible because of how cheap those Erlang/Elixir processes are. Because of that, just about any websocket example is a decent representation.

Plus, when you really start thinking about how the entire platform is designed specifically for passing small messages around between process, websockets become an even better example since that’s exactly what they do with the browser. You enable passing small messages between millions of connected clients to a server side environment built for passing millions of small messages between clustered and horizontally scalable servers.

> The real beauty of Elixir/Erlang is being able to run hundreds of thousands of concurrent "threads"

Erlang's units of concurrency are processes, not (green) threads. Unlike threads, they are completely isolated from each other.

> (co-operative in userspace, not OS-level).

Erlang's scheduler is preemptive, which means it has the ability to context switch between tasks without cooperation at any time.

> etc... for dealing with concurrent processing. This is literally what Erlang was designed to do, and Elixir makes it user friendly.

What exactly is user unfriendly in Erlang's concurrency model? You only need to understand 3 concepts, spawn, receive and send in order to perform any concurrent task. I'm not familiar with Elixir, what does it do differently?

Elixir is a lot more readable for newbies (especially people with a Ruby background), which is what I assume they mean by "user friendly". Elixir also has some nice libraries as well... one I've been digging into recently is GenStage, which gives you a way to organize process communication sort of like a conveyor belt, except that processes request more work from producers, allowing you to build a system that isn't going to break down as processes get overwhelmed.

Check out Jose's talk on it: https://www.youtube.com/watch?v=XPlXNUXmcgE

This Elixir Conf video about using Elixir for monitoring systems (with Nerves) would probably interest you: https://www.youtube.com/watch?list=PLqj39LCvnOWZMVugtyKlHMF1...

fwiw green/userspace threads are not a good thing[1]. They're only used because for the most part system level threads don't yet have the scaling properties applications need. Once that deficiency is fixed (yes...we're still waiting after 30 years) green threads can go away.

[1]Because insight at the system level is required to do effective scheduling and because the transition between the userspace's concurrency model and the system's typically introduces unpleasant limitations and sometimes bugs.

If you're saying that a thread/actor/CSP model of concurrency is better than "async" (callbacks) as used with JavaScript, then of course -- 100% agree on that.

So what you're really saying is that green threads are a good thing.

One of the biggest strengths of Erlang (and Elixir by extension) is that they take the approach of finding practical solutions to real problems.

Sure, theoretically there might be a better solution than green threads, but like you said, we're still waiting for that better solution 30 years later. In the meantime, Erlang has been powering highly reliable and concurrent systems for ~30 years now.

NodeJS people will tell you their solution is better.

Which I don't believe. Throwing away thread and managing it yourself and playing the game of will this code block the event loop is ludicrous.

> typically introduces unpleasant limitations and sometimes bugs.

BEAM VM does a very good jobs. It serves financial, large telecom, messaging, web and many other services. It is one of the marvels of software engineering. Not only does it provide this N:M scheduling well, it also provides process heap isolation between concurrency units (processes).

Heap isolation is very important, it increases safety, fault tolerance and provides guarantees that are just not there with shared memory model. Heap isolation is also other CSP/Erlang-like-clones ignore when they say they provide an Erlang-like environment. The only equivalent is really something like forking hundreds of thousands of OS processes [+]

> Once that deficiency is fixed (yes...we're still waiting after 30 years) green threads can go away.

I am not sure when it will be fixed. We'd need to be able to run one million OS processes effectively with the same latency and memory usage as what Erlang's processes currently have. We haven't gotten there in 30 years as you said, I don't think we are getting any closer. Sure there are machines that could probably run a lot more OS processes than before, but then putting an Erlang VM on the same hardware would allow running even more of its lightweight processes and so on.

[+] Another interesting exception could be Rust. If say threads were very cheap to create and could have millions of them, then could provide the same memory safety guarantees at compile time.