I’m not a C fan, I’ve checked Rust and rustler, what about ocaml? has anyone made a nif with ocaml?
2 Likes
Oh Rustler looks awesome, thanks for mentioning it ^-^
What do you mean, seed up? Speed up? If so in what context?
1 Like
In a general context, may be for some number crunching
In general context it is regarded more than fine. By number crunching, what specifically?
1 Like
I would imagine the instances of needing to create a nif to call would be small and/or specialized. Maybe the question should be “What other languages can I use to create a NIF to call from Elixir/Erlang?”
well that’s the idea
For number crunching purposes, I’ve had good success with writing Python scripts (i.e. numpy/scipy) that interface with an Elixir port via erlastic (the package isn’t maintained anymore but works for the most part – look at the forks too). It’s way less of a hassle than writing NIFs in my opinion, although obviously somewhat less sexy 
There is also erlport which lets you invoke python functions directly from erlang/elixir - this branch seems to be the most active: https://github.com/beano/erlport
In general ports are preferred over NIFs because they can’t mess-up the run-time environment.
For OP: in general people do not recommend languages for interop that have their own the garbage collector and run-time environment. It might be possible but you will not be doing yourself any favors. This really does make your practical choices C, C++ or Rust.
Like I mentioned though - interop can also be done via term exchange either over a network or through the port interface. Haskell has a pretty recent library that does term encoding and network communication. Honestly I’d prefer to use something in a port interface - thats a lot less to mess up on the foreign library’s side. I think Haskell could be used in the port interface with just the term conversion from hinterface.
I also found this for OCaml; it has more support for the port interface.
2 Likes
Good libraries, I think the best and safe option could be rust
2 Likes
I’ve made NIF’s in C, C++, Rust, OCaml, and Terra (basic ‘hello world’ experiment there). Not hard at all. 
Rustler is a fantastic library for Rust to make building NIF’s easy!
Indeed, make sure it is truly worth it. Calling a NIF and marshaling the data across has overhead as well so just making a NIF that adds 2 numbers will actually be a LOT slower than doing it in per BEAM/Erlang/Elixir.
Hear hear!
Plus you don’t need erlport at all, just use the normal Port interface on the BEAM. Those libraries only help when you are talking with programs that are not Port aware, but if you can make the program yourself and just talk over stdin/stdout as proper then nothing special is needed.
OCaml has a GC but OCaml is designed to be linked safely and securely (and type safe) with C interfaces, and NIF’s are C interfaces, so it works fine. Just you might want to mark your NIF’s as CPU using so they get marshalled to another thread, just in case.
You can communicate with any program from any language that supports standard stdin/stdout communication, no libraries needed. Libraries can help for marshalling data via ETF or JSON or whatever of course, but you could use text just as easily.
That is just a library for reading/writing the ETF format across stdin/stdout (which is pretty easy to write it yourself actually, it is a dead-simple binary format). You could just as easily use JSON or text or whatever you want too.
You’d be surprised, OCaml runs at about the same speed as Rust and would be substantially shorter code (plus significantly faster to compiler, Rust compiles horribly slow). Rust would be the better option if you are doing a lot of low level SIMD work or so though.
5 Likes
Right. You can always write more code. What these libraries give you is the possibility to integrate foreign code without writing one or two wrapping layers. If you just want to call a couple of functions in numpy, I think a solution with erlport would be quicker to develop than marshaling json objects (or whatever) back and forth. A similar advantage is found I think in the ETF libraries. I haven’t used all those - the only one I’ve used is an older Ruby library erlectricity, but I found it helpful because it makes the ruby program look less foreign to the Elixir code and vice-versa. You don’t need a layer focused on communication if both programs can speak their native terms to each other.
1 Like
What about GoLang?
/me thinks golang is actually a pretty horrible and poorly designed language…
7 Likes
I can deal with it very well, only thing that I do really miss is some kind of generic typing… Dealing with golangs interface{} feels even worse than Cs good old void* (or *void, can’t remember exactly, its been a long time…).
2 Likes
The error handling is also a nightmare
1 Like
That is precisely my feel about it…
Thankfully the interface and context’s all in it currently scared me away before I could get much in to that. ^.^;
1 Like
At least there is a uniform way to report errors, unlike C, where sometimes -1 means failure, sometimes 0, and sometimes the NULL pointer or sometimes it just says “in case of an error the behaviour and return value is unspecified”.
Not even that it is uniform, but also, the compiler forces you to at least think about if you need to check for error or not (well, you should always ;)…
But as I do write this, the that it feels like gcc -Wall -Werror -ansi -pedantic -Weven_more_warnings makes me really mad…
