cosmos72

Yes, from the things they've chosen to compare.

I am gomacro author's (gophernotes uses gomacro as Go interpreter) and I find the comparison needs an update.

Among other things, gomacro now supports interfaces - although gophernotes still has to catch up. It's also partially incorrect: gophernotes and gomacro are type safe I guess I will have to open an issue...

Also, IMHO the comparison criteria are chosen based on what lgo author considers important - not necessarily what's important for someone else.

Some quick examples that are important for me: portability on non-Linux systems, redefining a variable or function (lgo can only shadow them), redefining a method, allowing unused local variables...

I have great respect for what yunabe accomplished with lgo, including the deep integration with Jupyter (displaying HTML, Javascript, images...), code completion, and many other features, but I think his comparison with gophernotes needs to be updated.

For information, it's not the only Go kernel for Jupyter.

There is also https://github.com/gopherdata/gophernotes which uses a different approach: contains a portable Go interpreter, instead of invoking the Go compiler for each Jupyter cell as lgo does (lgo is currently linux only)

It compiles a plugin for each Jupyter cell code with "go build -buildmode=plugin" then loads it.

It's easy to see with Linux "lsof -p LGO_PID": it lists, among others, the loaded shared libraries - there is one per Jupyter cell code.

Hello d4l3k,

I did not try go-pry yet, but I am very curious to compare it with my own attempt at an interactive Go REPL https://github.com/cosmos72/gomacro

They look similar in several aspects, and different in some key ones. For example, mine does not try to instrument compiled code and, among other things, uses exactly go1.8 plugin to import compiled packages at runtime.