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.
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.
My twitter feed has some remote Elixir jobs popping up from time to time. I just saw this 10min ago: https://www.sketch.com/jobs/backend-developer/. I don't think it's more difficult to get an Elixir job than, lets say Rust one.
While the market for remote Elixir job is small I suspect that the number of Elixir engineers is fewer than, say, JS engineers so it might balance out.
We have found 2 good remote elixir devs on HN (and one off HN) and are happy so far. We are always keeping an eye our for more! Only caveat for now is that they’re US only.
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.
String performance is also so-so with Elixir unless you happen to be an expert with the language (ie. fully understand the inner workings of everything, including meta-programming and macros).
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.
Macros are not really necessary and you don’t have to know the inner workings of everything for doing well with strings in Elixir.
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.
> 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.
> 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
In theory yes, but in practice it’s not too bad. Especially with Rust, or even Nim NIFs.
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.
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!
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.
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?
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... 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.
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."
