> easy to follow/reason about in a functional language Go is explicitly not functional. Many builtin functions mutate (look at Sort for an example). There's no

> easy to follow/reason about in a functional language Go is explicitly not functional. Many builtin functions mutate (look at Sort for an example). There's no map. https://groups.google.com/forum/#!topic/golang-nuts/RKymTuSCHS0 https://groups.google.com/forum/#!topic/golang-nuts/RKymTuSC... Functions are only almost first-class. For example... http://play.golang.org/p/WB133vrGKD http://play.golang.org/p/WB133vrGKD Go does have powerful constructs, but to call it "functional" is maligned. I would also argue that it's not always easy to reason about and follow. The reason we build abstractions, which Java allows perfectly, is so that we can ignore the hidden complexity and reason about code more easily. Go explicitly makes it difficult to hide underlying complexity. If I want to make, for example, a Bimap (which Java has many clean implementations of) I get to pick from two poisons in Go: Either I must force everyone who uses it to type-cast on every get (implement the bimap via taking and returning interface{}), or I must surface the implementation details (two maps) and have users directly manipulate those since the builtin uni-directional map is a type-safe generic data-structure which I can't replicate in the language itself. This might look appealing at first, but since I also need to do some Locking my interface for allowing people to manipulate those maps directly rapidly becomes troublesome. Neither of those choices sound appealing to me. Honestly, if you want to avoid java now you have a plethora of options. You can develop for android with Scala and get basically first-class support. You can develop for android via webview+html+js and use something like http://ocsigen.org/js_of_ocaml/ http://ocsigen.org/js_of_ocaml/ to write OCaml and have a wonderful actually functional language. You can wait for Rust to have some android bindings implemented and use a wonderful language that allows powerful features like macros that are excellent for interface-building. I don't mean to bash on Go since it does have a place somewhere, I just feel that it is not the correct language for something UI heavy nor anywhere that suitably complex abstractions and complexity-hiding are a necessity.