8 ms·

The `make` function is an example of an inconcistency. The language does not have generics, yet this built-in function is a generic one. As far as Go being saf

by azth 14y ago

The `make` function is an example of an inconcistency. The language does not have generics, yet this built-in function is a generic one. As far as Go being safer and cleaner because it lacks modern language features, generics would make the language safer (compare to casting all over the place, which is less safe, and has a runtime cost). Some modern languages also don't have null pointers, further increasing safety.

chimeracoder 14y ago
Generics aren't included for two reasons: 1. They haven't figured out a way to implement them without impacting performance significantly 2. They're not as necessary as you might think. While they're open to adding them if #1 changes, in response to #2, I find I don't miss them as much as I would have thought - and that's coming from a strong advocate of statically typed, functional languages. In idiomatic Go, I just don't need them as often as I would have thought, and the interfaces are well-designed enough to make up for much of the difference. http://golang.org/doc/go_faq.html#Why_doesnt_Go_have_feature_X http://golang.org/doc/go_faq.html#Why_doesnt_Go_have_feature...
- azth 14y ago
  I have read those same arguments over and over. Just because generics do not come up as often does not mean they won't make programs safer and/or faster. Almost all of the workarounds I have seen for the lack of generics can easily be applied to Java for instance. There were several questions that came up on the Go mailing list asking how to convert certain code to make it more "idiomatic". The resulting code had several layers of indirection, interfaces composed of interfaces, and so on, that ironically it would have looked much more concise, and would have been type safe in a more "traditional OO" language like Java.
  - jlgreco 14y ago
    Not sure why you would expect to hear anything but the same thing over and over, in response to the same complaint being raise.. over and over. I don't think anyone denies that adding generics, if done properly, would improve the language. The only real controversial thing being suggested is that generics are not worth an implementation that is not up to standards. Personally, I think that is a reasonable position.
    - deleted 14y ago
      [deleted]
- gnuvince 14y ago
  When people mention that they don't find generics necessary, they should mention the type of work they do. For someone building an application, I can believe that one can do without generics, and still get a good application out. However, for someone writing a library, I think that their absence will be much more noticeable.
Jabbles 14y ago
I don't really view "make" as inconsistent - the fact that builtin functions have special powers doesn't strike me as particularly unusual. If they didn't I presume they'd just be part of the standard library. Besides, it seems that the inconsistency (if any) is the fact that the rest of the language doesn't have generics - something that I hope will be resolved in the future, but without which I am coping surprisingly well. Finally, null pointer dereference does not cause undefined behaviour, as in C, C++. Go will panic (and you can safely recover). I'm not convinced that removing null pointers will eliminate the cause of these bugs. I think the idea of "failing fast" would help diagnose bugs much faster - although I see reasons for disagreeing. I do not think Go is intended or recommended for safety-critical applications, where special languages such as Ada are used.
- frou_dh 14y ago
  > the fact that builtin functions have special powers doesn't strike me as particularly unusual. If they didn't I presume they'd just be part of the standard library. It strikes me that the primary expectation of a built-in function is not having to import anything, and not having to namespace-qualify it on use. It circumventing the type system IS a surprise. In Go, I believe not only generic-ness appears, but also overloading. Go as a complete package is very cool, though! I think the reason its warts get brought up disproportionately often is a reaction to its evangelists going a bit overboard in claims of simplicity/orthogonality.
- azth 14y ago
  > Finally, null pointer dereference does not cause undefined behaviour, as in C, C++. Go will panic (and you can safely recover). I'm not convinced that removing null pointers will eliminate the cause of these bugs. I think the idea of "failing fast" would help diagnose bugs much faster - although I see reasons for disagreeing. Dereferencing nulls in Java is not undefined either, so what? And the notion of 'failing fast' is exactly why null pointers should be modeled in the type system. What faster way to catch bugs than at compile time? Furthermore, how do you know you will quickly hit a NPE in you code at runtime, if it happens to be in a code path that is infrequently accessed? Ironically in the OSCON talk mentioned in another comment here, Pike mentions that dynamic typing is pushing some compile time errors into runtime, which is exactly what is happening here.

