kungfooguru

Or Erlang for even less noise ;)

    -module(math).

    sum(A, B) ->
        A + B.

Exact conversation I had with support after they suspended me after I sold something for the first time, but before I mailed the item. Its like they just randomly permanently suspend people.

Try both. It may be because I've been doing Erlang so long but I still prefer it and its tools (like rebar3 and Common Test). I find the syntax more consistent, less verbose and the lack of Elixir style macros to mean less confusing third party libraries.

But I do think Elixir has its strength in web applications. The macros make Phoenix and Ecto much simpler for building full web applications and if I were building a full fledged interactive web application I'd reach for those.

So mainly personal preference, you may find Elixir preferable, but all that to simply say it is not a "strict improvement".

Oh, and one none personal preference reason: it is nice to do libraries that don't benefit from being written in Elixir (like postgrex and jason get a lot of performance out of using macros so there isn't an argument to write those in Erlang) and aren't specific to Elixir (like a Plug adapter) in Erlang so they are more easily usable across BEAM languages, a list that continues to grow.

Not a big deal but, it was actually a bug in relx that caused it to be included (accidentally copying the erts dir from the symlink/copy in the _build/<profile>/rel/<relname>/ dir instead of from the unpacked tarball generated by systools when doing the final assembly), not `include_src`, that option only applies to the Erlang applications and not the runtime.

4. The compiler should not be included and neither should the headers. Unless a user explicitly wants to include the compiler and also have a C compiler on the node in order to compile stuff on the target node there is no reason to have the header files there and relups work fine without them.

If Elixir 1.11 'mix release' still includes all of the `erts` directory then an issue should be opened.

> Why are there 55 c-header files in the directory of the erts?

That shouldn't be the case anymore. It was a bug in rebar3 at one point and I think `mix release` may have copied said bug. If 1.11 doesn't properly not include those header files then an issue should be opened.

Not really worth it since distributed mnesia is basically CA (in terms of CAP) which shouldn't be a thing, but is in the case of mnesia :)

If you get to choose your infrastructure that may be fine. If you don't and you work in even a medium size company you likely work with what they have, which is increasingly kubernetes.

That said, they still do not do similar things. OTP does not take care of orchestration if you must run more than 1 node.

You are still benefiting from OTP's supervision and scheduling when using docker or k8s, the difference is in what other features and the size you need.

No one is saying always deploy to k8s, but they are not overlapping.

Nor does using BEAM make it uniquely fitted to running on physical machines compared to other languages like java, go, C++, Rust, ... If your application is suited to running on a few droplets the language you are using is not likely the deciding factor for that.

It is not going against the grain. Using release upgrades (upgrading a release without restarting the VM -- unless the version of erts has changed) should only be used where necessary and they rarely are.

They are great to have when you need them but should not be chosen lightly.

Part of the point of this booksite is to show integrating Erlang into a modern environment and not being the oddball deploy at the company. It is the lack of libraries for services used for deployment/monitoring and lack of documentation that is the reason for this.

Also, there is no abstracting away network partitions.