Interactive Go REPL | Hacker News Reader

Interactive Go REPL

github.com

211 pointsblacksmythe36 comments

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.

Wow this is a HACK. In the old-school getting-things-done-I-dont-care-if-its-ugly-but-it-has-a-certain-elegance-to-it sort of way. Well done.

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?

Author here.

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.

Oh wow. You're interpreting right from go/ast? Very cool!

Yup!

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.

How'd they miss the name "gobar"? :D

It is good that they missed it. Google "gobar" and you will see why.

I'm a little afraid to do that - is it safe for work?

https://en.wiktionary.org/wiki/gobar

Wow. Guess I learned something new today.

Dried cow dung

As someone who just started learning Go, what are the other popular Go REPLs in addition to this one?

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.

[1] https://github.com/motemen/gore

[2] https://github.com/gopherdata/gophernotes

Unfortunately, gore seems to be abandonware (last commit was a year ago).

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?"

https://chrome.google.com/webstore/detail/better-go-playgrou...

^ this plugin also adds some bells and whistles like syntax highlighting to make it feel like a real IDE.

Wow, in my tests everything seems to run fine, fast and bug free, congratulations for that!

repl.it's Go REPL is quite good: https://repl.it/languages/go

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].

[0]: https://monosnap.com/file/OIO9dwR3n85xSNIdJIapGrBhbqWS4J.png

[1]: https://monosnap.com/file/AzuB6JsqRSN5f07H1ydB5t74Qh9pSA.png

[2]: https://monosnap.com/file/J3llCwPTwAcchYJWZpVG7wdB8fFXZ1.png

Another VIM ? How to exit that damn thing ? :)

This is the first real Go REPL!

How does this compare to gore?

Thank you for this

it's funny coming from python i missed the repl for the first few weeks but go's insane compilation speed almost completely obviates the need for one.

Fast compilation and restarts doesn't at all address the style of programming where you evolve an in-memory program in an exploratory way.

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.

If that is your desire, you already know not to use Go.

Personally, the idea of developing code that way for use in a server brings back many memories, mostly not good, so this is not a big problem for me.

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.

https://www.youtube.com/watch?v=a9xAKttWgP4

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

Alright, I get it. You're not interested in the subject I brought up.

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.

This makes Go much more accessible to coders who prefer this style of development.

Can't wait to give it a shot!

Reply on news.ycombinator.com