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

31–40 of 50 posts

Re: Proposal for a Go Interpreter

#31

Post by zamalek »

> 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 to do one of a million things that don't fall into the original assumptions about what a Go interpreter would do?

Compiler-as-a-service is the future. A high quality parse tree, with a built-in interpreter or possibly JITter. Refactoring tools and tons of other cool things can be built instead of the same old black box.

If it's just going to be another plain-old interpreter, it would be best to instead focus on integrating V8 because a Go interpreter would bring far less to the table (notably interpreters are typically slow and one of the big benefits of Go is that it can be fast).

Re: Proposal for a Go Interpreter

#32

Post by amelius »

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…

+1 for the idea of integrating V8.

I tried using V8 from Go, but it turned out to be a performance-disaster mainly because the garbage collection strategy of Go requires objects in Go to be movable, hence all interactions between Go and V8 have to go through a lookup-table.

Re: Proposal for a Go Interpreter

#33

Post by sbinet »

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…

interesting, it's true having a toolbox for creating go interpreters would be much more powerful.

I am not sure I completely get what a compiler-as-a-service really is. could you expand please?

(wrt JITing, yes, we considered it and it's on our radar. we know some version of it worked at some point, at least at the proof-of-concept level: https://github.com/nelhage/gojit)

thanks for your input!

Re: Proposal for a Go Interpreter

#34

Post by zamalek »

sbinet wrote: post #33
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…

interesting, it's true having a toolbox for creating go interpreters would be much more powerful. I am not sure I completely get what a compiler-as-a-service really is. could you expand please? (wrt JITing, yes, we considered it and it's on our radar. we know some version of it worked at some point, at least at the proof-of-concept level: https://github.com/nelhage/gojit ) thanks for your input!

I suppose CAAS[1] doesn't make much sense outside of the .Net community :). The idea is that you very aggressively break down the compiler into the core constituent parts.

A less Microsoft-centric project would be Clang. Clang is quite accessible and despite that it's not as loosely coupled as Roslyn (e.g. I don't think you can refactor using it), you can still solve some real problems with it (such as autocomplete and static analysis).

Basically, CAAS is the front-end equivalent of LLVM. You turn the whole compiler into a very tidy API: following from that it should be significantly simpler to create something such as the interpreter that you are aiming for.

[1]: http://www.infoworld.com/article/2621132/microsoft-net/micro...

Re: Proposal for a Go Interpreter

#35

Post by zem »

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…

#3 in particular would be a huge win, not just for tests, but for exploring bits of your program in a repl as you develop it.

Re: Proposal for a Go Interpreter

#36

Post by sbinet »

zamalek wrote: post #34
sbinet wrote: post #33

Earlier quoted context omitted.

interesting, it's true having a toolbox for creating go interpreters would be much more powerful. I am not sure I completely get what a compiler-as-a-service really is. could you expand please? (wrt JITing, yes, we considered it and it's on our radar. we know some version of it worked at some point, at least at the proof-of-concept level: https://github.com/nelhage/gojit ) thanks for your input!

I suppose CAAS[1] doesn't make much sense outside of the .Net community :). The idea is that you very aggressively break down the compiler into the core constituent parts. A less Microsoft-centric project would be Clang. Clang is quite accessible and despite that it's not as loosely coupled as Roslyn (e.g. I don't think you can refactor using it), you can still solve some real problems with it (such as autocomplete a…

ah, didn't know about CAAS. of course LLVM/CLang was also on our radar. we are still pondering on whether we should target LLVM bitcode so we could easily build upon LLVM toolchain (and cross-pollinate with other LLVM-based interpreters. e.g. seamlessly interoperate with IJulia and CLing interpreters, sharing code and values at runtime thru LLVM.) to me, the main issue with LLVM is that it's a real pain to develop against, I know this for a fact having worked a little bit with CLing, the CLang-based C++ interpreter (the edit-compile-test cycle is that of a set of large C++ libraries, gophers tend to be spoiled in that department)

tangential: actually, you can refactor with the CLang libraries: http://llvm.org/releases/3.7.0/tools/clang/docs/LibTooling.h... (well, to some extent)

Re: Proposal for a Go Interpreter

#38

Post by jfindley »

Given how fast go code compiles, I wonder how many use-cases for interpreted Go code would be solved by a good plugin system? Certainly for the use-cases where I would use this proposal, I'd be just as happy (if not happier) with a plugin system - which is probably a bunch less effort to implement, too.

There was originally a proposal for a fairly promising plugin architecture for 1.5 - it didn't make the cut, in the end, but there might be some PoC bits out there if anyone's interested.

Re: Proposal for a Go Interpreter

#39

Post by justincormack »

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

Post reply on HN