Four days of Go

Post by aikah » Wed, Apr 22, 2015, 1:32 PM UTC

mike_hearn wrote: post #13

aperture wrote: post #3

Earlier quoted context omitted.

I enjoyed that the author readily admits to his own faults concerning Go too: In this telling, the story of Go is really a tale of revenge, not just against slow builds, but against all kinds of sloppy programming. Which in my opinion is too bad, because I myself am a sloppy programmer. This really does seem to be the approach I see with the Go digest mailing list. What I don't understand though is the ease of import…

Go is developed inside Google where all dependencies are checked into their global version control repository. There are literally no versions inside the Google codebase - everything is compiled at head. If you want to upgrade a third party library then you are expected to globally upgrade every user of it .... simply bumping the version of a widely used library can thus turn into a multi-month promotion worthy proje…

Post by [deleted] » Wed, Apr 22, 2015, 1:45 PM UTC

zerr wrote: post #4

jgrahamc wrote: post #2

In other words, Go represents a kind of Machiavellian power play, orchestrated by slow-and-careful programmers who are tired of suffering for the sins of fast-and-loose programmers. The Go documentation refers quite often to intolerable 45-minute build times suffered by the original designers, and I can’t help but imagine them sitting around and seething about all those unused imports from those “other” programmers,…

> faith Or arrogance and incompetence. It's been said many times. Go team should spend at least one day with Gilad Bracha...

Post by nicpottier » Wed, Apr 22, 2015, 1:48 PM UTC

Post by vorg » Wed, Apr 22, 2015, 1:51 PM UTC

sagichmal wrote: post #28

deckiedan wrote: post #23

Earlier quoted context omitted.

It's a balance between readability meaning 'short, and concise' and readability meaning 'very clear, even if that requires being overly verbose'. return (data.name !== '' ?: 'New Data') or Python style: return (data.name if data.name else 'New Data') vs: if (data.name != '') { return data.name } else { return 'New Data' } The former being much more concise, so that you can display (and grok, perhaps) a single functio…

> if (data.name != "") { > return data.name > } else { > return "New Data" > } Not exactly... if data.name != "" { return data.name } return "New Data" And consider the likely context... func name(ref int64) string { data, ok := get(ref) if !ok { return "No Data" } if !data.valid { return "Invalid Data" } if data.name == "" { return "New Data" } return data.name } Straightforward and unambiguous.

    package main
    import "fmt"
    func main(){
      fmt.Println(name(28))
    }
    type T struct{name string; valid bool}
    func get(ref int64) (T, bool) {
      return T{"abc", true}, false
    }
    func name(ref int64) string {
      switch data, ok := get(ref); true {
      case !ok:
        return "No Data"
      case !data.valid:
        return "Invalid Data"
      case data.name == "":
        return "New Data"
      default:
        return data.name
      }
    }

Post by voidlogic » Wed, Apr 22, 2015, 1:57 PM UTC

tormeh wrote: post #33

jerf wrote: post #30

Earlier quoted context omitted.

Go's goto is the standard structured-programming-limited goto which is not allowed to violate blocks, which means it is not the goto that is "considered harmful". Go's "pointers" are not allowed to do pointer arithmetic, which basically means that they are references. As they are also backed by a garbage collector, this means you can't do any of the nasty C things you can do with them, not even "fail to deallocate" t…

Goto's create unreadable code and are unnecessary. They're there to encourage the writing of bad code. You can pass a pointer over a goroutine channel. That's my main issue with them, beside the fact that we should be past this needless complication of our code. Again, they're unnecessary and encourage bad code.