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.

Agreed, sounds like Orleans. See https://github.com/erleans/erleans :)

Also for general writing on erlang and k8s: https://adoptingerlang.org/docs/production/ -- I try to explain why the two work at different levels so complement each other.

Other replies are a bit outdated. It got a lot easier in OTP-23 to go without EPMD, https://blog.erlware.org/epmdlessless/ -- if you run with the same port. If not using the same port across nodes then you may want to look at epmdless https://github.com/tsloughter/epmdless

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.

makeself (https://makeself.io/) is a generic way to do this for Linux that works for any Erlang/Elixir release -- meaning no use of mix or rebar3: https://gist.github.com/tsloughter/d62aad6d67b263e69275376b1...

Maybe something as simple is possible for Windows as well?

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 :)

Curious why they suggest a reverse proxy. It may be a holdover from a time before Erlang SSL got so many improvements? Heroku moved SSL termination to Erlang from ELB's and saw great improvements, plus they released a useful lib https://github.com/heroku/snit

I suppose it could be related to their use of mochiweb still for the web layer. Maybe they'll add on HTTP/2 eventually and no longer recommend a reverse proxy.

There are alternatives for HTTP/1.1 and HTTP/2 in Erlang, like Elli (http/1) https://github.com/elli-lib/elli and Chatterbox (http/2) library https://github.com/joedevivo/chatterbox

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.

There are some performance related topics covered in the Docker chapter regarding schedulers. And there are improvements already merged for Erlang 23 to remove the need for as much manual tweaking -- for example in 23 the VM will only start a scheduler per-cpu the cgroup actually allows, so if you are limited to 2 "cpus" by the cgroup there will only by 2 active schedulers.

Erlang does have the option to bind schedulers to processors but I don't know of any real world usage of it:

Binding Schedulers: http://erlang.org/doc/man/erl.html#+sbt

Custom CPU Topologies: http://erlang.org/doc/man/erl.html#+sct

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.

Hi, one of the authors here, the Docker chapter and soon to come Kubernetes chapter hopefully shed some light on this very question. They are not alternatives, docker and k8s complement Erlang.

Jose Valim, creator of Elixir, also wrote about this recently http://blog.plataformatec.com.br/2019/10/kubernetes-and-the-...?

For 'heart' here I'm referring to the heart program that'll start if you run erl with `-heart` http://erlang.org/doc/man/heart.html -- it will restart a down node.

I think part of the confusion is you in general don't need k8s, but when your size and requirements get to a point that k8s makes sense (which arguably lowers as hosted k8s becomes better) it is not in conflict with your also use of Erlang/Elixir.

I find distributed Erlang much nicer in k8s env (I don't have to maintain it obviously) where I get an IP per node, can add a k8s service making it possible to use DNS SRV queries to find all other nodes and letting k8s worry about where pods run and keeping them up.

Plus there is configuration management and consistent storage (resources in etcd).

Sure, you can write it yourself, and probably it is even easier to write in Erlang -- up to a limit due to the issues with distributed Erlang discussed above.

I worry about, and have seen this both in the first hype phase of Erlang a number of years ago, the misconception about what Erlang offers and the resulting frustration, blaming it on the tool and quitting.

Hoping in the chapters I'm working on for https://adoptingerlang.org/docs/production/ I can better explain the benefits of running on k8s (or similar), while also making clear it certainly isn't the right choice in all cases.

- Tristan

> How much have you used BEAM?

Over a decade professionally.

The closest thing Erlang has to it is pool http://erlang.org/doc/man/pool.html

Right, they do, that is why containers are still useful to releases for deployment.

Deployment doesn't overlap. Erlang releases bundle up your code but you still need libraries like openssl, to have a nice bundle that can actually just run anywhere Docker is the way to go.

And horizontal scaling between the two do not overlap either, not sure what you mean. Packing containers (processes) efficiently into a cluster of nodes is not something Erlang does.

Edit: Erlang/OTP does offer fail over for what it calls "distributed applications" but based on a static set of nodes -- not horizontal scaling, anymore than other languages/frameworks do by letting you spawn new instances...

Yes, check out http://partisan.cloud/. Erlang distribution was not designed for the cloud.

They really do not overlap at all. I don't understand why the comparison with docker and Kubernetes continues.

Running BEAM on docker in kubernetes is great, a lot is added and operations smoothed by doing so.

The How I Start guide was just updated for 1.9 http://howistart.org/posts/elixir/1/index.html

It needs to be a matching libc. So a release that includes the Erlang runtime and is built on Debian (glibc) won't run on Alpine (musl).

If you do, please use https://hex.pm/packages/eql (https://github.com/artemeff/eql) for the file parser :)

Yup, it (whatever pieces are now under this new clause, it isn't clear, may just be some modules) is no longer free software.

"With everything running in a monolith, if a bug is introduced in one destination that causes the service to crash, the service will crash for all destinations."

The real reason people should investigate Erlang/Elixir.

You should ship a single tarball (target system built from a release) that unpacks with everything you need, including the Erlang runtime, and run it. There is no need to install Erlang on the host and better to not use escripts unless it is a user facing cli tool.

Agreed. But it has been very frustrating that they haven't allowed boards to be public.

Maybe someone knows a service that lets you mark posts from your feed to be shared as a public collection?

You like having a fix open in a PR for 2 years and then learning that your work around for the fact that fixes don't get merged or released is going to be also blocked? Because that seems to be what is happening to the person who opened this reddit thread.