How Go improves expressiveness without sacrificing performance

http://dave.cheney.net/how-the-go-compiler-improves-expressiveness-w

by luriel • 14 years ago

49 17 14 years ago

dave.cheney.net

k4st• 14 years ago

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.

dhconnelly3• 14 years ago

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)

bluesnowmonkey• 14 years ago

Can the optimizer not eliminate the redundant bounds checks in the "good idiomatic" version?

alec• 14 years ago

Check the first comment in the article - I can't believe that is actually good and idiomatic. The author uses the indexes, but the range command also supports returning the values.

To be fair, I have a lot of difficulty figuring out what's a reference and what's a value in Go; I suspect if it were an int and not a struct, that wouldn't work.

dhconnelly3• 14 years ago

Only slices, maps, and channels are reference types.

halayli3• 14 years ago

Go syntax makes me cringe. example:

> for i := range e {

> var e = make([]E, 1000)

It's confusing and against mainstream conventions for no good reason.

luriel2• 14 years ago

What is confusing there and/or against "mainstream conventions" (whatever those are)?

halayli3• 14 years ago

If you don't know Go and you look at this 'make([]E, 1000)'. What does it tell you? How about this 'make(map[string]int) or make(chan int) ?'

for i := range e {

Why bring back := from pascal family and steer away from common conventions? Why range doesn't take parenthesis while make does?

Also trying to mix dynamic + static type languages will add to the confusion. Deference pointers in a language that looks dynamic but acts static is not mainstream.

tcard• 14 years ago

That's a common thought from anybody who first looks at Go code. But when you play around a little you realise that all these sharp syntax constructions happen to increase pragmatism, they are well-thought to make the coder happy.

I think that Go syntax falls into something like an uncanny valley —so similar to C-like languages that you instinctively compare it to them but just so different that it feels weird at first. But you'll love it.

dhconnelly3• 14 years ago

I find that most programming languages have confusing syntax that go against mainstream conventions for seemingly no reason. As might be expected from Bell Labs alumni, most of Go's design decisions have good reasons.

shadowmint• 14 years ago

Worth a read, if you find go's syntax confusing: http://blog.golang.org/2010/07/gos-declaration-syntax.html

However, its true, I also don't like the :=, or []type syntax purely for aesthetic reasons, but I can see at least the reasoning for it.

As the article points out, the * syntax is oddly non-uniform which it kind of inherits from c. So it's a mixed bag.

Overall though, I find the syntax is less of a problem when you have a big block of go code and you can see it all working together.

It's when you get these little fragments that it looks a bit odd, compared with what you might be use to.

thebigshane• 14 years ago

Can anyone explain why BenchmarkUnroll was specifically set to run twice as many iterations as the other two for the timing tests? It seems intentional. But why? Is there some overhead in having the compiler unroll the code versus manually that required more iterations to "even out"?

   BenchmarkUpdate 500000 2996 ns/op
   BenchmarkManual 500000 4642 ns/op
   BenchmarkUnroll 1000000 2824 ns/op

How Go improves expressiveness without sacrificing performance

Related Stories