On Fri, Jun 26, 2020 at 11:52 AM Tyler Compton <xavi...@gmail.com> wrote: > > On Fri, Jun 26, 2020 at 10:52 AM David Riley <fraveyd...@gmail.com> wrote: >> >> Also, to this specific point: this exact approach, as with much of Go, >> embodies the Bell Labs approach to design (for better or for worse, and with >> good reason). Sometimes we have to live with the artifacts of evolution. > > > One interesting counterexample here is the GC and scheduler, which take on a > huge amount of complexity in the implementation to create a dead-simple > interface. It seems like Go is willing to take a worse-is-better approach > when the amount of interface complexity is relatively small.
I honestly don't think that append is an example of worse-is-better. I think it's an example of preferring to pass and return values rather than pointers. The language could easily have made append take a pointer to a slice as its first argument, which would eliminate a certain class of bugs. But it would also mean that you couldn't create a slice by simply appending to nil, as in s := append([]int(nil), 1, 2, 3). You would instead have to declare the variable first. While append does confuse people from time to time, I think it's clearly documented, as pointed out upthread. It's not really all that hard to understand. And once you understand it, it's easy to use. I don't think any particular approach is obviously better here, so I don't think this is an example of worse-is-better. Ian -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAOyqgcVCGBdcA%2BHe28UqycJJb_GiG7LcV%2BP4WjHjvcAEDMrFJw%40mail.gmail.com.
