16 ms·
How Go improves expressiveness without sacrificing performance
- k4st 15y agoI 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 15y agoI 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 15y agoCan the optimizer not eliminate the redundant bounds checks in the "good idiomatic" version?
- alec 15y agoCheck 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 15y agoOnly slices, maps, and channels are reference types.
- halayli 15y agoGo 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 15y agoWhat is confusing there and/or against "mainstream conventions" (whatever those are)?
- halayli 15y agoIf 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.
- freakinjoe 15y agocode something useful in Go then do tell us your opinion rather than baseless rant.
- luriel 15y agoDo 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 15y ago> 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.
- deleted 15y ago[deleted]
- thebigshane 15y agoCan 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