6 ms·

That's just because its young. The same could have been said for C in the long long ago. And honestly compared to most of whats out there, C is a tiny languag

That's just because its young. The same could have been said for C in the long long ago. And honestly compared to most of whats out there, C is a tiny language. Give go time, it'll bloat ;)

shurcooL 14y ago
I would hope not, as long as people like Rob Pike are around and they don't radically change their current [1] guiding principles. [1]: http://commandcenter.blogspot.com.au/2012/06/less-is-exponentially-more.html http://commandcenter.blogspot.com.au/2012/06/less-is-exponen...
frou_dh 14y ago
Whether generics get retrofitted will be the measure of this. I suspect they won't, because by the time a Go 2.0 timeframe arrives, the thinking will be something like "Time has shown that we thrived without them, so despite commentator gnashing, they're simply not required."
- shurcooL 14y ago
  It's possible to write tools that generate code instead of building it into the language too. I wonder if it can be done better than building it into the language.
  - dchest 14y ago
    Here's one https://github.com/droundy/gotgo https://github.com/droundy/gotgo
  - frou_dh 14y ago
    You could contrast achieving generics using C preprocessor gymnastics versus C++ templates.
    - shurcooL 14y ago
      C preprocessor stuff works with text and text only. That's why it's quite hard to make things elegant. Tools can work with text and anything else you can think of. So they can potentially be better. But I don't know what could be done at this point (in fact, this might be a good problem to be analyzed from a theoretical side).
Someone 14y ago
Not only because it's young, also because we _do_ learn from mistakes made in other languages. For example, I do not see PL/I's choice to make none of its keywords reserved names (IIRC, defended on the argument that one cannot expect anybody to know all the reserved words) repeated much anymore in Algol-like languages. As another example, IDE/language pairs such as Eclipse/Java have learned us the advantages of languages that are easy to parse and where there is little ambiguity even in incomplete or incorrect programs (it makes syntax coloring easier, and allows for refactoring tools that are somewhat reliable on non conforming source code)

That's just because its young. The same could have been said for C in the long long ago. And honestly compared to most of whats out there, C is a tiny language. Give go time, it'll bloat ;)

shurcooL 14y ago

I would hope not, as long as people like Rob Pike are around and they don't radically change their current [1] guiding principles. [1]: http://commandcenter.blogspot.com.au/2012/06/less-is-exponentially-more.html http://commandcenter.blogspot.com.au/2012/06/less-is-exponen...

frou_dh 14y ago

Whether generics get retrofitted will be the measure of this. I suspect they won't, because by the time a Go 2.0 timeframe arrives, the thinking will be something like "Time has shown that we thrived without them, so despite commentator gnashing, they're simply not required."

shurcooL 14y ago
It's possible to write tools that generate code instead of building it into the language too. I wonder if it can be done better than building it into the language.
- dchest 14y ago
  Here's one https://github.com/droundy/gotgo https://github.com/droundy/gotgo
- frou_dh 14y ago
  You could contrast achieving generics using C preprocessor gymnastics versus C++ templates.
  - shurcooL 14y ago
    C preprocessor stuff works with text and text only. That's why it's quite hard to make things elegant. Tools can work with text and anything else you can think of. So they can potentially be better. But I don't know what could be done at this point (in fact, this might be a good problem to be analyzed from a theoretical side).

Someone 14y ago

Not only because it's young, also because we _do_ learn from mistakes made in other languages. For example, I do not see PL/I's choice to make none of its keywords reserved names (IIRC, defended on the argument that one cannot expect anybody to know all the reserved words) repeated much anymore in Algol-like languages. As another example, IDE/language pairs such as Eclipse/Java have learned us the advantages of languages that are easy to parse and where there is little ambiguity even in incomplete or incorrect programs (it makes syntax coloring easier, and allows for refactoring tools that are somewhat reliable on non conforming source code)