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.


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 

Reply via email to