
Elixir RAM and the Template of Doom - signa11
https://www.evanmiller.org/elixir-ram-and-the-template-of-doom.html
======
bnt
Elixir is a super fun language but suffers (at least in my opinion) from a
serious lack of remote jobs. And I suspect it’s because of the nature of
Elixir jobs in general: load-heavy and systems-heavy tasks for critical roles
(fintech etc), which means it’s tricky to hire someone thousands of miles away
to do the work.

~~~
rubyn00bie
Woah, I have the totally opposite perspective-- that if you want to hire
Elixir engineers you pretty much _have_ to hire remotely.

Most locales have such a small number of Elixir engineers available hiring
remotely is the only real option... Because Elixir isn't most folks first
language the hiring-pool tends to be pretty senior level engineers (even if
they're new to BEAM/OTP) meaning they can kind of choose to work remotely or
not.

> And I suspect it’s because of the nature of Elixir jobs in general: load-
> heavy and systems-heavy tasks for critical roles (fintech etc), which means
> it’s tricky to hire someone thousands of miles away to do the work.

I don't think that's the case myself or haven't seen that particular issue. In
fact, I won't forget an Erlanger I met once who was a very large company's
_only_ remote employee. I'd say the nature of BEAM/OTP mean you need to be
onsite even less because the debugging tools are so good it wouldn't give you
much.

You an remotely login to a running instance of your application and fire up
Observer. No magic, hacks, restarts, debug builds, or bullshit needed. Be on
the network, have the erl cookie, and fire up an eshell... It's awwwwwesome.

As others have said, I just think the number of places using Elixir is still
relatively low compared to other more ubiquitous languages. You really only
find Elixir/Erlang in the first place because you've probably burnt yourself
out dealing with `NIO` everywhere else and want something sane so you can once
again know the warmth joy in your cold dead heart.

/shrug just my two cents

~~~
strzibny
100% this. I have a remote Elixir gig now. We are fully remote team (there is
no office).

------
hellofunk
If only you could have really fast numerical computations that compete
effectively against C++, it would be like the best of all the worlds.

~~~
mrdoops
The runtime isn't designed for fast numerical computations, but rather I/O,
concurrency, and robustness. You can however get the best of both worlds by
orchestrating the fast numerical computations (C++/Rust/C) with Ports and
NIFs.

~~~
pkos98
IMO NIFs won't get you the best of both worlds as they tend to eliminiate the
resilient properties of the BEAM.

See
[http://erlang.org/doc/tutorial/nif.html](http://erlang.org/doc/tutorial/nif.html):

> As a NIF library is dynamically linked into the emulator process, this is
> the fastest way of calling C-code from Erlang (alongside port drivers).
> Calling NIFs requires no context switches. But it is also the least safe,
> because a crash in a NIF brings the emulator down

~~~
rubyn00bie
I think Rust _can_ give the best of both, but in general I totally agree with
you. IMHO, most people look to NIFs when they probably want to use IPC. Run a
separate process for the computationally intensive operations (e.g. ./must-go-
faster) and then let the operating system manage it. It's more reliable,
probably faster, and easier to maintain that way too!

~~~
hellofunk
What IPC method would you recommend?

------
Matthias247
For the first example: I would be actually very surprised if Elixirs way of
using a writev() for that tiny string is faster than a regular write. Based on
my previous testing it was typically faster to write just a single chunk of
data if the data was relatively small sized (e.g. < 10kB) - even if that meant
copying data into a single buffer before.

Maybe one reason why Elixir doesn't do it could be that there are no cheap
stack allocations, and it tries to avoid heap allocations at all costs?

------
giancarlostoro
Is writev seems to be the *nix version of WriteFileGather on Windows.

[https://en.wikipedia.org/wiki/Vectored_I/O](https://en.wikipedia.org/wiki/Vectored_I/O)

~~~
cesarb
It's rather that WriteFileGather is the Windows version of writev on Unix.
According to [https://man7.org/linux/man-
pages/man2/writev.2.html#CONFORMI...](https://man7.org/linux/man-
pages/man2/writev.2.html#CONFORMING_TO) writev exists since 4.2BSD, which
according to Wikipedia is older than even Windows 1.0 (which probably didn't
have WriteFileGather yet, I don't think 16-bit Windows had OVERLAPPED).

Also, looking at the documentation for WriteFileGather, it seems more limited
than writev. WriteFileGather seems to require that all buffers are page-sized
and page-aligned, while writev can gather arbitrary-sized and arbitrary-
aligned buffers.

------
ReactiveJelly
I read this thinking, "This will explain how Elixir / Erlang does some
optimization that is wild and totally impossible in any other language," and
came out thinking "Elixir / Erlang is wild and impossible to understand."

------
nelsonic
Previously shared on HN:
[https://news.ycombinator.com/item?id=11571756](https://news.ycombinator.com/item?id=11571756)

------
doonesbury
"Now, before you email me about how you implemented THE TEMPLATE OF DOOM in
assembly using only five molecules of RAM..." Love the humor.

