4 ms·

I work with Go on a daily basis (and it is my own choice), and I would like to offer a slightly different opinion than most people on this thread. Go is reliab

I work with Go on a daily basis (and it is my own choice), and I would like to offer a slightly different opinion than most people on this thread. Go is reliable, fast, and its main benefits are simple concurrency, a good, well written standard library, and a blazing fast compiler. Moreover, the Go tour is very nice, and it gives enough material to any programmer to start writing short programs using http, images, channels,... in only a few hours. This said, very often, using Go feels backwards to me. It could be because of I have personal gripes with the package management system, but I easily ignore those cosmetic things when I'm getting stuff done, so it's not. After getting used to type systems like the one Haskell has, Go feels very primitive. Moreover, the lack of generics and support for functional programming makes my programs longer, less readable, and less friendly for teamwork. Even though I still sell Go to my friends as a replacement for most of the scripting languages they use, (Typed) Clojure and Haskell are languages that are way friendlier to me. I would take Go over C or C++ any day, simply because it would allow me to write relatively readable programs in less time, but if the task fits within what Clojure or Haskell does right, I would not hesitate for a second. As of today, I primarily use Go for infrastructure work, and it really shines there. I am going to replace a lot of Python code with it, and it's not necessarily for the performance, but for the ease of deployment, the reliability, the fact that Python developers can read it, and the static typing. That is to say I don't disagree with the author, but I want to provide another point of view. The language I believe will deliver what I hoped with Go is Rust. I do not believe, however that it is ever going to reach the hype level that Go has, but it seems more promising to me.

twotwotwo 13y ago
++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

++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.