Read the whole article. It starts by introducing xeus and xeus-cling for those who don't already know about it, then gets to the subject of the title, xeus-python, which is based on xeus and, indeed, written in C++:
Nice - I think we will make the switch to this.
We wrote a Common Lisp kernel for Clasp (Common Lisp system that interoperates with C++ and uses LLVM as the backend -https://github.com/clasp-developers/clasp)
We implemented ipykernel and ipywidgets in Common Lisp by translating the Python code. I think we could switch to Xeus and lower the maintenance burden and contribute to Xeus.
The title is wrong here. We don't claim that xeus-python will replace IPython. IPython/IPykernel has plenty of great features and xeus-python covers just a small portion of it.
hmm no disrespect intended but .. this line of the article jumps out .. "C++ is a good choice for a standard implementation of the protocol, it is a common denominator of most of the languages out there, it has a massive developer community and is widely adopted in the industry for performance middleware applications."
AFAIK the linking characteristics of C++ are pretty bad, since the symbols are mangled in a compiler-specific way, no?
If a small library implements a protocol for any new kernel to re-use, wouldn't it be better to use a language that results in stable external symbols, for linking ?
[+] [-] betatim|7 years ago|reply
There is however a kernel for C++ that you can try here: https://mybinder.org/v2/gh/QuantStack/xeus-cling/stable?file... if interpreted C++ is your thing :)
[+] [-] T-A|7 years ago|reply
https://github.com/QuantStack/xeus-python
[+] [-] proverbialbunny|7 years ago|reply
This bug is prohibitive enough I suspect it will be a deal breaker for the majority who want to use this kind of tech.
[+] [-] drmeister|7 years ago|reply
[+] [-] Tomte|7 years ago|reply
[+] [-] stonewareslord|7 years ago|reply
[+] [-] martinRenou1|7 years ago|reply
[+] [-] martinRenou1|7 years ago|reply
[+] [-] mistrial9|7 years ago|reply
AFAIK the linking characteristics of C++ are pretty bad, since the symbols are mangled in a compiler-specific way, no?
If a small library implements a protocol for any new kernel to re-use, wouldn't it be better to use a language that results in stable external symbols, for linking ?
[+] [-] T-A|7 years ago|reply
extern "C"
[+] [-] pjmlp|7 years ago|reply
Having said this, for C++ there is extern "language" {}, with extern "C" {} being the most common.
[+] [-] detaro|7 years ago|reply
[+] [-] hprotagonist|7 years ago|reply
This is a new lightweight option that drops some of the magic in favor of flexibility.
[+] [-] Sean1708|7 years ago|reply