Earlier quoted context omitted.
I'm not exactly sure I'd call those "bindings". If you want an actual compelling competitor to us because we're not a big name, at least look at mxnet. That's more credible. It's incredible that folks insist on this still. Both those frameworks aren't even going to be aiming for any level of integration with the JVM. At least take a look at what makes us different. A big one being: https://github.com/bytedeco/javacpp…
It sounds like you got a bit angry because of my comment? Sorry, I didn't meant to mean it negative in any way, esp nothing negative about DL4J. I just thought that it might be a good contribution to the discussion to have a more complete overview of the DL options in Java, as it was not mentioned here. Of course, there are advantages and disadvantages for each. E.g. TensorFlow might be more well-known but its Java b…
I guess what I was elaborating on (partially for clarity of other readers who really don't know the difference, partially as a response to your comment here) was the fact that they really are very different things.
My problem with these things being posted as "alternatives" is: deep learning is just 1 part of the suite.
When you want to do anything with these other frameworks, usually python is somewhere in your workflow.
That isn't my only complaint though: Dl4j "the deep learning framework" is 2 parts. Nd4j (the tensor library directly comparable to TF/mxnet,..) and dl4j the deep learning DSL which is higher level like keras.
As for your point about folks using C++/Java bindings: Even "production" ends up being nuanced there. TF has different deployment modes with almost no out of the box tooling for very common deployment scenarios. That includes things like kafka, spark,..
We take an angular js like approach to this. Rather than have deployment as an exercise left to the reader, you get imports from different frameworks, a clear way of doing everything from ETL to setting up a server, and a way of actually debugging/controlling things from the JVM rather than using some SWIG bindings with a black box.
For example, our tensor library has deep integrations with the java gc which allows reference collecting as well as in java memory management system for cpu and gpu all for handling management on the gpu.
You need to control those things if you say: run things on a tomcat server. You don't get that granularity when just deploying some c++ bindings. There's a reason I emphasize having the full runtime tooling available to you (not just integrations).
So yes: In general when I see someone just off hand pitching these things, I clarify it. As I said in my previous comment: A whole application suite is a very different approach than a "tensor lib with autodiff and some java bindings".
People have different use cases and different requirements. I'd at least like a fair comparison side by side though..