3 ms·

One of the primary design principles behind Go is that it be designed to incorporate the best available features of other languages, as much as it is able while

by Zikes 10y ago

One of the primary design principles behind Go is that it be designed to incorporate the best available features of other languages, as much as it is able while remaining simple and easy to learn and use. If there is a way to incorporate the best features of Haskell and Rust while maintaining Go's current simplicity and ease of use, then it should be incorporated. To that end, the Go core developers have expressed an intent to implement Generics, however they want to do so in a way that does not (significantly) negatively effect the language's simplicity or compile times. https://github.com/golang/go/issues/15292 https://github.com/golang/go/issues/15292

kasey_junk 10y ago
> One of the primary design principles behind Go is that it be designed to incorporate the best available features of other languages Is that documented somewhere?
- Zikes 10y ago
  I expected I would find it in https://golang.org/doc/faq https://golang.org/doc/faq but I'm not seeing it there, so I have no reliable sources for that statement at this time. It's something I hear often, though. That Go is intended to be a "modern" language, with the definition of "modern" being that the opportunity that a blank slate provides allows for the application of the best features and learnings of the languages of the past.
  - AnimalMuppet 10y ago
    > ... with the definition of "modern" being that the opportunity that a blank slate provides allows for the application of the best features and learnings of the languages of the past. Application of the best features and learnings to a particular problem domain. The (intended) domain is Google-scale code bases that live for decades. The ideas that are important there may not be applicable anywhere else. If they are, it's more by happenstance than design.
glangdale 10y ago
An open question: has the ship has already sailed on generics in Go? That is, is there too much Go code out there written without generics to ever incorporate generics after-the-fact? I am in two minds; after all, C++ existed for a long time without a workable implementation of templates, and that hasn't stopped the STL from doing quite well. On the other hand, there were a number of fairly successful generics implementations already done when Go was created, and some of the core developers for Go seem to really have only lukewarm support for the idea (unlike C++, where Stroustrup seemed to support generics enthusiastically well before they appeared). It does seem to be a very weird thing to bolt onto an already mature language. Some of the less felicitous bits of the C++ standard library seem like they would have been done very differently if templates had worked from Day 1 in the language.
- Zikes 10y ago
  It's absolutely a possibility for Go 2.0. There's a hard lock on Go 1.X compatibility, but per the link in my above comment the Go team is fielding proposals for Generic implementations. I also recommend reading Russ Cox's (Go core developer) HN comment: https://news.ycombinator.com/item?id=9622417 https://news.ycombinator.com/item?id=9622417
  - glangdale 10y ago
    I've read that before. I do regard the conservatism here as carrying a cost: specifically, great rafts of code will be written without generics and the absence of generics will influence other parts of the language. I'm not an expert in generics by any stretch of the imagination; I timidly implement the occasional template function, happily use STL/BGL where I can, and am amazed at the sort of data structures this lets me get away with. I do find myself puzzled that apparently no generics system in common use was deemed 'good enough' by the Go team to just clag before an entire language and its aforementioned 'rafts of code' sprang up around the absence of such features... there may be good reason. But a language that doesn't let me do what I happily do in C++, with type safety, using language features that are over a decade old, is a total non-starter for me. The language may be all the simpler for this, but the code I would have to write would bear the cost of this instead. It's not a win for me, and vague threats that I'll get a vomitous compiler message when I bugger up "make_pair" and hints that the "princess is in another castle" aren't going to browbeat me into accepting a throwback of a language. My guess is that g++'s template error messages are going to be acceptable long before I see generics in Go, if I ever do.
int_19h 10y ago
I'm not really convinced by the Go rationale on the lack of generics and other things (like sane error handling). Argument from complexity is weak, because literally every other strongly typed mainstream PL has those abstractions by now. It's like arguing that your language shouldn't have loops and functions sometime circa 1970, because they complicate matters over the good old GOTO. All in all, my impression of Go is that it's a language designed by the same people who wrote the Google C++ coding guidelines (https://www.linkedin.com/pulse/20140503193653-3046051-why-google-style-guide-for-c-is-a-deal-breaker https://www.linkedin.com/pulse/20140503193653-3046051-why-go...).

by Zikes 10y ago

kasey_junk 10y ago

> One of the primary design principles behind Go is that it be designed to incorporate the best available features of other languages Is that documented somewhere?

Zikes 10y ago
I expected I would find it in https://golang.org/doc/faq https://golang.org/doc/faq but I'm not seeing it there, so I have no reliable sources for that statement at this time. It's something I hear often, though. That Go is intended to be a "modern" language, with the definition of "modern" being that the opportunity that a blank slate provides allows for the application of the best features and learnings of the languages of the past.
- AnimalMuppet 10y ago
  > ... with the definition of "modern" being that the opportunity that a blank slate provides allows for the application of the best features and learnings of the languages of the past. Application of the best features and learnings to a particular problem domain. The (intended) domain is Google-scale code bases that live for decades. The ideas that are important there may not be applicable anywhere else. If they are, it's more by happenstance than design.

glangdale 10y ago

An open question: has the ship has already sailed on generics in Go? That is, is there too much Go code out there written without generics to ever incorporate generics after-the-fact? I am in two minds; after all, C++ existed for a long time without a workable implementation of templates, and that hasn't stopped the STL from doing quite well. On the other hand, there were a number of fairly successful generics implementations already done when Go was created, and some of the core developers for Go seem to really have only lukewarm support for the idea (unlike C++, where Stroustrup seemed to support generics enthusiastically well before they appeared). It does seem to be a very weird thing to bolt onto an already mature language. Some of the less felicitous bits of the C++ standard library seem like they would have been done very differently if templates had worked from Day 1 in the language.

Zikes 10y ago
It's absolutely a possibility for Go 2.0. There's a hard lock on Go 1.X compatibility, but per the link in my above comment the Go team is fielding proposals for Generic implementations. I also recommend reading Russ Cox's (Go core developer) HN comment: https://news.ycombinator.com/item?id=9622417 https://news.ycombinator.com/item?id=9622417
- glangdale 10y ago
  I've read that before. I do regard the conservatism here as carrying a cost: specifically, great rafts of code will be written without generics and the absence of generics will influence other parts of the language. I'm not an expert in generics by any stretch of the imagination; I timidly implement the occasional template function, happily use STL/BGL where I can, and am amazed at the sort of data structures this lets me get away with. I do find myself puzzled that apparently no generics system in common use was deemed 'good enough' by the Go team to just clag before an entire language and its aforementioned 'rafts of code' sprang up around the absence of such features... there may be good reason. But a language that doesn't let me do what I happily do in C++, with type safety, using language features that are over a decade old, is a total non-starter for me. The language may be all the simpler for this, but the code I would have to write would bear the cost of this instead. It's not a win for me, and vague threats that I'll get a vomitous compiler message when I bugger up "make_pair" and hints that the "princess is in another castle" aren't going to browbeat me into accepting a throwback of a language. My guess is that g++'s template error messages are going to be acceptable long before I see generics in Go, if I ever do.

int_19h 10y ago

I'm not really convinced by the Go rationale on the lack of generics and other things (like sane error handling). Argument from complexity is weak, because literally every other strongly typed mainstream PL has those abstractions by now. It's like arguing that your language shouldn't have loops and functions sometime circa 1970, because they complicate matters over the good old GOTO. All in all, my impression of Go is that it's a language designed by the same people who wrote the Google C++ coding guidelines (https://www.linkedin.com/pulse/20140503193653-3046051-why-google-style-guide-for-c-is-a-deal-breaker https://www.linkedin.com/pulse/20140503193653-3046051-why-go...).