GoNB compiles each Go notebook cell instead of interpreting it

The idea is to insert a compile step in the REPL loop

The core argument is a language-design one. Go is a compiled language, but with very fast compilation, which allows a REPL style loop by inserting a compile step in the middle of it, so it becomes a read-compile-run-print loop while still feeling interactive. GoNB uses that speed to implement a Jupyter kernel. The stated benefit over interpreted Go kernels is faster execution, at the cost of an imperceptible increased start up since each cell is compiled. That is a precise trade and worth taking at face value: you are not getting an interpreter, you are getting a real compiler invocation per cell, and the same compiler that builds your project.

CGO works, but you are not writing C in the notebook

The compatibility claim is unusually strong for a notebook kernel, and the reason is the same mechanism. Because the standard Go compiler is used, there is 100% compatibility with projects, even those using CGO, and arbitrary Go compilation flags can be used when executing the cells. The README is careful to add the limit, though: it works with packages that use CGO, but it will not parse C code in the cells, so it cannot be used as a C kernel. That distinction is the difference between linking against a C library and writing C in a cell, and for a data science workflow where a dependency pulls in a C library, the first is what you usually need. The module manifest confirms the Go version requirement at 1.24.4.

Completion and contextual help come from gopls

The autocomplete and contextual help are not reimplemented in the kernel. The README credits gopls, the Go language server from the golang tools repository, which means the completion behaviour in the notebook is the same completion behaviour you get in an editor, and it is the same implementation that has to keep up with new Go language features. The kernel also caches results between cells, so a value computed in one cell is available in the next without recomputation, and compilation errors are surfaced with context you can reach by mousing over them. Debugging goes through gdlv, a GUI for the delve debugger, reachable from the kernel, which is an unusual amount of real tooling for a notebook.

Rich output, widgets and a browser automation escape hatch

The output side supports HTML, markdown with latex, images, javascript, svg and videos, and widgets, meaning sliders and buttons that you can interact with through HTML elements, with the note that you can create your own widgets. There is a Plotly integration through the go-plotly library and an Apache ECharts integration through a separate gonb-echarts project. The module manifest also lists other dependencies, such as `go-rod` and `go-zeromq/zmq4`, that the README does not describe. The WASM mode, marked experimental, compiles and executes the Go code as WebAssembly, which is the path to interactive widgets that do not need a running kernel process.

Notebooks that are Go files, and tests inside cells

Two integrations change how you work rather than what you can do. Jupytext support means the notebook can be written as a normal Go file and converted to a notebook with markdown support, which turns the notebook into something that goes through code review and diffs like source. The second is that a cell's `Test*` and `Benchmark*` functions can be run with `go test` simply by adding `%test` to the cell, so the test functions in a notebook cell are not decoration but executable assertions. There is also support for `go.mod` and `go.work`, allowing local development and the importing of specific library versions, which is what makes a notebook reproducible rather than a scratch pad.

Docker is the easiest way in

The pre-built image bundles JupyterLab and GoNB together, so trying the kernel does not require installing Go or configuring a kernel spec. The commands are two:

docker pull janpfeifer/gonb_jupyterlab:latest
docker run -it --rm -p 8888:8888 -v "${PWD}":/notebooks janpfeifer/gonb_jupyterlab:latest

The current directory is mounted so the notebook files are visible, and the URL the container prints goes into the browser. The image is built from a JupyterLab base notebook image and installs a set of utilities, and the Dockerfile documents an autostart mechanism: you can provide an `autostart.sh` file, mounted read-only, which is executed as root at startup, which is how you install extra dependencies into the container. The README also notes that there is a live version in Google's Colab that bootstraps GoNB, and a Positron extension for GoNB notebooks.

The Windows story is fresh, and the project says so

There is a tension in the documentation worth flagging, because it affects where you should spend your time. The highlights section announces that Windows support, not WSL, is working, thanks to a contributor, and adds that it is fresh from the oven so there may be some kinks and issues should be reported. The installation section, meanwhile, states that the instructions are only for Linux and macOS, and that in Windows it works in WSL or inside a Docker. The release history lines up with the newer claim: v0.11.5 is titled Windows Support, and v0.11.4 improved error reporting and added nbexec flags. The last push to the main branch was on 2026-07-27, the same day as the Windows release, and the project describes itself as experimental, saying it has been heavily used by the author in developing GoMLX.

Editorial conclusion

Adopt GoNB when your notebook work is in Go and you want the real toolchain behind it, because the kernel uses the standard Go compiler, works with CGO projects, supports go.mod and go.work, and gives you gopls completion and delve debugging inside the notebook. Do not adopt it if you want Python-style semantics, since the README is explicit that a compiled kernel behaves differently and recommends reading the tutorial first. Verify first that you can accept the per-cell compilation cost and the startup delay it implies, and note that the project describes itself as experimental and has recently added native Windows support, so treat the Windows path as newer than the Linux and macOS ones.

Frequently asked questions

Official sources

1. janpfeifer/gonb on GitHub
2. License: MIT
3. Project website
4. README
5. Releases