Appreciated the feedback!
I believe it’s very common situation. For most of us it’s sufficient to just use great Jupyter’s functionality. In my case, I have been involved in engineering a notebook experience, so had to go one step further and actually see how the whole thing work
After carefully reading your post, I didn’t see anything that allows the Kernel to communicate directly with the Notebook page, more specifically with its javascript.
This is needed for instance to implement interactive widgets, who may need to interact with the kernel (and user program).
Any pointers to that ? Or any further post planned in that direction ?
I wish I had this post when I started developing my own kernel for Go a while back, it would have saved me lots of time. Great post!
Niiice! I really like Go, so would be interesting to see how you implemented the kernel. Thank you for sharing
After carefully reading your post, I didn’t see anything that allows the Kernel to communicate directly with the Notebook page, more specifically with its javascript.
This is needed for instance to implement interactive widgets, who may need to interact with the kernel (and user program).
Yes, I hope to touch those topics in the Jupyter server overview and possibly a separate dedicated post on Jupyter widgets.
The Jupyter’s elephant is so huge that I have to eat it piece by piece
About the GoNB, the Go kernel: everything is kind of standard from the kernel perspective, except there is no interpreter: in compiles and executes every time a cell is executed, and it carries over (memorize) declarations (functions, types, variables, etc.) from one cell to the next. Since Go compilation is so fast, it’s very responsive. Other than that, lots of features – it even has an option to compile the cell to Wasm and run it in the notebook.
except there is no interpreter: in compiles and executes every time a cell is executed, and it carries over (memorize) declarations (functions, types, variables, etc.) from one cell to the next. Since Go compilation is so fast, it’s very responsive.
This is why it’s exciting to me!
It’s no surprise one could interactively execute Python’s code, right? What about compilable langs?
My idea to have a series of articles on different components probably would not be complete if I missed to overview a compilable lang integration into realms of Jupyter kernel protocol.
Nice, let me know if you want help writing a slide or a paragraph+diagram on the iteractive+compiler topic, when the time comes.
That’s really nice of you to offer I might bother you to proof-read that piece
Btw, next on my research is understanding how to use Comms (custom messages) to communicate between Front-End and kernel, to implement widgets.
Nice, I have not done that myself either. Curious what’s going in that part of Jupyter though
BTW, Jan, I forgot to ask what was the usecase that pushed you to create the golang kernel? Was that an ability to have a sandbox Golang code snippet execution? I know that most usecases would be Machine Learning/Data Science-related (like Python or R kernels) and Go is not that popular for those purposes afaik.
Happy to help with the article when the time comes
Custom Messages
I still haven’t figured that fully out yet. On the kernel side I know what to do, but in the Javascript side it’s still a mystery (I have 3 different questions posted without an answer on that …). I recently just reverese engineered it a bit, so I think I’ll have something working that will allow me to do Widgets (actually without the need to install extensions). I’ll post more if my tests work out later.
Why a Go Kernel
My main project is actually GoMLX, an accelerated ML framework for Go (like Jax or PyTorch for Go, using XLA, the same engine Jax/Tensorflow uses) – E.g.: a flower diffusion image generation here.
I work on ML, and I’m often annoyed with python frameworks (lack of type checking, abuse of magic that makes things brittle, absurd slowness of python for some things that need to be done outside the frameworks, etc.). So I thought I would try something different in Go.