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.
The Lisp machine emulator for x86-64 that runs Genera is easy to setup if you care to google around. The current owner of Symbolics displayed interest in open-sourcing Genera a few years ago but nothing happened since then.
The wrong people have been drunkenly driving Emacs into the ditch for the past decade or so, and they're really screwed it up in so many ways, usually trying to be way too clever and solve problems that really aren't worth solving.
They made "line-move-visual" the default, which in the service of making Emacs behave more like Microsoft Word, it makes ^N and ^P across wrapped lines stay on the same line and move to the part of the same line that is wrapped above or below the cursor, totally breaking type-ahead predictability and keyboard macros. That totally pissed of the late and long time Emacs user Marc Crispin, and he explains why it's such a terrible idea that breaks keyboard macros: http://compgroups.net/comp.emacs/line-move-visual/274792
It totally breaks keyboard macros, one of the most important things about Emacs. It definitely should not have been made the default, since keyboard macros are a way of life for real emacs hackers. I totally agree with Marc's take on the problem, and I am terribly disappointed that RMS let somebody get away with changing it that way, and making that horrible mode the default.
They just can't stop trying to make it more like Microsoft Word, while failing to actually achieve that goal, and only succeeding in inflicting half-assed solutions with harmful unpredictable side-effects on the users.
Another example is how the region highlighting and the weird pending delete behavior terrorizes me that sometimes but not all the time according to rules I just can't figure out or tell by looking at the screen, when I type something that I intend to insert, a huge chunk of my buffer might just disappear, but sometimes it doesn't. So now Emacs has become unpredictable and malicious. I have to do a dance of "insert character, undo" to know that I have canceled the pending delete mode. You can't tell if you are in pending delete mode just by looking at the screen and seeing the obnoxious highlighting, because sometimes it highlights the region and isn't in pending delete mode, and sometimes it highlights the region and is in pending delete mode. I just wish it would stop highlighting the region, because any time I set a mark and move around, it highlights half of the screen at no use to me, and that just gives me a headache, and I have to insert a character an undo it to cancel the highlighting, and until I cancel the highlighting I am living in terror that my next keystroke will delete a huge unseen portion of the buffer.
And the thing that REALLY pisses me off is the lame-assed attempt to make ^A and ^E ignore the prompt in shell mode. There is an extremely simple reliable solution to the problem of separating the prompt from your input in shell mode so you can always get to the beginning of the line with ^A, and that is to have a newline at the end of your prompt, so every line you type in is on the whole line and does not have a prompt prefix, therefore no half-assed magic is necessary.
But the half-asses magic is terribly implemented and has bizarre side-effects that screw me all the time: I get these fucking invisible force fields inserted into the line between my characters whenever I yank some text onto the line that has a prompt or a command line on it, and I can't move past them with ^A or ^E (but sometimes I can -- they're not predictable which is even worse)! And I can get any number of these fucking invisible force fields on my line, so in order to get to the beginning of the line I have to go ^A, look at the screen to see if I made it, type ^B ^A if I didn't, again and again, until I drill past all the invisible force fields that are trying to make my day happier.
And then I have to mark the beginning of the line I want to edit and repeat, go to the end of line by drilling back some number of opposite facing invisible force fields (which may be in different places than the ones going the other direction), and then kill the region, go to the end of the buffer, then yank the entire line to get a copy of it without any fucking invisible force fields in it.
But if there is an invisible force field in the line, or I just want to edit a few characters of the line and that adds some invisible force fields that were not even there before, and then I hit return in the vain hope of re-entering the entire line but not the prompt, it just enters the tail of the line after the last invisible force field, making an error in the shell, or sometimes even executing a totally different command than I intended and totally fucking me over.
I would really like somebody to explain what the fuck the idea behind the invisible force fields are, and give me the address of whoever thought is was such a brilliant idea, so I can send a robot drone to firebomb their house, or worse yet send RMS to live with them for a few months. Why did they do something so terrible, that totally fucks up such common important operations, to solve a trivial problem that has a much better solution?
Emacs used to be totally predictable. I learned it at 300 baud over the ARPANET on ITS, and I could type ahead hundreds of characters to do all kinds of stuff, and then go take a piss or get a drink or take a bong hit, and come back later, and it would be in exactly the state I meant for it to end up in. Now, I can't do that even on a local display. And for some fucking reason, it waits for up to five seconds sometime before updating the display when I'm running it in a terminal (especially when I start an incremental search or query replace). What the fuck is that about??! Not only is it totally unpredictable and forces me to stop what I'm doing and wait for it to catch up so I can figure out what state it guessed its way into before going on, but it won't paint the screen for five seconds when running on a modern top-of-the-line computer!
Emacs has become a shrine to outrageous violations of the principle of least astonishment. I just can't figure out how they could have come up with so many ways to corrupt it, when it used to work so well. It's totally unpredictable now, and I can't type ahead any more, so I have to type a few characters, look at the screen to see how it misinterpreted my intentions, and then try to work around the misunderstanding.
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.