- No generics.
- No exceptions.
- No inheritance.
- Nullable pointers.
- No decimal types (yet they put in complex!)
- No IDE.
- No support for GUI applications on Microsoft Windows.
- Go ignores years of academic research on language design.
Please ignore the people who are happily productive with the language :).
Go does have exceptions under a different name called "panic". It's named differently to communicate why they were added to the language (read docs for details) and their expected use-case.
Go does have a variation of inheritance called embedding. Using embedding you inherit all methods and fields of the former type but that does not provide is-subclass relation between types. In order to have abstract-class-like behavior one would use interfaces.
---
At the moment Go is mostly useful for creating lean network services. "net" package from standard library is really good. Goroutines are scheduled with the respect to system calls so all your code is effectively async without any jumps and hoops (no callbacks!).
There are few packages in other areas (gui) but that's not the fault of the language. You're welcome to write new ones or wrap existing C libraries (and that's really easy in Go).
Go also has generics, they just are not available to lowly peons writing new Go types.
(I will avoid any attempt at humor in future posts on this site.)
- Forcing one brace style - Forcing naming conventions to a certain extent - To use the Go tool you are required to have your directories set up in a specific way - All types are not equal: No support for using user defined types as map keys, maps are generic, but user defined types are not - Two initialization functions, new and make. One returns a pointer, the other a struct. Seeing as go makes no distinction between the stack and the heap, is there need for two.
Convention over configuration is great and all, but it really felt as if it was being used as an excuse to force me to use someone else's style. Even python which catches flak for forcing indentation as tabs let's you choose the indentation depth and character. Go made me feel slightly violated; forcing my directory layout was the last straw, and the lack of any configuration in a place where it would not be complex to add it seamed stupid.
Go's CapitalEverythingNaming convention is quite annoying but the mere fact that it'll be used everywhere makes me happy.
- I find that having a common style about source files from different origins (we're in the open source era) and common naming conventions are great for the readability. I can decipher foreign code much easier if I don't have to set my mind about the bracing style. And seriously, would you prefer to have "private" and "public" all in the place instead of this simple convention ?
- I found it a little painful too, at first, to have to mix source and binary in my projects with the advent of the go tool but the removal of redundant makefiles and its simplicity of use, especially when you deal with a lot of projects and packages from diverse origins is so great that it's hard to protest against that.
- Are you sure you're up to date about map keys ? http://tip.golang.org/ref/spec#Map_types
You can use any indentation depth in Go too. But in Python you can't get rid of indentation because its lexer expects it, just like you can't get rid of the "forced" brace style in Go, because its lexer expects it.
This has been discussed numerous times on the mailing list. The answer, for good reasons, is too bad. As you note in your conclusion, consistency is prioritized above configuration.
There's reasons for this, they were meticulously debated and chose by the designers to help people out. If you have a pure Go project, you can install it anywhere Go is available in a single command. No autotools, no makefiles, no build-essentials, nothing. Just a single `go get` command.
If you ever work on a decent sized project in Go, you will quickly come to appreciate the enforced consistency across the project.
>To use the Go tool you are required to have your directories set up in a specific way
Not with the binary distribution. And "have a source directory on GoPath" is too restrictive... set `GOPATH=~` and for 90%+ of users, their existing dir structure is perfectly fine.
>No support for using user defined types as map keys
This is no longer true IIRC.
>Two initialization functions, new and make. One returns a pointer, the other a struct.
I don't understand why this is a negative?
As for D, I simply need to give it another go, pardon the choice of words.