3 ms·

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

• stcredzero 13y ago
  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.
• vertex-four 13y ago
  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).
• PuerkitoBio 13y ago
  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.