Well, from my 15 years experience for each nice example of ternary operator being useful there are 10 more examples where it's being used improperly and makes code hardly readable.

I know that the typical answer is "it's just bad programmer", but that's where Go chooses different view. Many design decisions in Go were taken with awareness of the social context of programming.

If the feature incentivizes using it in a wrong way - it's not a bad programmer, it's a bad feature. Programming language is a language between humans in a first place and it should be readable as much as possible, it should deincentivize using obscure and easy-to-use-improperly things.

It so much better when you go to practically any Go repository and find that code is readable and clear. I've never had this experience with any other language before.

PS. Found one of the real examples of abusing ternary operators. That was one of the coolest I've seen. And I guess it's easy to understand that the same programmer wouldn't write the same with "if .. else .." blocks in Go. He would realize that it's too verbose and hard, hence probably wrong design, so he need to find better solution within the space of language features. http://imgur.com/a/hjKOe

> If the feature incentivizes using it in a wrong way - it's not a bad programmer, it's a bad feature.

So there's nothing good about alcohol (it may cause liver damage), cars (they may cause accidents), prescribed drugs (they may have unpleasant collateral effects), ...

Hey, it's also true that programming incentivizes bugs, so programming is bad. Let's stop programming!

It's weird how people miss the conditional operator but not switch case fallthrough.

> It so much better when you go to practically any Go repository and find that code is readable and clear. I've never had this experience with any other language before.

What languages did you have to endure before?

> Found one of the real examples of abusing ternary operators.

Yeah, the original code is silly, the binary search trees are not always balanced. They should be more like:

    if (type <= 10) ? (if (type <= 5) ? ... : ...) : if (type <= 7) ? ... : ...

It's worse that that, since you need to declare the variable as well. It's the "var n int" piece that bugs me, since sometimes you're moving code around and have a n := trueVal hidden in there.

    var    n int
    if expr {
        n = trueVal
    } else {
        n = falseVal
    }

Go has a ternary if, but the syntax is weird ;-)

    n := map[bool]func() int{
            false: func() int { return falseExpr },
            true:  func() int { return trueExpr },
    }[expr]()

https://play.golang.org/p/TXIse32WD9

Now, let's see how to abstract it with "go generate"...

I genuinely prefer

    n = if expr trueVal else falseVal

(which is what e.g. Scala does) over meaningless-unless-memorized '?' and ':'

In most cases this will boil down to:

    n := defaultVal
    if expr {
      n := otherVal
    }

Which I think is easier to understand, and not that much more typing. YMMV of course.

If defaultVal is a constant, this is OK, but what if it requires computation?