Hello Louky, thanks for the question :)
Support for out-of-order code is one of the last missing features, and I am am pretty confident it can be added with reasonable effort, given the large amount of static type analysis that gomacro already performs. In my opinion, the hardest obstacle to full 100% language support is already solved: implementing the declaration of new interface types, and that's up and running :) About the performance: code running in the interpreter is currently between 10 and 100 times slower than compiled Go - a typical value that comes out in several benchmarks is 30 times slower. But: * imported packages are **compiled** and run at full speed * code startup is instantaneous, even with the current pre-interpretation pass that converts source code first to ast.Node, then to a tree of closures for faster execution - such pass typically takes less than 1 millisecond. Also, the use cases for a Go interpreter are quite different from a Go compiler: an interpreter is useful when you want to interactively manipulate data (think about a huge dataset that takes a long time to load from disk: an edit-compile-run cycle will have to load it every time), or explore complex data structures interactively, or perform exploratory programming (gomacro lets you redefine constants, variables, types, functions and methods on-the-fly), or add a scripting engine to an existing program, and the list could continue... a Read-Eval-Print-Loop (REPL) is really a different beast from edit-compile-run cycle, no matter how fast the compiler is. Probably, a very overlooked advantage of an interpreter is that it's MUCH easier to write language extensions inside it than inside a compiler. Gomacro already offers four extensions compared to compiled Go, and in the announcement I forgot to mention (in my opinion) the most important one: extremely easy code generation using macros. More than 75% of gomacro code is generated with this technique, and I will present the topic at Golab.io conference in Italy in October. Before that date I should have some documentation available too - they reproduce Lisp macros almost literally, but I guess most Go programmers do not know Lisp. On Friday, April 27, 2018 at 10:12:46 PM UTC+2, Louki Sumirniy wrote: > > How does it perform compared to pre-compilation? I would think it is such > a thin margin it's barely worth doing? Also, order-dependency is a pretty > big problem considering how little Go code will be written in this kind of > order, since it doesn't have to be. I would think therefore that to fix > this problem you will have to have a pre-interpretation pass on the parser > that populates the namespace and dependency-orders it. > > > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
