Well, hotloading is very powerful, and can really mess things up in a hurry. You've got to plan for it. I wouldn't expect ejabberd to be built to hotload between releases (unless the docs say you can)

But for hotfixes, it's great. And for code you write, it's often possible to structure even large changes for hotloading.

A lot of people have built deployment around the limitations of other technology, and it's a hard thing to get them to hotload. But if you can, it really reduces the cycle time between when you detect an issue and when its fixed and deployed.

Short cycles are great because for many issues you can pick the issue up, fix it, deploy it, verify the fix, and be done without having to switch tasks. Additionally, a short cycle reduces the duration of impact for simple bugs, which means you need to spend less effort on finding them before deploy (probably not no effort though). Complex bugs that persist broken state are still difficult to remedy, so you should still spend significant effort on finding those before deployment.

(Also, I'm really not sure why having the port installed would interfere with building a new one, but I've always built Erlang with make and erlc which is maybe a bit unusual)

I like it a lot.

The big advantage of Rustler vs. say, writing C or using Zig's equivalent, is that you can just use any Rust libraries. For example, I wrote Rust<->Elixir bindings to xxhash and CANBus for our industrial control/embedded applications, and it was quick to do. Very little ceremony.

Rustler provides these Encoder and Decoder traits (and implementations for most stdlib data structures) that make it easy to pass data back and forth across the FFI boundary without you having to manually do it, and they've done all of the work of writing/generating the bindings to Erlang's C API. It also includes a generator to easily create a new NIF that integrates into your Elixir project.

Of course, you need to know both Elixir and Rust to a high enough level, but if you do, it's really pretty straightforward to just either wrap an existing Rust library, or to rewrite some hot path in Rust and schedule it on a dirty CPU or IO thread.

I haven't used it. I've written and used NIFs, but mostly they're simple enough that C is fine, and Rust isn't really needed. I think discord ends up with complex data structures in their native layer; Rust seems reasonable for that, but I never experienced that need.

That said, I did have a concurrency issue with a NIF I used, but I don't know if Rust would have been helpful or just made it really hard to express.

This is pretty interesting. Thanks! I didn't have time to dig into it [1], but something that's a bit ugly is something like a PCI BAR, defined as

   Bits 31-4: 16-Byte Aligned Base Address
   Bit 3:     Prefetchable (flag)
   Bits 2-1:  Type
   Bit 0:     Always zero

In Erlang, this gets parsed with something like:

   <<BaseLS:4, Prefetch:1, Type:2, 0:1, BaseMS:24/little>> = BAR

and then you have to put the Most Significant and Least Significant parts back together somehow, and there's the zero filling too, like maybe

   <<Base:32>> = <<BaseMS:24, BaseLS:4, 0:4>>

If the structure were big endian, you'd probably have bits 0-28 be the address and bits 29-31 be the flags, and you could parse it as

   <<ShiftedBase:28, Prefetch:1, Type:2, 0:1>> = BAR,
   Base = ShiftedBase bsl 4

You could also just do

   <<BaseAndFlags:32/little>> = BAR

and then mask out the flags and stuff, but then you lose the joy of pattern matching, or you defer the pattern matching which means you'd lose out on matching in function heads or have to have an intermediate parsing function that calls the real function with matching in its heads.

[1] I looked a bit more and the example seems inline with Erlang syntax https://bitstring.software/documentation/#constructing-bitst... shows something similar to what I would expect with

  Version = 1,
  Data = 10,
  <<Version:4, Data:12>>.

You could say Data:12/little, and that does flip bits around, but a little endian C developer isn't going to be happy with what results. It's not natural for them to combine the lower bits of byte 0 with the bits of byte 1.