4 ms·
There is something to your description. I use Go sometimes, for pragmatic reasons, when I need more performance than I can get from Python or Ruby, but boy is i
by stiff 12y ago
There is something to your description. I use Go sometimes, for pragmatic reasons, when I need more performance than I can get from Python or Ruby, but boy is it a ugly language!
There are just tens of little ugly things Go does and the result is, well, even uglier. Writing four functions for every collection to be sorted, writing x = append(x, foo) everywhere, shitty namespacing that prevents you from writing list := list.New() and so on and so forth. Even C is more elegant, and I would probably prefer to use C, if only C came with a library manager like rubygems or go get and a decent repository of libraries. I would even prefer Java if it produced native binaries and had an integrated library manager.
- tptacek 12y agox = 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.
- pcwalton 12y ago> 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.
- tptacek 12y agoHrm. 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.
- webkike 12y agovector::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).
- mjdwitt 12y agoIndeed. Which is why pcwalton is answering Thomas' conjecture about C++'s STL containers.
- stiff 12y agoI 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.
- tptacek 12y agoI honestly am not sure I follow what your concern is with that line of code. list.New() looks extremely clean to me.
- stiff 12y agoYou 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.
- tomp 12y agoUnless 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)
- pcwalton 12y agoYou can write that in C though. typedef int foo; foo main() { foo foo = 0; return foo; }
- 12y ago
- pjmlp 12y ago> I think Golang's namespacing is a high point of the language. Really?!? Available in modular languages since Mesa days (mid 70's).