7 ms·
Elixir RAM and the Template of Doom
- nelsonic 6y agoPreviously shared on HN: https://news.ycombinator.com/item?id=11571756 https://news.ycombinator.com/item?id=11571756
- giancarlostoro 6y agoIs 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 6y agoIt's rather that WriteFileGather is the Windows version of writev on Unix. According to https://man7.org/linux/man-pages/man2/writev.2.html#CONFORMING_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.
- bnt 6y agoElixir 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.
- bkolobara 6y agoMy 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/ 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.
- sjtgraham 6y agoWe (https://teller.io/ https://teller.io/) hire remote Elixir engineers. https://jobs.lever.co/teller/2215bd6e-a1ae-461b-80a9-0b786b6529c8 https://jobs.lever.co/teller/2215bd6e-a1ae-461b-80a9-0b786b6...
- dhxt 6y agoWhile 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. 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 https://findwork.dev/?search=elixir&remote=true&sort_by=date
- rubyn00bie 6y agoWoah, 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 6y ago100% this. I have a remote Elixir gig now. We are fully remote team (there is no office).
- Kaze404 6y agoThis was interesting to read as a remote Elixir developer :p
- atonse 6y agoWe 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.
- hellofunk 6y agoIf only you could have really fast numerical computations that compete effectively against C++, it would be like the best of all the worlds.
- mrdoops 6y agoThe 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 6y agoIMO 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
- elcritch 6y agoIn 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.
- rubyn00bie 6y agoI 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!
- Matthias247 6y agoFor 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?
- tus88 6y agoC programmers are yawning.
- ReactiveJelly 6y agoI 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."
- doonesbury 6y ago"Now, before you email me about how you implemented THE TEMPLATE OF DOOM in assembly using only five molecules of RAM..." Love the humor.