

How Go improves expressiveness without sacrificing performance - luriel
http://dave.cheney.net/how-the-go-compiler-improves-expressiveness-w

======
k4st
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.

~~~
dhconnelly
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)

------
thebigshane
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

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

~~~
alec
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.

~~~
dhconnelly
Only slices, maps, and channels are reference types.

------
halayli
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.

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

~~~
halayli
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.

~~~
luriel
Do you know what := does in Go? What "common conventions" provide the same
concise expressiveness?

As for your complain about make(), what does it have to do with syntax?

Why doesn't range require parens? Among other things because it has no need
for them, while make() clearly does need them.

~~~
halayli
> Do you know what := does in Go? What "common conventions" provide the same
> concise expressiveness?

I know what := means because I have a Pascal background, most programmers are
used to = as being the assignment operator. But the mere fact that you asked
me what ":=" means proves my point. It's not common and you don't expect
everyone to know it.

Why range doesn't require parenthesis? It takes parameters just like make
does.

~~~
enneff
"I know what := means because I have a Pascal background"

But it's not the same: in Pascal := means assignment, whereas in Go it means
variable declaration. Go uses = for assignment, as is the popular convention.

You must learn new things when you learn a new programming language. People
should stop being surprised and/or upset by this. Besides, Go's syntax is not
all that shocking or unusual, especially compared to Scala, Erlang, or
Haskell. I regularly switch between Go, JavaScript, C, and Python and don't
have any trouble adjusting.

"Why range doesn't require parenthesis? It takes parameters just like make
does."

Range is a keyword, while make is a function. Range is used with a single
value (the map, slice, or channel being ranged over), while make may take up
to three arguments.

Please - it is really silly to critique the syntax of a language if you don't
know the language.

