Comment by simiones | Hacker News Reader

Comment by simiones | Hacker News Reader

Parent Full thread

Of course Go has hidden behaviors and overly complex syntax, like any programming language before or after.

For example:

  xrefs := []*struct{field1 int}{}
  for i := range longArrayName {
    longArrayName[i].field = value
    xrefs = append(xrefs, &longArrayName[i])
  }

Perfectly fine code. Now after a simple refactor:

  xrefs := []*struct{field1 int}{}
  for _,x := range longArrayName {
    x.field = value
    xrefs = append(xrefs, &x)
  }

Much better looking! But also completely wrong now, unfortunately. `defer` is also likely to cause similar problems with refactoring, given its scope-breaking function border.

And Go also has several ways of doing most things. Sure, C# has more, but as long as there is more than one the problems are similar.

And I'm sure in time Go will develop more ways of doing things, because the advantage of having a clean way to put your intent into code usually trumps the disadvantage of having to learn another abstraction. This is still part of Go's philosophy, even though Go's designers have valued it slightly less than others. If it weren't, they wouldn't have added Channels to the language, as they are trivial to implement using mutexes, which are strictly more powerful.

I don't think this is a good example of proving the point that Go is difficult to read. Isn't it expected to internalize the semantics of basic language primitives when learning a new language, or does people just jump in guessing what different language constructs do? IMHO you learn this the first week when reading up on the language features.

range returns index and elements by value. The last example does what you asks of it, it's like complaining something is not returned by reference when it's not. Your mistake. Perhaps some linter could give warnings for it.

I don't think you can truly internalize the varying semantics of which operations return lvalues and which return rvalues. At least, I haven't yet been able to in ~2 years of Go programming, and it's a constant source of bugs when it comes up.

The lack of any kind of syntactic difference between vastly different semantic operations is at the very least a major impediment to readability. After all, lvalues vs rvalues are one of the biggest complexities of C's semantics, and they have been transplanted as-is into Go.

As a much more minor gripe, I'd also argue that the choice of making the iteration variable a copy of the array/slice value instead of a reference to it is the least useful choice. I expect it has been done because of the choice to make map access be an rvalue unlike array access which is an lvalue, which in turn would have given different semantics to slice iteration vs map iteration. Why they chose to have different semantics for map access vs array access, but to have the same semantics for map iteration vs array iteration is also a question I have no answer to.

> and they have been transplanted as-is into Go

Hum... I don't think anything can return an lvalue in C.

Your first paragraph is not a huge concern when programming in C, declarations create lvalues, and that's it. I imagine you are thinking about C++, and yes, it's a constant source of problems there... So, Go made the concept much more complex than on the source.

I think Go has exactly C's semantics here. The following is valid syntax with the same semantics in both:

  array[i] = 9
  *pointer = 9
  array[i].fieldName = 9
  (*pointer).fieldName = 9
  structValue.fieldName = 9  
  pointer->fieldName = 9 // Go equivalent: pointer.fieldName = 9

  // you can also create a pointer to any of these lvalues
  // in either language with &

Go has some additional syntax in map[key], but that behaves more strangely (it's an lvalue in that you can assign to it - map[key] = value - but you can't create a pointer to it - &(map[key]) is invalid syntax).

> I don't think anything can return an lvalue in C.

Btw, I was curious to check , here is an example of a function returning an lvalue:

  struct test {
    int a;
  } global;

  struct test* foo() {
    return &global;
  }

  int main (int argc, char**argv) {
    printf("%d", global.a); //wil print 0

    foo()->a = 9;
    //or (*(foo())).a = 9;

    printf("%d", global.a); //will print 9
  }

I think this is actually a very good example of the inverse relationship between logical complexity and language complexity.

A language that has implicit copy/move semantics is easier to write (since it's less constrained), and more difficult to read (since in order to understand the code, one needs to know the rules).

A language that has explicit copy/move semantics, is more difficult to write (since the rules will need to be adhered to), but easier to read (because the constraints are explicit).

Although I don't program in Golang, another example that pops into my mind is that slices may refer to old versions of an array. This makes working with arrays easier when writing (as in "typing"), but more difficult when reading (as in understanding/designing), because one needs to track an array references (slices). (correct me if I'm wrong on this).

In this perspective, I do think that a language that is simpler to write can be more difficult to read, and this is one (two) case where this principle applies.

(note that I don't imply with that one philosophy is inherently better than the other)

EDIT: added slices case.

What exactly is the difference here? Is the `x` variable being updated in the second sample so that the stored references all point to the same item?

Yes, that code is equivalent to

  xrefs := []*struct{field1 int}{}
  var x struct{field1 int}
  for i := range longArrayName {
    x = longArrayName[i] //overwrite x with the copy
    x.field = value //modify the copy in x
    xrefs = append(xrefs, &x) //&x has the same value regardless of i
  }

The desired refactoring would have been to this:

  xrefs := []*struct{field1 int}{}
  for i := range longArrayName {
    x := &longArrayName[i] //this also declares x to be a *struct{field1 int}
    x.field = value
    xrefs = append(xrefs, x)
  }

Reply on news.ycombinator.com