I'm probably the crazy one in the community who is using Elixir for the most super-strange things. For example:

- as a custom DHCP server to do multiple concurrent PXE booting (among other things)

- as a system for provisioning on-metal deployments (like ansible but less inscrutable).

- as a system for provisioning virtual machines over distributed datacenters.

I'll probably also wind up doing DNS and HTTP+websocket layer-7 load balancing too by the end of the year. Probably large-size (~> 1TB) broadband file transfer and maybe even object storage gateway by next year. I've rolled most of these things out to prod in just about year. I honestly can't imagine doing all of these things in Go, without a team of like 20.

Elixir sucks at:

- platform-dependent, like IOS, android, or like SDL games or something,

- number-crunchy, like a shoot em up, or HPC.

- something which requires mutable bitmaps (someone this past weekend brought up "minecraft server").

Actually even desktop might be okay, especially if you pair it up with electron.

> Elixir sucks at:

> number-crunchy, like a shoot em up, or HPC.

> something which requires mutable bitmaps (someone this past weekend brought up "minecraft server")

One thing I'd like to see for the BEAM communities long term are well maintained libraries of NIFs[0] for high performance and possibly mutable data structures. Projects like rusterl[1] and the advances made on dirty schedulers make this more feasible than it used to be.

It would be cool to write all the high level components of a minecraft-esque game in Elixir, and drop down to rust when you need raw performance. Similar to the relationship between lua/c++ in some modern game engines

[0] http://erlang.org/doc/man/erl_nif.html

[1] https://github.com/rusterlium/rustler

I'm in agreement; though I don't like rust (can't read it) and am the author of https://hexdocs.pm/zigler/Zigler.html

These are some good examples, and I highly appreciate you pointing out Elixir’s downsides.

What are you using to store state? The distributed system itself? An external database? Hybrid approach?

currently my main system in prod is a (very smart) stateless caching system, I don't have a database, but I will eventually spin up a (probably amazon) database, for the web gateway, when the keys to that are handed over to me. One of the nice things is that using elixir really puts you in the mindset of thinking hard about who should have responsibility for "the truth". No hiding behind objects backed by ORMs. State is pushed out as far as possible to the edge and I don't trust my server to keep state correctly. As soon as it's at risk of being inconsistent (netsplit, e.g.) the state-holders in the server are slaughtered, rebooted, and told to reconnect to the edge machines, which are trusted with the truth. The nice thing about elixir is that restart logic costs the the price of like 5-6 lines of code across the entire codebase (no worrying about cleaning up resources like tcp connections or anything).

Not in prod (personal project), I have a websocket-scraper on an aws free tier that's dropping data into a sqlite file, that I can transfer to my laptop for offline processing, so there are lots of interesting options.

This is really interesting to read, I’ve primarily thought about the DB as something which keeps your objects warm. Any recommended sources to read more about this way of treating state?

Haha I dunno, I just came up with it because that seemed like the sensible thing to do. And the virtualization library I use (libvirt) is basically a database anyways. Whenever I've talked with people who know better than I about distributed state (and iot) everyone seems to agree that pushing state management to the edge is the correct strategy in this case. For some things (like tracking customer intent and business logic) where consistency is important, like for you're responsible for someone's $$$, then you want to centralize and really be 100% certain your state is safe, and - I learned this analogy from stephen nunez, who got it from Toyota principles - you want a 'stop the world' lever when things go wrong. To prevent compounding inconsistency.

In crude and probably wrong terms, AP concerns can be more easily pushed to the edge and CP concerns like to be centralized.

When you say push state to the edge, would this be similar to how with the onion architecture you have the domain model in the center but repo access to get data on the outside?

Edit: So as not to have the DB be the ‘core’ of the app?

if you need to do some batching operations such as read from a queue, do some processing and publish to s3, I can recommend Broadway https://github.com/dashbitco/broadway

I have seen lots of codebases in lots of languages do this type of task, but aside from maybe spark on the high end, i haven't see it done better.

The beauty of erlang is your code reads like synchronous code so it's easy to read/maintain, but it has all the power of the parallelism of async code.

A BitTorrent client would be cool.

I wrote one in Scala+Akka and the actor model is great. It's even better when the runtime supports preemption, like Elixer.

An erlang BitTorrent client exists: https://github.com/jlouis/etorrent

Robotics/iot applications.