Gluon in Core API

[Hebali]

Is there any plan or interest in promoting Gluon (or at least some aspects of it) to the core API so that it is accessible from languages other than Python? It would be a shame for functionality like Gluon's RNN support to be limited to the Python API.

TensorFlow has implemented a lot of important functionality only in the Python API rather than the core C/C++ API and I would hate to see MXNet go that route too. I think the cross language support is a huge selling point for MXNet.

Thoughts?

[chsin]

I would also like more attention on the C/C++ API. Most of the focus has been on Python, which results in the other supported languages being overlooked to the point that they are barely supported. It seems more an issue that the C/C++ API is being neglected since (correct me if I’m wrong) the other languages call C/C++ core functions, so if a functionality is only in Python, that would mean you have to recode the functonallity in the other languages you support. I, however, only care about the C/C++ API since the code I write is mostly in C/C++, which makes using Mxnet difficult since the C/C++ API is poorly documented and neglected compared to the Python API. I understand why it makes sense for people to use Python since it’s must easier for prototyping and homework assignments, but less so for fast and reliable production code. Hence, I hope the C/C++ API won’t be neglected, though it seems like plans to improve it, e.g. #5647, are quickly forgotten.

[Hebali]

Core functionality for supported languages (namely Python, Scala, R, Julia, C++ and Perl) is delivered through bindings to MXNet's C API (see c_api.h and c_predict_api.h).

Each language's wrapper (such as R-package, cpp-package, etc) adds its own language-specific conveniences. For instance, the C++ package adds some OOP friendliness to the C functionality.

Naturally, it does not make sense and in many cases would not be not possible to include those language-specific conveniences in the C API. So, admittedly, there are numerous aspects of Gluon that cannot be promoted to the core C API.

But, it seems like Gluon is going in a direction that will lead to a lot of great functionality that could and should be included in the C API. For instance, rnn_cell.py and rnn_layer.py. RNNs are highly relevant to ML work being done in any of the supported languages. Sure, someone using one of those languages could implement equivalent functionality for themselves. But, I think such a concession diminishes the overall value of MXNet / Gluon.

As I said in my original post, TensorFlow has already made this mistake. Hopefully, they will back out of it. But why make the same one in MXNet? Python is clearly a preferred language for ML. I use it a lot and am a fan. But there are some important reasons for using MXNet in the other supported languages. Support within C and/or C++ means that native applications can take direct advantage of the functionality. The current thinking seems to be: "ML researchers develop models in Python, serialize them and then (maybe) serve them from C/C++" But that seems like somewhat short-term thinking. For MXNet's long-term flexibility and relevance, I think it is important to include as much as possible in the core C API.

[statist-bhfz]

So, is there any chance to get R implementation of Gluon (in native R code or via reticulate)?

[charlesrwest]

I would also like to see the C/C++ API have access to the same features/be treated as a first party. It is one of the primary draws of MXNet for me.

[charlesrwest]

On a related note, it looks like C++ is becoming a first party language with PyTorch:
https://www.reddit.com/r/cpp/comments/9kyfb3/pytorch_10rc1_includes_new_pure_c_frontend/