First chapter of Kernighan and Donovan's new Go book [pdf]

Post by bradtgmurray » Mon, Oct 19, 2015, 7:23 PM UTC

yokohummer7 wrote: post #64

realrocker wrote: post #4

From the book: "But it has comparatively few features and is unlikely to add more. For instance, it has no implicit numeric conversions, no constructors or destructors, no operator overloading, no default parameter values, no inheritance, no generics, no exceptions, no macros, no function annotations, and no thread-local storage."

> no default parameter values Hearing this leaves a bad taste in my mouth, because one of the (mis)features I've found in Go is its implicit default value in struct initialization. In Go, you don't get a compile error when you miss some fields while initializing a struct. e.g. type T struct { a int b string c float64 } t := T{c: 1.5} will happily set `t.a` to 0 and `t.b` to an empty string. While this is useful for m…

  typedef struct Foo {
    int a;
    int b;
  } Foo;

  Foo f = (Foo) { .a = 1 }; // This will initialize b to zero.

Post by AnimalMuppet » Mon, Oct 19, 2015, 7:27 PM UTC

MichaelGG wrote: post #76

dekhn wrote: post #61

Earlier quoted context omitted.

No, the authors specifically said that they would like to have generic features but couldn't figure out a way to implement it without unacceptable performance problems. I'm pretty sure the feature will show up in the next few minor version increments.

Basically they dismissed every implemented approach, despite generics obviously working in other systems. (And it's hardly a "new" feature unless we're counting in multiples of decades.)

Post by 15155 » Mon, Oct 19, 2015, 7:31 PM UTC

AnimalMuppet wrote: post #93

MichaelGG wrote: post #76

Earlier quoted context omitted.

Basically they dismissed every implemented approach, despite generics obviously working in other systems. (And it's hardly a "new" feature unless we're counting in multiples of decades.)

> Basically they dismissed every implemented approach, despite generics obviously working in other systems. But working at a price. And Go isn't willing to pay the price (especially in terms of compile time). If Go ever adds generics, it will be with a new approach that doesn't blow up compile times.

Post by jgalt212 » Mon, Oct 19, 2015, 7:33 PM UTC

realrocker wrote: post #4

From the book: "But it has comparatively few features and is unlikely to add more. For instance, it has no implicit numeric conversions, no constructors or destructors, no operator overloading, no default parameter values, no inheritance, no generics, no exceptions, no macros, no function annotations, and no thread-local storage."

Post by bkeroack » Mon, Oct 19, 2015, 7:39 PM UTC

jgalt212 wrote: post #97

realrocker wrote: post #4

From the book: "But it has comparatively few features and is unlikely to add more. For instance, it has no implicit numeric conversions, no constructors or destructors, no operator overloading, no default parameter values, no inheritance, no generics, no exceptions, no macros, no function annotations, and no thread-local storage."

> no default parameter values This would seriously bum me out as I find the easiest to extend the functionality of an existing Python function is to add a new parameter with a default value. This way, regardless of whether the existing code base the calls the new or old version of the function, it performs the same way as it always has.