Comparing Go with Lua

Re:Comparing Go with Lua by masklinn on Friday September 09, 2011 @08:50AM (#2977896)

> But the big similarity is this: functions can return more than one value. This is quite distinct from returning tuples, as Python does and is very much more efficient. (Bruce Eckel errs in speaking of tuples in Go) So the following style is common: a function returning a value plus an optional error:

I have trouble with this assertion: as far as I can tell, nothing would stop a language (especially a statically typed one) from optimizing a tuple return/unpack into a cheaper parallel assignment, and still provide a full-blown tuple type. I might be wrong, but is tuples unpacking not a strict superset of Go/Lua's restricted multiple return values?

(this is not possible in Python, because Python really unpacks arbitrary iterables, and Python 3 introduces ruby-style unpacking slices, so you can't apply such an optimization unless you can infer the exact return type of the callee)

Multiple return values is not intrinsically more efficient than tuples unpacking, it's just foisting an optimization onto the language user (by arbitrarily limiting his options in this case).

Even the following pattern of unpacking into a function arguments can trivially be handled via tuples unpacking (by making them explicit, which counts as a positive as far as I'm concerned)

> Go and Lua provide mechanisms for protected calls which are similar in spirit. Something bad will happen in a function, and the idea is to prevent that badness from bringing down the process.

a.k.a. exception handlers by any other name.

> The strength of the Go approach is that there is an explicit mechanism for calling arbitrary code when a function stack frame goes out of scope. With Lua (as with most garbage-collected languages) the best you can do is define finalizers on objects and wait for the garbage collector to call them (eventually.)

Right, because there's no such thing as `BlockClosure#ensure:`, `unwind-protect`, `using()` or `with:`.

> The difference is that with Go you have to use an underscore if you want to ignore the value (it is very strict about unused variables)

The issue with a bare `_` is that it has limited readability. Sometimes, you want to say "This is that, but I don't care for it". Erlang lets you do that by `_` being used as a prefix as well as a wildcard (technically I believe it introduces bindings, but more interestingly it makes the compiler not warn about unused bindings). It is very useful for bit positional matches of which half are thrown out.

> Note also the similar for-iterator syntax which naturally flows out of multiple return values.

Which you can just as easily get from tuples unpacking, of course.

> Lua's multiple returns came from CLU according to The Evolution of Lua. It is interesting how long it can take for new programming language concepts to reach the mainstream.

About 17 years[0] is not that much, and that's only if you discount pattern-matched functional languages[1].

[0] http://docs.python.org/reference/simple_stmts.html#assignmen...

[1] http://en.wikipedia.org/wiki/ML_(programming_language)

[ Parent | on HN ]

Re:Comparing Go with Lua by pcwalton on Friday September 09, 2011 @11:57AM (#2978580)

"I have trouble with this assertion: as far as I can tell, nothing would stop a language (especially a statically typed one) from optimizing a tuple return/unpack into a cheaper parallel assignment, and still provide a full-blown tuple type. I might be wrong, but is tuples unpacking not a strict superset of Go/Lua's restricted multiple return values?"

Well, it depends on how you implement polymorphic code, but generally yes. This is why we use tuples instead of multiple return values in Rust. In fact, if you return a struct by value in LLVM, LLVM will allocate a virtual register for each element.

[ Parent | on HN ]