gonb VS Docker

I've had these strong feelings and the OP describes it really well. Despite being a polyglot programmer, I really struggle with Python, both in expression and performance (unless it's just config for GPUs).

Some of this frustration was recently an "Unpopular Opinion" on the Go Time Podcast regarding Python being great for "data exploration" but not for "data engineering": https://changelog.com/gotime/304#t=3196

I've been yearning for better interactive tooling and ML-related libraries bridge this gap and started using some even in just the last week:

* GoNB (Golang-support for Jupyter notebooks, also from a Googler) https://github.com/janpfeifer/gonb

* That uses Go-Plotly for graphs/UI: https://github.com/MetalBlueberry/go-plotly

* GoMLX (GoNB author is also on that project, many thanks Jan!) https://github.com/gomlx/gomlx

* Hidden at the end of OP is LangChainGo for LLMs, which I haven't used yet: https://github.com/tmc/langchaingo

Pick those up and let's make the Go community stronger together!

When I created a new Jupyter file in Go, I faced a challenge trying to replicate the development process I usually follow with Python. In Python and Jupyter Notebook I can conveniently run code in separate parts, saving previous values in memory and using cells to organize code. This flexibility was missing in Go, and it took me some time to figure out a solution. However, I came across a helpful tutorial that explained how to use caching with the Go Kernel, making the process smoother with gonb.

I needed one more thing to make myself feel at home, something I usually use with Python. When working with data, I often turned to the Jupyter VSCode extension for its convenience. To my relief, I discovered that a Go kernel existed, tailored perfectly for my needs.

Training library, with some pretty-printing. Including plots for GoNB Jupyter notebook.

Tutorial (and demo) here. Source code in github.com/janpfeifer/gonb.

I'm not touching anything Docker anymore.

Here's the scenario: you're the unfortunate soul who received the first M1 as a new employee, and nothing Docker-related works. Cue multi-arch builds; what a rotten mess. I spent more than a week figuring out the careful orchestration that any build involving `docker manifest` needs. If you aren't within the very fine line that buildx assumes, good luck pal. How long has `docker manifest` been "experimental?" It's abandonware.

Then I decided it would be smart to point out that we don't sign our images, and so I had to figure out how to combine the `docker manifest` mess with `docker trust`, another piece of abandonware. Eventually I figured out that the way to do it was with notary[1], another (poorly documented) piece of abandonware. The new shiny thing is notation[2], which does exactly the same thing, but is nowhere near complete.

At least Google clearly signals that they are killing something, Docker just lets projects go quiet.

How long before this project lands up like the rest of them? Coincidentally, we were talking about decoupling our CI from proprietary CI, seeing this was a rollercoaster of emotions.

[1]: https://github.com/notaryproject/notary