| The error handling was a disappointment at first, but in practice it is a lot clearer and more usable than any other kinds of error handling I've tried. It could perhaps do with some syntactic sugar, but it isn't a big issue since IDEs can pick up that slack. After about half a decade of Go I'd say that the error handling is something I've come to like. "More expressive" in my opinion tends to mean "less readable", but there is some personal bias here. The people I've met during my career who like "more stuff" are usually the younger, less experienced programmers who aren't as concerned about long term viability. I'm in my fifth decade of programming and my approach is "do more with less". When people want more stuff, for me, it means that I'll be dealing with more cases of people not knowing how all the stuff works. Everyone likes to think they can deal with more cognitive overhead, but mostly people can't. I'm not sure if pattern matching belongs in a language like Go at all. Admittedly I haven't given it much thought, but it doesn't feel right for what Go aims to be. If you want to do Erlang, do Erlang, but I might be wrong about this. What's error prone about the for statement? I don't use the C-style for statement all that often as way more than 50% of my for loops are ranging or naked for loops with break/continue/return. Not having nil tends to lead to having to invent sentinel values all over the place, doesn't it? Is that really better? And since you often end up doing things by value in Go anyway, it isn't like you don't have any choice. |