Hacker News Reader

Comment by tptacek | Hacker News Reader

x = append(x, foo) is a common C idiom too; in fact, it's been awhile since I had to work with STL containers, but I think it was common there too.

I love Golang namespacing rules. They do exactly what I need them to do to allow me to call into other people's code using the right function calls, and nothing else. I think Golang's namespacing is a high point of the language.

View on HN

> x = append(x, foo) is a common C idiom too; in fact, it's been awhile since I had to work with STL containers, but I think it was common there too.

No, vector::insert() is the common idiom and mutates in place. It'd be written `x.insert(x.end(), foo.begin(), foo.end());` For single elements, vector::push_back() is the common idiom, and also mutates in place.

Hrm. I've written about 100kloc of C++ code, around ~1999-2000. I'm going to have to go figure out why I thought this was the case.

vector::insert() is certainly not a C idiom. In can never be a C idiom because that is C++ code. the x = append(x, foo) idiom can be seen all over C, most obviously with the use of realloc, which is often called to resize an array via x = realloc(x, newsize).

Indeed. Which is why pcwalton is answering Thomas' conjecture about C++'s STL containers.

I don't think simply having a separate symbol table for packages and a separate one for types and variables would hurt much, and I hate writing things like aList := list.New(). Having said this, I know many of those things are purported to have such and such super important reasons, it doesn't change the ugly "feel" of the end result. Another instance is the indication of visibility by case, they will go on and on about how it's a triumph of simplicity, I think it's simply an ugly notation.

I honestly am not sure I follow what your concern is with that line of code. list.New() looks extremely clean to me.

You frequently have packages that are named after generic nouns, like time, host, file etc. There are many contexts where this same generic name makes for the best variable name: clear, short, and easy to type:

  func ReadFile(filename String) {
    file := file.Open(filename)
  }

In Go you have to invent a new name, so invariably you will see a lot of:

  theFile := file.Open(filename)
  aFile := file.Open(filename)
  readFile := file.Open(filename)

depending on who wrote the code.

Unless you're also frustrated by not being able to write `int int = 3` in C/C++/C#/Java/most other languages, I don't see the point of your concern.

    f = file.open("a.txt")
    out_file = file.open("b.txt", file.WRITE)

You can write that in C though.

    typedef int foo;

    foo main() {
        foo foo = 0;
        return foo;
    }

You can do the same thing in Golang by renaming the import that clashes with your preferred variable name. Nobody does it, though, because it's not worth the trouble.

In the C# language we refer to this as the 'Color Color problem'. You have some enum or type Color and then a member of an object which you, quite obviously, want to name 'Color'. It's so annoying for the programmer to work around this that we define special exceptions in naming rules so the programmer can do what they want.

the only place where I constantly find this annoying is the url package. url := oh wait, shit, already imported that.

a couple of times I just changed the name of the import, as you sometimes do in Python:

import (

  urllib "net/url"

)

url := urllib.QueryEscape(...)

tada!

I've hit this a few times in Python and it bugged me like crazy. But then I grew up and dealt with it.

> I think Golang's namespacing is a high point of the language.

Really?!? Available in modular languages since Mesa days (mid 70's).

Reply on news.ycombinator.com