Their demo is a chat app. The main thing you build in the Pheonix book is a chat app. They may not have fully established themselves in the chat realm but the majority what they talk about is chat related. Eg having 2-3 million concurrent users in a chat on one server. Working on built in Presence in the Pheonix framework.

I mean there is work in Embedded with Nerves. But everytime I hear anything about Elixir it's related to communications in one way or another.

pretty cool, I’ve only dabbled with Elixir. I wonder if a pervasively async Clojure server could compete for the chat use-case? I’m thinking aleph/manifold/core.async with a data-store that supports fully-async operations.

@shanekilkelly: i'm working on an all-clojure/script fully-async solution like that - not oss tho, and i've no idea about capacity yet

cool, best of luck with that would be interesting to see a blog-post or something once it’s done.

how are you managing data persistence?

that seems to be the main blocker, (literally).

@shanekilkelly: we have two sorts of persistence - long term persistence for query-based retrieval, for which we are using cassandra, and short-term persistence of events awaiting processing, for which we are using kafka

cassandra has an async java client, a low-level async clojure client https://github.com/mpenet/alia, and our own higher-level async clojure client - https://github.com/employeerepublic/er-cassandra/

and kafka production is async with https://github.com/pingles/clj-kafka

@mccraigmccraig: nice. I haven’t looked at cassandra yet, will check it out. I’ve mostly been using jdbc/postgres with clojure, but it’s a blocking api.

@shanekilkelly: postgresql has much more advanced query facilities than cassandra - but cassandra's scale and reliability stories are way in advance of postgresql's - i figured to start out with components that are known to scale would make scaling much less painful when it comes, and that is reasonable as long as working with those components isn't an order of magnitude harder than postgresql (which it isn't)

@mccraigmccraig: I like your reasoning re: scaling.

pretty much the same way I’m thinking.

what’s the problem domain? (if you don’t mind sharing)

basically using chat services as a foundation for other business services which have an easy-to-quantify value

the first such service we are looking at is arranging shift-swaps or emergency-cover for businesses where an unplanned staff absence has a distinct financial impact - either lost earnings for the business, or a guaranteed service provision requirement meaning expensive emergency cover arrangements

sounds fun