I can think of many uses for macros, so it's a good thing though I will never use a language that compiles to Go because I like static typing. It would be a logical next step to implement by-default reflection and dynamic typing. But I don't see the benefit. Go's whole schtick is about how it's static typed, and uses an implicit build system based on the structure of a repository filesystem. People choose it because of these two things. Newbies stuck in mindsets taught by dynamic typing and OOP and FP languages struggle with Go and don't realise that providing these features goes counter to the whole point of the language.
I think a good direction, however, would be a code generator, and a declarative syntax for this, to speed up prototyping, and macros are an important first step towards that. On Saturday, 28 April 2018 04:00:41 UTC+3, Max wrote: > > 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.
