delve VS evcxr

At a recent job, we had slightly different containers for local dev; our backend containers (for a Go app) had Air [1] installed for live reloading, plus Delve [2] running inside the container for VS Code's debugger to connect to. We also had a frontend container for local dev, which didn't get deployed as a container, just as static files.

[1] https://github.com/cosmtrek/air

[2] https://github.com/go-delve/delve/

https://github.com/go-delve/delve/releases/tag/v1.21.2 Thanks Derek and the rest of the team for helping us to debug in a normal way!

My employer has a commercial solution for this but Delve does supports `rr` traces natively for this purpose, which gives a complete open-source solution (https://github.com/go-delve/delve/blob/master/Documentation/usage/dlv_replay.md).

delve and related IDE integrations

For time travel debugging in Go:

The Delve debugger for Go supports debugging rr traces: https://github.com/go-delve/delve/blob/master/Documentation/...

Undo (who I work for) maintain a fork that debugs our LiveRecorder recordings: https://docs.undo.io/GoDelve.html

Either rr (https://rr-project.org/) or our UDB debugger (https://undo.io/solutions/products/udb/) can do some time travel debugging of Go programs via GDB's built-in support for Go. I believe its weakness is in support for goroutines, since they don't map well onto its idea of how programs run.

So in my case I use https://github.com/leoluz/nvim-dap-go (which itself calls out to the CLI tool https://github.com/go-delve/delve).

Clone https://github.com/go-delve/delve.git

Emacs didn't invent REPL, and it's common everywhere. For Rust: https://github.com/evcxr/evcxr/blob/main/evcxr_repl/README.m.... But heck, the compiler is reasonably fast enough that any IDE can REPL by compiling the code.

The value here is more in being able to read a script before you run it, then have it run fast, maybe tweaking something here and there. And a compiled script will run 10,000 times faster than LISP, which can be important.

https://github.com/evcxr/evcxr can run Rust in a Jupyter notebook. It's not Golang but close enough.

The engine uses rust_decimal::Decimal to represent high precision decimal numbers, like the weight property. Serialization of RocksDB keys is done by the storekey crate. To know how Yumi's machine stores diffs, we can now ask- How does storekey serialize rust_decimal? Well, using evcxr to run Rust in Jupyter, the answer is as a null-terminated string:

In theory you should be able to create Rust notebooks (Jupyter notebook) using evcxr so maybe some AI, data analysis, prototyping make sense if you aim for good performance in final application (protype in evcxr and use notebook as reference to implement final application in Rust for speed and safety).

You should check out evcxr

There is also implementations of rust REPLs, like the beautifully named evcxr.