This language seems to remove lots (almost all?) of the goodies of Go, like multiple return values, type checking by the compiler, gofuncs and channels, slices, maps and enforced naming conventions, and replace them with stuff from PHP, like interpreting "0" and "nil" as false and weird meta-methods.
Yeah, the senseless differences are deal breakers for me. It seems to be written by someone who is pining for Java - single returns and exceptions, no preamble before if, ternary operator, etc.
It would have been simpler to just make "dynamically typed Go".
What I would want in such a language is (in formal set-theoretic terms) a strict superset of Go. I would want something would run code that would also be compiled by the Go compiler, but which would also run programs that omitted type declarations. (Hence, the set of strings that are valid programs is larger than for Go, and also includes all valid Go programs.)
Such a language could be used as a REPL and dynamic debugging environment for Go. That would be utterly fantastic.
Most of the differences are actually Lua-like semantics, which is perfectly in line with the author's goal of making a "Lua for Go". I suspect that v0.2 will branch out from there a little.
Personally, though, if I wanted a Lua for Go, I'd just use Lua (or maybe LuaJIT).
That's fine, I know it can't please everyone, but as mentioned in the docs and the article, this is more about Lua-like semantics with a syntax very close to Go than Java. There are no exceptions per se, there are runtime errors returned to the Go host, and a protected mode using `recover()`.
The preamble before `if` is mainly because the variables are function-scoped anyway, but again, a lot of things may change, this is the very first step in a long iteration process, and the feedback I'm getting today from the various forums will help a lot in knowing how to steer the ship.
Hi, author here. Actually, Lua and Javascript were more of an influence than PHP (I don't know PHP much). But type checking was an obvious thing to remove since I'm aiming for a dynamically-typed language, and I do want sufficiently different (and looser) constructs than Go so that it can find its niche, otherwise what's the point?
I'm definitely not done, and multiple return values are one of the points I'm not fully decided yet (this is a v0.1 after all). Interaction with channels are on the roadmap, and concurrency can be done in the Go host to run different execution contexts.
I was discussing with a friend online about a scripting language for Go that would integrate as well with it as Lua does with C.
We concluded, however, that the best option would be to write a Go interpreter (in Go of course). One of the key reasons why is to maintain full compatibility with Goroutines and channels.
I never got started on that project though... too many others need finishing. Bravo on publishing your vision!
Why do you think that? I find JS's numeric rules (float, except when you use bitwise operators) quite convenient and safe. Some examples of things that are awkward with float-only numeric would be helpful.
14 comments
[ 3.2 ms ] story [ 44.2 ms ] threadIt would have been simpler to just make "dynamically typed Go".
Such a language could be used as a REPL and dynamic debugging environment for Go. That would be utterly fantastic.
Personally, though, if I wanted a Lua for Go, I'd just use Lua (or maybe LuaJIT).
The preamble before `if` is mainly because the variables are function-scoped anyway, but again, a lot of things may change, this is the very first step in a long iteration process, and the feedback I'm getting today from the various forums will help a lot in knowing how to steer the ship.
I'm definitely not done, and multiple return values are one of the points I'm not fully decided yet (this is a v0.1 after all). Interaction with channels are on the roadmap, and concurrency can be done in the Go host to run different execution contexts.
We concluded, however, that the best option would be to write a Go interpreter (in Go of course). One of the key reasons why is to maintain full compatibility with Goroutines and channels.
I never got started on that project though... too many others need finishing. Bravo on publishing your vision!
Otto (JavaScript interpreter): https://github.com/robertkrimen/otto
Twik (Scheme like): http://blog.labix.org/2013/07/16/twik-a-tiny-language-for-go
1. fmt.Printf("%f", 1.0 / -0.0);
2. x := -0.0; fmt.Printf("%f", 1.0 / x);
3. x := 0.0; fmt.Printf("%f", 1.0 / -x);