Introduce binary Github Releases for convenient downloading
mindreframer opened this issue · 3 comments
First: thanks for zygo! I played with it 2 years and it is awesome to see that it is still actively developed! I am looking for a flexible scripting interpreter that is not bash and is practical enough to be used for daily tasks (server-side scripting / CI automation /etc).
It would be great to have a readily downloadable binary, that can be used on a system without a Go compiler.
It also does not need to be a chore and can be part of CI with goreleaser:
This is the last hurdle that keeps me ( and probably many other possible users) from using it for scripting on servers instead of bash.
So yes, zygo could really become an indispensable tool, if it is easy to access via wget / curl / brew / apk / apt-get.
Thanks again and have a nice weekend!
Roman
Hi Roman @mindreframer, thanks for the compliment and interest in zygo.
A couple of caveats:
I'm pretty busy right now, so unfortunately don't have time to maintain zygo. Given that fact, I don't recommend using it in production unless you're willing to take on maintenance duties. For example, there's a problem recently reported with packages recognized in #23 that unfortunately I don't have time to fix.
Second, my more recent work on https://github.com/gijit/gi has reminded me of the massive benefits of strong early type checking. For most all of my use cases, gijit (which provides for Go scripting rather than a lisp) is going to be preferable to zygo. Given that fact, I'm not particularly motivated to expand on zygo. While gijit may be earlier days than zygo, to me it is the future.
I am looking for a flexible scripting interpreter that is not bash and is practical enough to be used for daily tasks (server-side scripting / CI automation /etc).
If you don't need the static type checking (and since you're playing with zygo I'm guessing not), then I heartily recommend Lua and in particular LuaJIT if available on your architecture. Very mature, very fast, very cross-platform, very production ready (used in World of Warcraft, Redis, nginx, etc). Some ecosystem support, and in particular Luar (https://github.com/stevedonovan/luar) makes it trivial to call into Go code besides. Lua has very nice coroutines (I discovered becausegijit is implemented in Lua). Underneath, Lua is a nice lisp. On top, it gives a friendly to beginners syntax.
brew install luajit
So yes, zygo could really become an indispensable tool,
I would love it if others stepped up and did maintenance, but given my lack of time, its otherwise a risky endeavor if you should hit a bug.
Hope that makes sense. And best wishes.
@glycerine Thank you for the elaborate response! Yes, it makes sense on one side and it is a shame on the other. That is an interesting turn on gi with Lua + LuaJIT, yet as you said it is early days. I will follow the progress on gi, it might end up as just the right thing! All the best to you!
as you said it is early days. I will follow the progress on gi
Great! While young, gijit is already much more capable than zygo: interfaces, pointers, switch, select, complex numbers, and defer are advantages over zygo; the whole Go language is there. This was possible quickly because it is simply a port of the very mature GopherJS project from javascript to Lua. Javascript and Lua are almost identical semantically (both based on lisp, but with Lua being a bit stronger/more capable), so the port went very quickly.
The only limitations of gijit are in terms of packages and goroutines. For one package non-parallel tasks, it is quite usable. gijit can't currently import arbitrary Go source packages, but it can import Go binary packages with just a little pre-compilation effort. Some goroutine patterns won't work either, because I didn't (yet) port the part of GopherJS that detects blocking I/O or timer calls. But those won't work in zygo either, and probably never will.