I love this! I really think the title could use the project name in it; I almost didn't click because there are tons of other go REPLs out there for explanatory programming; but nothing that gives you this drop-to-repl in a program.
Does anybody know if this is finally a real full-blown REPL? Does it allow starting new goroutines and communicating with them over channels? Does it support FFI, i.e. package syscall + unsafe? on Windows and Linux?
Or is it again a "recompile and rerun everything after each new line is added and pretend to be a REPL"? Or is it maybe something inbetween?
It's something inbetween. Pretty much the way it works is it dynamically inserts references to all objects/packages/functions in scope at compile time. It then has an in Go interpreter that uses reflection to be able to interact with those references in a transparent way.
The compiled part is just go so that part interacts the same way. The Go interpreter is only partially complete so there may be a few things that don't work as expected, but should be easy enough to add.
I'm also thinking about adding go1.8 plugin support so you can import new packages during the run instead of specifying them on the command line.
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.
https://play.golang.org/ isn't a "real" REPL but it serves the same purpose for me in most cases. You can write a few quick lines just to test a theory e.g. "What happens if I pass this function this weird input?" or "Will this regexp function do what I think it does?"
The one that has seemed reasonable last I checked, was gore [1]. Then, you might want to check out the Golang Jupyter kernel as well (gophernotes [2]), which mentions gore as an inspiration.
I find repl.it's go REPL to be totally unsatisfactory. I don't want to have to type `package main` at the top of my REPL before being able to evaluate any expression [0]. Avoiding that sort of boilerplate is a REPL's raison d'être.
In contrast, [gore](https://github.com/motemen/gore) lets you start evaluating expressions right away [1], and provides nice REPL short-hand for importing packages [2].
It doesn't,but op mentioned coming from python and I don't think many programming languages outside the lisp family have anything near a good REPL experience.
The few times I have tried to do serious work in python hasn't really impressed me much in that regard.
yes it does? unless you're unable to write a single line without interactivity. i do literally the same thing in go as i did in python (when i needed to): write a little and hit compile to watch what happens (except i add a fmt.Println(fmt.Sprintf("%#v",x)) or something like that). often the entire thing happens faster than it would take python to just interpret a similar line and execute.
Find a screencast along the lines of someone livecoding something from scratch in a single editor-connected REPL session. Maybe using Clojure (or similar), and you'll appreciate the fundamental difference vs booting up fresh processes that start from line 1 of 'main' again and again.
that's a trick though - no one uses interpreters like that. for most people they're for experimentation, which is exactly what i was saying i'm able to do with go.
The style I'm talking about, code isn't typed directly into the REPL/interpreter!!
You work in your real text editor and it has a connection to a persistent session of the language runtime, over which you can send fragments, lines or whole files into. And receive data back if you wish. You can refine or replace as little or as much of the program as you want, while it is running.
Say there's a power cut and your computer turns off. No big deal because you were working in your real text editor and saving source files to disk (but not necessarily sending all of their content into the session).
It's not trivial or a novelty. I get that a traditional line-at-a-time interpreter inside a terminal à la /usr/bin/python isn't super compelling. That's not what I'm talking about.
(I am also a happy user of Go FWIW. It's the C style of programming in a super-refined form (not surprising considering who 2 of its creators are!))
>You work in your real text editor and it has a connection to a persistent session of the language runtime, over which you can send fragments, lines or whole files into. And receive data back if you wish. You can refine or replace as little or as much of the program as you want, while it is running.
...that's even closer to the style that fast compilation lends itself to
Agreed. Where I do miss a true REPL (and fingers crossed, this project is it) is when I don't have a specific Go project I'm working on but want to quickly explore an idea.
