5 ms·

++to both sides of this, though I think I weight the positives a little more heavily than you do. The stdlib, compiler, and ecosystem stuff like the tour/godoc/

++to both sides of this, though I think I weight the positives a little more heavily than you do. The stdlib, compiler, and ecosystem stuff like the tour/godoc/playground matter more than they get credit for (the value of any language can't be determined just from its spec), and that hype helps get libraries written, tools improved, etc. I also share the sentiment that there's one set of gripes that are annoying but don't actually prevent getting stuff done (if I'm reading your comment right). I wouldn't mind C++-style const params, some way to briefly relax the (usually quite useful) fatwa against unused names in the heat of writing/testing code, a concise built-in non-close() way to broadcast to everyone waiting on a channel, etc. But, point is, none of that really stops or substantially slows a project down. And Go has other, almost complementary, quirks I like, like expressions at the toplevel or the prohibition on discarding results of certain functions or constants that are just numbers or... I really hope that by Go 2 there's a better way to write containers or functional tools. Right now leading gophers occasionally argue that it'd be bad to extend Go until your code never has to repeat itself, and sure, you can get by with what Go has now. But that all glosses over that there's a substantial cost in expressiveness to some things Go's missing. I'd even accept something like parameterized package imports (import intset "container/set<int>" loads package set<T> substituting T for int). Those would be "Go-y" in that instantiation would have to be explicit and the type system would be unaffected (both unlike C++), though it'd sacrifice some power/brevity. Pike also offhandedly mentioned polymorphic functions in his "Less is exponentially more" post a while back, and I'd take those too. :)

ithkuil 13y ago
FYI https://github.com/droundy/gotgo https://github.com/droundy/gotgo
- pjmlp 13y ago
  Like generic macros bundled in C++ compilers around 1993.
  - ithkuil 13y ago
    You mean a trick to use cpp preprocessor to implement template expansion when C++ (or common compilers) didn't have templates? Did this technique just expand the classes every time they were used (in the header file, just like C++ templates) or generated files for each concrete type parameter which was then just compiled once (like gotgo) ?
    - pjmlp 13y ago
      Yes. Borland C++ for MS-DOS had such a framework. Basically you had to #define the desired set of type definitions before each #include, if I remember correctly. That is why I find tools like gotgo a form of time travel back to the time when generic programming wasn't mainstream.
  - twotwotwo 13y ago
    Sure. I'm happy if it makes it easy to build the stuff I want, even if it's not fundamentally that new or interesting.
    - pjmlp 13y ago
      The point is that by keeping generics out of the language, Go designers have forced the developers to look out for solutions of their own. Which funny enough, happen to be similar to the ones in use before generics were widely available in the mainstream.
      - twotwotwo 13y ago
        Fair enough--I'm just saying I actually wouldn't mind if the actual eventual solution in Go were a bit gotgo-like (though I'd like it to be standard, not require an extra build step, etc.). Making adaptable containers without extending the type system might even be the Go-y way to do it, though it probably wouldn't win many converts from other languages. (Or, from the other end entirely, I could see polymorphic functions happening--they'd complicate the Go compilers more than macro-like generics would, but using them would feel familiar for Go's many refugees from duck-typed dynamic langs.) Anyhow, I'm fairly aimlessly spec'latin' here, don't listen too much to me.
- twotwotwo 13y ago
  Yeah--it looks like it does it about as well as a third-party tool can. But it's the sort of thing it seems like could hugely benefit from being in the core--then hopefully folks would be more inclined to write libs for B-trees or whatever on top of it. Mostly irrelevant, but to put a finer point on the wish for something to show up in the core: I totally sympathize with the Gophers' decision to ship 1.0 without generics (or polymorphic functions or whatever); there are workarounds for not having 'em, and there's plenty else to keep the core team busy, like writing an awesome stdlib. Other languages that now have generics also lacked them at first. But it sort of grates to hear it waved off as simply unimportant that you can't deploy a set or B-tree or whatever of a new type without either cut-and-pasting (by hand or w/a third-party tool) or taking the runtime hit of dynamic typing. That's a solvable, useful-to-solve, and repeatedly solved problem, and seems eventually worth solving in the Go core, even if it's not the highest priority. Most of Go's omissions/quirks I either actively like or just shrug at, but that's one on my wishlist. End rant. :)

ithkuil 13y ago

FYI https://github.com/droundy/gotgo https://github.com/droundy/gotgo

pjmlp 13y ago
Like generic macros bundled in C++ compilers around 1993.
- ithkuil 13y ago
  You mean a trick to use cpp preprocessor to implement template expansion when C++ (or common compilers) didn't have templates? Did this technique just expand the classes every time they were used (in the header file, just like C++ templates) or generated files for each concrete type parameter which was then just compiled once (like gotgo) ?
  - pjmlp 13y ago
    Yes. Borland C++ for MS-DOS had such a framework. Basically you had to #define the desired set of type definitions before each #include, if I remember correctly. That is why I find tools like gotgo a form of time travel back to the time when generic programming wasn't mainstream.
- twotwotwo 13y ago
  Sure. I'm happy if it makes it easy to build the stuff I want, even if it's not fundamentally that new or interesting.
  - pjmlp 13y ago
    The point is that by keeping generics out of the language, Go designers have forced the developers to look out for solutions of their own. Which funny enough, happen to be similar to the ones in use before generics were widely available in the mainstream.
    - twotwotwo 13y ago
      Fair enough--I'm just saying I actually wouldn't mind if the actual eventual solution in Go were a bit gotgo-like (though I'd like it to be standard, not require an extra build step, etc.). Making adaptable containers without extending the type system might even be the Go-y way to do it, though it probably wouldn't win many converts from other languages. (Or, from the other end entirely, I could see polymorphic functions happening--they'd complicate the Go compilers more than macro-like generics would, but using them would feel familiar for Go's many refugees from duck-typed dynamic langs.) Anyhow, I'm fairly aimlessly spec'latin' here, don't listen too much to me.
twotwotwo 13y ago
Yeah--it looks like it does it about as well as a third-party tool can. But it's the sort of thing it seems like could hugely benefit from being in the core--then hopefully folks would be more inclined to write libs for B-trees or whatever on top of it. Mostly irrelevant, but to put a finer point on the wish for something to show up in the core: I totally sympathize with the Gophers' decision to ship 1.0 without generics (or polymorphic functions or whatever); there are workarounds for not having 'em, and there's plenty else to keep the core team busy, like writing an awesome stdlib. Other languages that now have generics also lacked them at first. But it sort of grates to hear it waved off as simply unimportant that you can't deploy a set or B-tree or whatever of a new type without either cut-and-pasting (by hand or w/a third-party tool) or taking the runtime hit of dynamic typing. That's a solvable, useful-to-solve, and repeatedly solved problem, and seems eventually worth solving in the Go core, even if it's not the highest priority. Most of Go's omissions/quirks I either actively like or just shrug at, but that's one on my wishlist. End rant. :)