In my experience the difficulty of using BEAM is directly related to how well your problem fits into the actor+deep copy model of the environment. For certain problems BEAM will be a terrible solution because you're going to spend a lot of time working around this. I also think this is what makes it easily the best choice for other problems that fit this model well.

In the middle you will probably have a large number of problems that it's ok-ish at. But not really sure on what the distribution is here.

>For certain problems

Can you give an examples? Respectfully, you were asked for tasks and instead gave a description of the category.

I can only think of real-time, or real performance limited software (example: rocket guidance software, aviation, etc). With these every modicum of performance per millisecond matters; but these constraints only apply in a few (relatively) small fields of software development.

My particular problem was a back end for a medium-level multiplayer RPG (500ish people connected at once per world). The only real way I found to get it performant was to lean heavily into processes. But then you have a race condition problem and need to DIY your own method of synchronization because you're no longer using the process mailbox for that purpose.

In practice I haven't found the immutability of Elixir that useful for concurrency because data is deep copied when it goes across processes anyways. This is in comparison to Clojure where you can safely and perfomantly share immutable data across multiple threads.

I would have suggested ets tables + entity system.

From my testing, the performance characteristics of ets isn't that great - data still gets copied around when you access stuff in it. I tried using it in my exploratory tests and certain worst case, player-focused actions would take around 20ms, when using a regular GenServer with a synchronization system on top would take around 5us.

To be clear, for NPCs it worked fine. But players are hoarders and in an RPG that can result in a ridiculous amount of data being attached to them.

I'm an Erlang enthusiast, but find myself writing C for (small) things where I need to interface with struct heavy library calls, and nobody else has built up an BEAMy interface. I could build it, but it would take about the same work to just build my project in C.

Of course, maybe there's a generalized BEAM to C call library I'm not aware of? (I didn't think to search for one until now)

Also, honestly, it's a little easier to have a C daemon than an erlang daemon. Just call daemon() before the service loop vs setting up an app file. Of course, you have to build hotload yourself from dlopen and friends, and you lose out on a lot of features.

Two ideas that might help:

Elixir releases are built in and easy to use. You don't have to write an app file directly for instance.

I usually use ports for C interface (rather than NIFs). I have a little boilerplate C and Elixir that I recycle to do the ground work and then it's just your specific implementation detail.

Yeah, so I'd write just as much (or likely more) C code to interface with the library and BEAM as just writing the implementation in C.

Probably the best you're going to get for a generalized c call library is rustler or zigler (I maintain zigler)

Yeah, so those look like nicer ways to call C than writing a NIF, but they don't look like point to a C include and get the constants and a way to call the functions in the include (and use the types in the include. If I'm reading correctly.

I'm looking for the equivalent of Perl's h2xs, or something like that. (which incidentally, maybe I should be writing these things in perl ;)

challenge accepted: https://github.com/ityonemo/zigler/issues/240

> AFAIK, any modernish language is good enough to get something up and running regardless of the task.

A lot of languages that have more limited existing use have more gaps in their ecosystems. That means that to get something going quickly, you run into cases where you spend a lot more time building (or validating and tweaking existing but relatively rough) support infrastructure that you would just grab a well-tested, established library for in a language with a richer community and ecosystem. This is an area where the top tier ecosystems (Python, .NET, JVM) really shine over even second-tier popular ones like Ruby, and where both of those tower over things like BEAM, which has the additional problem that it has a fairly high impedance for incorporating C libraries, where many other platforms (some also with stronger ecosystems of their own) also more easily consume C libraries.

This extends both to broad application domains (e.g., scientific libraries) and to things like probability of having an idiomatic, language specific, well-supported client for a new service you want to tie in and incorporate.

There are things where the Ruby/Java version will be faster to use, more polished, or simply exist in the first place. I mean, yes, you can probably kinda sorta get something working with BEAM languages, but I'd occasionally hit something where Ruby had a gem, and Erlang didn't have much.

I've been porting code across platforms and most languages cannot embed themselves into arbitrary runtimes, for technical or political reasons. Had to go with rust rather than higher level languages.

If you're running a server—sure, BEAM me up.