Is that possible, if so how? Or is it better to develop a dotNET / ASP (c#) application that would interact with the external dotNET library directly?
One way is to compile an exe file including the c# stuff then use erlang ports
1 Like
Considering that no dotNet library conforms to any library spec at all, no, not a chance (.NET really sucks in a lot of ways, this is one, same with Java). 
You’d have to make an app using that library and talk to it that way.
why you think .net sucks at the same level of Java? 
Many many reasons.
They are not functional yet have a GC.
They are incapable of creating base-linkable libraries
They require utterly ginormous runtime’s (.NET is finally getting some AOT, but still need that nasty runtime last I saw).
Their installation size is also ginormous (a piddly program in both .NET/Java and, say, C++ can be the different between tens of megs for a minimal VM install compared to a few kb for the C++ native app).
Even OCaml, which does have a GC and is functional still compiles to near microscopically small stand-alone program sizes that can be native linked into, say, the BEAM VM.
And that is only the tip of the iceberg, the number of bugs I’ve encountered in their VM’s from specific math calls in specific orders corrupting unrelated memory to GC freezing is astoundingly bad just in those alone…
/me has had a lot of experience with the JVM, a little bit with .NET, do not like either
If I want a fast language then I’ll use C++ or OCaml (or maybe Rust now).
At the very least the fact you cannot even link it into another arbitrary program, statically or dynamically at the OS level, is just annoyingly stupid… At least the BEAM VM pretends to practically be an OS in its own right, and it still let’s you link in native libraries. Honestly I’d not give the BEAM VM or any language on it any more than a cursory learning look if it were not for it’s absolute reliability, distribution, and ease of working with about anything else. The Java and .NET VM’s don’t have any of that.
/me is trying really hard not to go in to rants about the jvm and .net VM’s…
2 Likes
Maybe not sucks but it runs in VM , so you embedding one VM in another Erlang VM . I think this is not good solution, good luck with debugging problems. If you need some dontNET functionality why not create micro service and use it as service for Elixir?
That would be the thing to do there, either via a Port or a socket or something. 
Would it be easier to integrate or interact with a Java library inside a Phoenix/Elixir application, compared to dotNET?
Erlang provides a module jinterface when compiled with this feature. Afaik it is to make something like a c port in Java. But I have never worked with it, since the availability of the feature is optional in an erlang installation, while one can’t specify it as a dependency to fetch from hex…
So you can’t rely on it.
+1 for Erlang ports. This would be the approach I’d try. I’ve blogged about this technique here. My examples use Ruby, but it should work with .NET apps as well.
5 Likes
(Disclaimer, I’ve never used this, I’ve just read the documentation)
Have a look at JInterface - it’s a set of Java classes/interfaces provided by Erlang that can make your Java program look like an Erlang(Elixir) node. So from the point of view of your Elixir code, you are just writing plain Elixir that talks to some process via messages and what not.
From the point of view of your Java code, you have to create “processes” to receive messages (actually, mailboxes) and you can also send messages to remote Elixir processes. How do you set this up is up to you but it seems straightforward.
(I’m not sure if what @NobbZ says holds: on my installation I can find the OtpErlang.jar file by following the instructions at “1.12 Compiling and Loading Your Code” - I installed Erlang via asdf).
1 Like
I have just tested Erlang / Java communications via JInterface, looks fine. So this interface makes it possible to execute Java code inside Phoenix and retrieve results back?
JInterface runs inside it’s own OS process - so I wouldn’t describe it as “Java code inside Phoenix”.
JInterface allows other nodes to communicate with it via BEAM-style messaging. The code you write to run behind JInterface is pure Java code running on the JVM - so if you want concurrency you have to use the usual Java thread management. On top of it all it’s up to you to translate/transform the typical Java “method on object” interaction protocols to something that works as a messaging protocol.
1 Like
In a different context Saša made an interesting comment:
I take this to be an opinion that is informed by experience. Since then I’ve been a bit more skeptical about C Node/Jinterface based solutions even when they seem to be somewhat convenient.
To get back to your original post about a dotNet library - I personally would favor a solution where the dotNET code can live where it is happiest (Windows Server?) while Phoenix isn’t tied to Windows and Phoenix can access the dotNET library’s capabilities via some non-BEAM specific protocol. But that’s just me.
Whether the capabilities of that library is worth that kind of overhead is a separate issue. What job is more critical? What the library is capable of or what Phoenix is going to be doing? If the library’s capabilities trump everything and it’s too costly to duplicate elsewhere and Phoenix’s contribution would be relatively minor then I would lean towards a dotNET centric solution. On the other hand if the Web API/front end effort is significant enough and Phoenix can have a significant positive impact, wrapping the dotNet Library in a “service” may be worth the effort.
1 Like
@peerreynders … The library I have in mind is the SAP Business One DI API which makes all sort of interactions possible with SAP Business One. I think the native path can be best.after all: dotNET ASP Web Api integrating that library. Phoenix can be used if all those functions are exposed by some SOAP API provided by the SAP B1 software developer.
Be aware that while .NET and Java support SOAP fairly well for historical reason it’s no picnic to use from less mainstream environments.
So while a .NET/Java developer can expose/consume a SOAP interface with a click of a button (it was heavily pushed by WS-* tool vendors after all) developers for other environments may have to work a bit harder - i.e. possibly having to learn the relevant parts of SOAP/WSDL and sling XML accordingly.
