"Go is syntactically a big language. Neugram’s front end has to match it, and that’s a lot of work, much of which is still to do."<p>I appreciate the sentiment – that there's a lot of work left to do – but isn't the assertion about syntax size false? I thought Go's syntax was quite small compared to other popular languages? It only has 25 reserved words (Java has 50+) and was designed in part to be uniform and easy to read.
How does this compare with <a href="https://github.com/cosmos72/gomacro" rel="nofollow">https://github.com/cosmos72/gomacro</a> which does something very similar? It seems fairly complete, or at least much further along than neugram + it does lisp style macros! If you ignore the macros its language is pretty much go except that main(){ ... } is elided just like in ng.<p>May be worth checking it out, at least for ideas/inspiration.
100% behind you on this, crawshaw. Although I've never missed having a Python style REPL for golang ("go run" usually fits the bill). You make a convincing argument for why it would indeed be a very powerful tool for any Linux admin's toolbox ;)<p>It's premature for feature requests I know. But I'd love to be able to view the Stack Trace of a live running goroutine. Typically something I log to disk using the "runtime" calls. To be able to probe that info from a command shell would be neat, don't you think?
This is really cool, but I can't help but suggest another language which works incredibly well for scripting: Nim[1].<p>Of course, I must put a disclaimer: I am incredibly biased as I am of Nim's core developers. But to help convince you, Nim has:<p>* Shebang support<p>* Error handling via exceptions<p>* A somewhat limited REPL<p>* Operator overloading<p>While I applaud the author's efforts, I can't help but wonder if Nim would fit their needs (or be easier to adjust to their needs).<p>1 - <a href="https://nim-lang.org" rel="nofollow">https://nim-lang.org</a>
I like this. Especially the error handling. Since the focus on a scripting language can be brevity (Ala perl) I don't want to write all that error handling boilerplate. But I don't want to ignore issues either. So this is a compromise. I can check errors, I can capture errors (in _) to ignore them. But if I don't do anything, they turn into panics.
this reminds me of the effort to replace a lot of the intel management stuff with linux and have userland all written in go<p><a href="https://schd.ws/hosted_files/osseu17/84/Replace%20UEFI%20with%20Linux.pdf" rel="nofollow">https://schd.ws/hosted_files/osseu17/84/Replace%20UEFI%20wit...</a>
Glad to see this using <a href="http://github.com/peterh/liner" rel="nofollow">http://github.com/peterh/liner</a> for interactive line editing.<p>I used that package in an interpreter of my own and it works wonderfully to provide `readline` style keyboard interaction in a pure Go program.
It seems like something like this would be useful for a Jupyter kernel. I don't think I'd use this as an embedded scripting language; it doesn't offer enough in terms of abstraction and conciseness to justify leaving Go. I'd probably try for a lisp.
This is awesome. I've been trying to reach for go instead of bash more and more and this is exactly what I need for the small stuff.<p>Any ideas how it could relate to the go toolchain? could I stick my Neugram files in a repo and go get them?
No shebang support? What about this? Sure it's not "native" but it accomplishes the same thing.<p><a href="https://rosettacode.org/wiki/Multiline_shebang#Go" rel="nofollow">https://rosettacode.org/wiki/Multiline_shebang#Go</a>
Sometimes switching between Go and C is weird (because of the type order or the semicolons) but I've never had any trouble switching between Go and Python.<p>Go has an awesome ecosystem for writing servers and web applications but it's obvious that the libraries weren't built for scripting purposes and the language is more explicit (for good reasons).<p>Python, on the other hand has an ecosystem that's great for scripting and language features that are more compact and terse.
You can already "go run program.go" from anywhere, even outside of a project structure, which is the same result as running an interpreted script.<p>It's a novel idea but I don't really see it taking off. Is there really that much benefit to having a shebang at the top of the file versus executing "go run" and is it really worth having a REPL for a fairly verbose language? I certainly don't see myself wishing for a Java REPL, and I don't particular see myself reaching for a Go REPL either.