2) go has generic types : slices, maps, and channels, all of which have slightly differing behaviour, including some highly counter intuitive and contradictory behaviour (example: slices are pass-by-reference, arrays are pass-by-value. In other words []int and [5]int behave entirely differently)
4) go has exceptions (panic/recover), negating all the advantages of Go error checking, and providing zero fixes for the problems it introduces (finding the source line where an error happened and if/how multiple errors are related. Easy in Java/C++/..., hard in Go) (in C++ you have to be aware of whether any external code you use throws exceptions ... in Go you have to be aware if any external code you use panics. And if you say I haven't dealt with it, that means that you quite literally haven't dealt with it. Same as in C++. External libraries throwing exceptions is perfectly fine ... as long as they never actually throw an exception. Panicing standard library is fine ... as long as it doesn't panic ... If you're looking for correct code, it is of course not fine)
5) Go's "simple" threading and panics. Try crashing a Go program with shared data with a null-pointer derefence in the shared data. Someone please explain to me how the resulting output is simple.
6) golang's own compiler and standard library are not in fact idiomatic Go. This goes from small problems (like total lack of unit tests in quite a few places), to larger ones, like not using interfaces for logging.
7) interface{}. I just grepped a reasonable, thoroughly reviewed codebase I've written, of several tens of thousands lines of Go. Result: 2.7 uses of interface{} per 1000 lines of code.
Is this what people here call simple to think about code ? I would argue that you don't understand a codebase until you've read it. That's a certainty. So can we at least agree there's a point where verbosity no longer increases readability ? I hope you can see Go is far past that point.
Go's type system : riddled with exceptional behaviour. Literally it says "type system applies unless it's doing <-, cap, len, copy, new, append or delete calls", in which case we do something custom. The resulting behaviour, of course, is inconsistent with Go's type system (which is really the point of the code of course, unfortunately, there's surprises buried in there, and those calls are inconsistent with eachother as well).
All of these are implemented as exceptions in the compiler. I would warn you about this link : once it is seen, it cannot be unseen :
The irritating part is that this sums up Go mailinglist behaviour quite well. Coding practices is for you, not for us, the Go authors. Generics ? Of course we need that, but you obviously don't as you're a bad programmer. And if you're asking for something else that must mean you suck. Overloading ? Ditto. Generic types ? Yes for us, not for you though !
Of course, all of these claims are thrown around and when you actually read the compiler code you wonder ... do these guys know about type systems ? Don't these guys know about the standard coloring algorithm ? Why aren't they using extremely-well-known algorithm X for this ?
In other words, it really looks like the compiler was (and is) written by someone who last opened a compiler book in the 70s. But reading the mailinglist, you'd think they were the central authority on compiler theory and you're stupid. This is in fact not the case.
Go works and feels like a late-90s language like Oberon. Clean at the surface, with lots of buried ugliness. Lots of weird custom datatypes, forms and parts of the standard library that are not implemented in the language itself. It's why I switched to C/C++. Go is simply the same as those old languages we moved away from. There is nothing in Go that cannot be achieved better and more flexible in C++, D and Rust.
1) go has generic functions : http://golang.org/pkg/builtin/, they're just not accessible to you
2) go has generic types : slices, maps, and channels, all of which have slightly differing behaviour, including some highly counter intuitive and contradictory behaviour (example: slices are pass-by-reference, arrays are pass-by-value. In other words []int and [5]int behave entirely differently)
3) go has overloaded functions : http://golang.org/pkg/builtin/, they're just not accessible to you
4) go has exceptions (panic/recover), negating all the advantages of Go error checking, and providing zero fixes for the problems it introduces (finding the source line where an error happened and if/how multiple errors are related. Easy in Java/C++/..., hard in Go) (in C++ you have to be aware of whether any external code you use throws exceptions ... in Go you have to be aware if any external code you use panics. And if you say I haven't dealt with it, that means that you quite literally haven't dealt with it. Same as in C++. External libraries throwing exceptions is perfectly fine ... as long as they never actually throw an exception. Panicing standard library is fine ... as long as it doesn't panic ... If you're looking for correct code, it is of course not fine)
5) Go's "simple" threading and panics. Try crashing a Go program with shared data with a null-pointer derefence in the shared data. Someone please explain to me how the resulting output is simple.
6) golang's own compiler and standard library are not in fact idiomatic Go. This goes from small problems (like total lack of unit tests in quite a few places), to larger ones, like not using interfaces for logging.
7) interface{}. I just grepped a reasonable, thoroughly reviewed codebase I've written, of several tens of thousands lines of Go. Result: 2.7 uses of interface{} per 1000 lines of code.
Is this what people here call simple to think about code ? I would argue that you don't understand a codebase until you've read it. That's a certainty. So can we at least agree there's a point where verbosity no longer increases readability ? I hope you can see Go is far past that point.
Go's type system : riddled with exceptional behaviour. Literally it says "type system applies unless it's doing <-, cap, len, copy, new, append or delete calls", in which case we do something custom. The resulting behaviour, of course, is inconsistent with Go's type system (which is really the point of the code of course, unfortunately, there's surprises buried in there, and those calls are inconsistent with eachother as well).
All of these are implemented as exceptions in the compiler. I would warn you about this link : once it is seen, it cannot be unseen :
https://github.com/golang/go/blob/master/src/cmd/internal/gc...
The irritating part is that this sums up Go mailinglist behaviour quite well. Coding practices is for you, not for us, the Go authors. Generics ? Of course we need that, but you obviously don't as you're a bad programmer. And if you're asking for something else that must mean you suck. Overloading ? Ditto. Generic types ? Yes for us, not for you though !
Of course, all of these claims are thrown around and when you actually read the compiler code you wonder ... do these guys know about type systems ? Don't these guys know about the standard coloring algorithm ? Why aren't they using extremely-well-known algorithm X for this ?
In other words, it really looks like the compiler was (and is) written by someone who last opened a compiler book in the 70s. But reading the mailinglist, you'd think they were the central authority on compiler theory and you're stupid. This is in fact not the case.
Go works and feels like a late-90s language like Oberon. Clean at the surface, with lots of buried ugliness. Lots of weird custom datatypes, forms and parts of the standard library that are not implemented in the language itself. It's why I switched to C/C++. Go is simply the same as those old languages we moved away from. There is nothing in Go that cannot be achieved better and more flexible in C++, D and Rust.