by azth 14y ago

chimeracoder 14y ago

Generics aren't included for two reasons: 1. They haven't figured out a way to implement them without impacting performance significantly 2. They're not as necessary as you might think. While they're open to adding them if #1 changes, in response to #2, I find I don't miss them as much as I would have thought - and that's coming from a strong advocate of statically typed, functional languages. In idiomatic Go, I just don't need them as often as I would have thought, and the interfaces are well-designed enough to make up for much of the difference. http://golang.org/doc/go_faq.html#Why_doesnt_Go_have_feature_X http://golang.org/doc/go_faq.html#Why_doesnt_Go_have_feature...

azth 14y ago
I have read those same arguments over and over. Just because generics do not come up as often does not mean they won't make programs safer and/or faster. Almost all of the workarounds I have seen for the lack of generics can easily be applied to Java for instance. There were several questions that came up on the Go mailing list asking how to convert certain code to make it more "idiomatic". The resulting code had several layers of indirection, interfaces composed of interfaces, and so on, that ironically it would have looked much more concise, and would have been type safe in a more "traditional OO" language like Java.
- jlgreco 14y ago
  Not sure why you would expect to hear anything but the same thing over and over, in response to the same complaint being raise.. over and over. I don't think anyone denies that adding generics, if done properly, would improve the language. The only real controversial thing being suggested is that generics are not worth an implementation that is not up to standards. Personally, I think that is a reasonable position.
  - deleted 14y ago
    [deleted]
gnuvince 14y ago
When people mention that they don't find generics necessary, they should mention the type of work they do. For someone building an application, I can believe that one can do without generics, and still get a good application out. However, for someone writing a library, I think that their absence will be much more noticeable.

Jabbles 14y ago

I don't really view "make" as inconsistent - the fact that builtin functions have special powers doesn't strike me as particularly unusual. If they didn't I presume they'd just be part of the standard library. Besides, it seems that the inconsistency (if any) is the fact that the rest of the language doesn't have generics - something that I hope will be resolved in the future, but without which I am coping surprisingly well. Finally, null pointer dereference does not cause undefined behaviour, as in C, C++. Go will panic (and you can safely recover). I'm not convinced that removing null pointers will eliminate the cause of these bugs. I think the idea of "failing fast" would help diagnose bugs much faster - although I see reasons for disagreeing. I do not think Go is intended or recommended for safety-critical applications, where special languages such as Ada are used.

frou_dh 14y ago
> the fact that builtin functions have special powers doesn't strike me as particularly unusual. If they didn't I presume they'd just be part of the standard library. It strikes me that the primary expectation of a built-in function is not having to import anything, and not having to namespace-qualify it on use. It circumventing the type system IS a surprise. In Go, I believe not only generic-ness appears, but also overloading. Go as a complete package is very cool, though! I think the reason its warts get brought up disproportionately often is a reaction to its evangelists going a bit overboard in claims of simplicity/orthogonality.
azth 14y ago
> Finally, null pointer dereference does not cause undefined behaviour, as in C, C++. Go will panic (and you can safely recover). I'm not convinced that removing null pointers will eliminate the cause of these bugs. I think the idea of "failing fast" would help diagnose bugs much faster - although I see reasons for disagreeing. Dereferencing nulls in Java is not undefined either, so what? And the notion of 'failing fast' is exactly why null pointers should be modeled in the type system. What faster way to catch bugs than at compile time? Furthermore, how do you know you will quickly hit a NPE in you code at runtime, if it happens to be in a code path that is infrequently accessed? Ironically in the OSCON talk mentioned in another comment here, Pike mentions that dynamic typing is pushing some compile time errors into runtime, which is exactly what is happening here.