Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Proposal for a Go Interpreter

docs.google.com

Post reply on HN
Print view View original

41–50 of 50 posts

Re: Proposal for a Go Interpreter

#41

Post by zupa-hu »

That would be totally amazing. I played with the idea of letting clients run custom code on my servers but that didn't materialize so far due to the amount of work required to safely allow that. Being able to do that easily would certainly make online tools more configurable for power-users - or let an application-economy flourish where users can share small snippets that customizes a service in given ways.

For reference, I run a website analyzing service that crawls websites every week or so and reports errors, mainly broken links. As all the document sources are available at TCP level it would be trivial to extend it with custom error reporting.

Re: Proposal for a Go Interpreter

#42

Post by thegeneral »

zupa-hu wrote: post #41

That would be totally amazing. I played with the idea of letting clients run custom code on my servers but that didn't materialize so far due to the amount of work required to safely allow that. Being able to do that easily would certainly make online tools more configurable for power-users - or let an application-economy flourish where users can share small snippets that customizes a service in given ways. For refer…

Thank you zupa-hu, this is exactly the type of use-case the proposal is intended for.

Re: Proposal for a Go Interpreter

#43

Post by ferbivore »

justincormack wrote: post #39
zamalek wrote: post #31

> To provide an interpreter that can embed inside a Go application, in order to provide scriptability to the Go ecosystem at large. Can we move away from scripting engines at some point. They are big black boxes that you throw characters into and then "things" happen that you have no control over. * What if I don't want the security? * What if I want more security? * What if I want actual pointers? * What if I want t…

V8 is large and not actually that easy to embed. There is a pure Go implementation of Lua for scripting already [1] [1] https://github.com/Shopify/go-lua

There's also GopherLua [1], which is more active and supports features like coroutines and channels.

[1] https://github.com/yuin/gopher-lua

Re: Proposal for a Go Interpreter

#44

Post by sbinet »

samuell wrote: post #40

I was surprised the GoRe REPL [1] was not in the list of existing tools [2]? [1] https://github.com/motemen/gore [2] https://github.com/sbinet/notes-and-todos/blob/master/README...

that's my personal bias. GoRe's REPL recompiles and re-runs the resulting binary after each line entered, accumulating side effects:

  $ gore
  gore version 0.2.5  :help for help
  gore> var i = 41
  gore> f := func() { i++; fmt.Printf("universe=%d\n", i) }
  (func())(0x4012b0)
  gore> f()
  universe=42
  gore> f()
  universe=42
  universe=43
when Go was released back in 2009 there has been a string of such REPLs, which don't match "my" definition of a REPL, at least, not the one I want to be able to use for exploratory work (the kind you get from a python or IPython prompt)

again, that's my personal bias. that said, GoRe is a nice project (gocode-completion, especially, is nice)

Re: Proposal for a Go Interpreter

#45

Post by sbinet »

amelius wrote: post #37

Go is one of the fastest compilers around. I think compile-speed was one of the design-goals. Hence, what additional benefit would an interpreter have?

state. as I said elsewhere in this HN thread, many of the first REPLs that appeared when Go was first released used this rather effective scheme of recompiling on the fly a single main.go file after each new input the user entered and re-running the whole thing.

nothing's wrong with that except that you accumulate side-effects:

  gorepl> f := func() { launchMissiles(); fmt.Printf(">>> missiles launched\n") }
  gorepl> f()
  >>> missiles launched
  gorepl> var a = 2
  >>> missiles launched
  gorepl> fmt.Printf("oops!\n")
  >>> missiles launched
  oops!
that's not the kind of REPL I want, and that's not what "my" REPL does (https://github.com/sbinet/igo) nor the one built on top of LLVM (llgoi: http://llvm.org/viewvc/llvm-project/llgo/trunk/cmd/llgoi/)

Re: Proposal for a Go Interpreter

#46

Post by current_call »

zamalek wrote: post #31

> To provide an interpreter that can embed inside a Go application, in order to provide scriptability to the Go ecosystem at large. Can we move away from scripting engines at some point. They are big black boxes that you throw characters into and then "things" happen that you have no control over. * What if I don't want the security? * What if I want more security? * What if I want actual pointers? * What if I want t…

Compiler-as-a-service is the future.

Lisp. You want Lisp.

Re: Proposal for a Go Interpreter

#48

Post by current_call »

iofj wrote: post #15
mratzloff wrote: post #7

Go is a great language. But why on Earth would you want to script with it?

1) play.golang.org is a popular feature of Go. Why not have better versions ? (e.g. an IPython/Jupyter kernel) 2) Golang depends on code generation for a lot of it's features. Executing generated code immediately could be helpful. 3) Very quickly execute small tests - one of my favorite python and java/eclipse features that I find somewhat lacking in Go and very much lacking in C++ development : Unit tests that execu…

2) Golang depends on code generation for a lot of it's features. Executing generated code immediately could be helpful.

That's horrifying.

Re: Proposal for a Go Interpreter

#49

Post by iofj »

current_call wrote: post #48
iofj wrote: post #15

Earlier quoted context omitted.

1) play.golang.org is a popular feature of Go. Why not have better versions ? (e.g. an IPython/Jupyter kernel) 2) Golang depends on code generation for a lot of it's features. Executing generated code immediately could be helpful. 3) Very quickly execute small tests - one of my favorite python and java/eclipse features that I find somewhat lacking in Go and very much lacking in C++ development : Unit tests that execu…

2) Golang depends on code generation for a lot of it's features. Executing generated code immediately could be helpful. That's horrifying.

Let's pre-emptively define a .ghp file format !

Re: Proposal for a Go Interpreter

#50

Post by geon »

alexschleber wrote: post #10

Here is a potentially more urgent idea: Create a transpiler Javascript to Go. Now THAT would get my attention.

The compiler team built a non-general transpiler from C to Go in order to port the compiler.

Perhaps it could be hacked to read js?

Post reply on HN