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.
