Mark, Some considerations that may be unclear when approaching Go and considering anything familiar from other languages that is not in Go...
MAKING DECISIONS Go's designers are experienced. with central roles in UNIX, C, GCC, Modula, etc., and also across teams of various scales and diversities, from small-all PhD Bell Labs teams to big more normally distributed background teams in large companies. They all ended up at Google and saw the "horror" of programming as usual at huge scale: many hour builds even with 10k CPUs, long latent bugs despite testing and review regimentation, etc. The result was a project to design a language and build approach that makes it hard to abuse, stumble, or fail in precisely the ways that teams commonly suffer problems. This is a little bit downplayed in the conversations, but statements like "complex ternary expressions can be confusing" really mean "we documented 18,327 cases of major bugs caused by misunderstood nested ternaries." (This would also correspond to "we documented 9M cases of bugs caused by misunderstood default casts in C++ with generics and overloaded operators." 😃) These kinds of awarenesses lead to a "defensive programming" mindset about casting, pointer math, increment as expression rather than operator, and most everything that can sometimes make the Go team seem arbitrary. What is not clear in this is that they miss these things too. Ken Thompson had the idea for the ternary operator. It makes sense to him. His (odd but logical) way of indenting if clauses and ternaries made it safe for him. But "good for Turing-award winner Ken" is not the test for professional team programming at scale. So when you hear these data-driven, career experience based arguments for/against approaches know that it is not personal, it is an analytic decision based on data. The goal of those decisions was to make whole teams more productive, and millions of Go users seem to bear these ideas out pretty well. You can see this play out in discussions of "what should be different in Go2?" Not much seems to be suggested, at least compared to each rev of C++. MANAGING PAIN Many new Go users complain about the verbosity of error handling. They feel pain. It is often stated as "it was easier and prettier when it was magic because of exceptions." The answer is always "embrace it. it is good for you to be explicit about possible errors. it gives you a place to do something smart rather than just fail. it is good for those who read your code to know what can go wrong. it is good for people who use your code to know what errors you can possibly have." This may leave the new user doubtful, but nearly all who give it time come to see it as good advice. I'm not sure that the deeper point comes across as clearly as possible: the actual pain is probably not what you think it is. As a developer, you might think the effort/cost/pain is "how long to type it and get it to build and pass tests." But in truth, in teams, at scale, the real pain is 10000 people who read your API, 1000 people who read your code, 100 people who maintain/port/tune/extend it. The time it takes to type six lines instead of one is pretty small in this view, especially if it is true that each of these readers-of-code comes to understand it faster and more correctly. This is the real pain that needs to be managed. It makes tricky, dense, APL-ish cleverness seem awful and verbose but simple code rather nice. Thoughts to consider, Michael On Wed, Aug 15, 2018 at 8:06 AM Tamás Gulácsi <tgulacs...@gmail.com> wrote: > > > 2018. augusztus 15., szerda 16:46:51 UTC+2 időpontban Hoo Luu a következőt > írta: >> >> 在 2018年8月15日星期三 UTC+8上午12:43:37,Mark Volkmann写道: >> >>> var color = temperature > 100 ? “red” : “blue” >> >> >> Although this feature will not be accepted, we could just talk about it. >> I prefer 'if-expression' to ternary. >> >> var color = if temperature > 100 { "red" } else { "blue" } >> >> vs. current if statement syntax: >> >> var color >> if temperature > 100 { >> color = "red" >> } else { >> color = "blue" >> } >> > > I prefer with nice clean unmissable "default vs. special" > > color := "blue" > if temperature > 100 { > color = "red" > } > > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- *Michael T. jonesmichael.jo...@gmail.com <michael.jo...@gmail.com>* -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.