The title is misleading and wrong. The article is about a new library that lets you write kernels in C++.

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 :)

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++:

https://github.com/QuantStack/xeus-python

Having a C++-based Python kernel available doesn't mean "Jupyter switches to"

Playing with that xeus-cling notebook, does anyone know how to curb the `error: redefinition of` errors when changing code and rerunning it?

This bug is prohibitive enough I suspect it will be a deal breaker for the majority who want to use this kind of tech.

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.

No, that's not the article's title (which is a reasonable one), but a very heavy-handed editorialization.

I think OP doesn’t realize Jupyter supports multiple kernels and already has a bunch, they’re just adding another.

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.

But still, thanks for the mention! :)

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 ?

> AFAIK the linking characteristics of C++ are pretty bad, since the symbols are mangled in a compiler-specific way, no?

extern "C"

Any programming language that supports overloading uses mangled symbols in a compiler-specific way.

Having said this, for C++ there is extern "language" {}, with extern "C" {} being the most common.

Seems like it exposes a C API.

This isn’t a switch — ipython is still there.

This is a new lightweight option that drops some of the magic in favor of flexibility.

I don't think the big news of the article is the Python kernel, but rather the C++ library that makes writing other kernels easier.