Why Erlang Matters

Re:Why Erlang Matters by arh68 on Thursday April 07, 2016 @06:46PM (#11451304)

Any idea if a network-level FFI has been started? I'm thinking along the lines of the Haskell erlang-ffi [0].

    Speaks the Erlang network protocol and impersonates 
    an Erlang node on the network. Fully capable of 
    bi-directional communication with Erlang.

NIFs still limit you to < ~1ms computations, from what I understand, but impersonating a node (on another machine, even) seems a lot more flexible. Just wondering; NIFs in Rust are still a great idea.

[0] https://hackage.haskell.org/package/erlang

[ Parent | on HN ]

Re:Why Erlang Matters by toast0 on Thursday April 07, 2016 @10:14PM (#11452165)

Have you seen c nodes[1]? That may be what you're looking for?

[1] http://erlang.org/doc/tutorial/cnode.html

[ Parent | on HN ]

Re:Why Erlang Matters by wcummings on Friday April 08, 2016 @04:51PM (#11457817)

There's support for "dirty NIFs" in new versions, R19 will make it the default. Dirty NIFs allow for long running NIFs managed by the VM. In older versions, you can use nif_create_thread to create background workers, and your NIF will only block for as long as it takes to acquire a lock for your queue.

You can also use c nodes (or the JVM interface, which is pretty similar to c nodes I think).

... You can also use ports which define an interface for communicating with external processes.

The world is your oyster!

[ Parent | on HN ]

Re:Why Erlang Matters by rdtsc on Thursday April 07, 2016 @08:27PM (#11451759)

Not anymore with dirty schedulers you will be able to (as of 19.0 I think) have any long running C code as a NIF!

[ Parent | on HN ]