gonb VS fleet

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.

Docker didn’t have a default way to run on multiple hosts, and so in the wake of docker’s explosive adoption there was a rush of different solutions offered for scheduling containers across a fleet. One of the first well-adopted solutions was actually called fleet - it was part of CoreOS, whose team went on to be very influential throughout the container revolution. This was in the systemd era, and was basically seen as a multi-host systemd. It was very cool and it worked great!

Figure out how to revive https://github.com/coreos/fleet as something native in systemd?

I guess what in trying to say is k8s is systemd distributed but more then. I see how in line fleet and systemd is though https://github.com/coreos/fleet/blob/master/Documentation/fleet-k8s-compared.md

What you describe is essentially the original CoreOS fleet[0] project. It's distributed systemd init files.

[0] https://github.com/coreos/fleet#fleet---a-distributed-init-s...

I find it ironic half of k8s mojo, etcd, came out of this project as well.