Elixir RAM and the Template of Doom
evanmiller.org
evanmiller.org
I've built an aggregator / scraper to combine / search all large remote job boards and simplify contract hunting for myself. You might find this useful - https://findwork.dev/?search=elixir&remote=true&sort_by=date
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
See 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
It’s only a problem if the NIFs crash (rate in my experience), or they take too long and cause the VM to hang (easier to do for big computations). Now with the newish ability to mark a nif as dirty which helps the scheduler know a nif can have longer runtimes that could block the VM.
P.S. Elixir/BEAM often also achieve resilience via connecting multiple nodes as well.
Usually the intuitive way to use strings ends up being multiple orders of magnitude slower than using a combination of macros and IO lists.
I've had some implementations of things go from taking 700ms down to < 10ms by doing nothing except replace using the String and Enum modules with an IO list and macros to remove an Enum.reduce call. Problem is, I had to ask for help to get there because it wasn't in the realm of possible for me otherwise.
This was to solve very easy problems like generating a bunch of random discount codes with a custom charset. The Python solution was really fast, super straight forward and less lines of code. I run into a lot of things like this with Elixir.
I want to use Elixir so bad for anything web based, but I find it really hard to write it, both at understanding it and having to typically deal with writing a lot more code vs Python / Ruby.
The secret for working with strings in functional languages (or in languages with immutable strings) is to realize most operations, such as concatenation, end up copying the strings. So instead of saying “string1 concat string2 concat ...”, it is better to collect a list of strings and build one final string only at the end. Here is an Elixir specific article that goes more in-depth into this: https://www.bignerdranch.com/blog/elixir-and-io-lists-part-1...
Other languages may provide specific data-structures for this purpose, such as ropes, but in a nutshell that’s all there is to it.
I never had to think of anything like this in Python. The intuitive / easiest to read code usually ended up being efficient enough that I didn't need to even think about improving the performance.
By using macros it’s relatively trivial to create sections of code that can compile to a computation graph and have a compiler create native code/nif for it.
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?
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.