How Go improves expressiveness without sacrificing performance

Re:How Go improves expressiveness without sacrificing perfor... by k4st on Saturday February 11, 2012 @06:34PM (#3580504)

I am not convinced that this has anything to do with Go improving expressiveness. If anything, this seems more like whichever Go compiler is being used is not doing common subexpression elimination, and that is forcing the developer to re-invent a 'map' that returns nothing but mutates the list in place, albeit in an unusual way.

What are these "improvements" in expressiveness being compared to? Certainly not C or C++, as the initial problem isn't an issue, and the proposed solution is possible.

[ Parent | on HN ]

Re:How Go improves expressiveness without sacrificing perfor... by dhconnelly on Saturday February 11, 2012 @07:08PM (#3580581)

I think the improvement in expressiveness here is in not having to do &E before calling the method that has receiver type * E. That is, (&E[i]).update(1, 2, 3, 4) and E[i].update(1, 2, 3, 4) do the same thing, so he was able to eliminate writing &E[i].

Also, if the method was defined with receiver type E, and you have a variable x of type * E, you can also do x.update instead of (*x).update. Go automatically dereferences.

(edited: my asterisk operators made everything italicized)

[ Parent | on HN ]