4 ms·

Programmers who write CLI apps/network-services tend to love Go. Programmers who love mutable, imperative programming love Go. Programmers who find the CSP mode

Programmers who write CLI apps/network-services tend to love Go. Programmers who love mutable, imperative programming love Go. Programmers who find the CSP model a natural fit for asynchronous programming love Go. Programmers who want the stdlib to contain what they need for 80% of use-cases love Go. Programmers who love checking `if err != nil` in every statement love Go. Programmers who write re-usable libraries (eventually) come to hate Go. Programmers who leverage Sequences/Streams, immutability and functional programming tend to hate Go. Programmers who prefer exceptions or railway-result types for error handling also tend to hate Go. Programmers who desire tight control over performance and memory management will obviously hate Go. In my personal opinion, the Go language is handicapped to claim simplicity. However, the Go standard library is amazing for productivity. If Go the language, didn't come with its stdlib and wasn't pushed by Google, you wouldn't have so many Go fans.

adtac 7y ago
>Programmers who desire tight control over performance [...] will obviously hate Go. Curious, why do you say that? Go tries very hard to prevent abstracted, hidden costs like (con|de)structors, so performance is quite obvious. Could you explain a bit more? I understand the memory management part.
- apta 7y ago
  The golang gc is not tunable, at least compared to the JVM GC for example. It is tuned for latency, not throughput. So, if you're writing high-throughput code, you can't really do much. You can try to write code that reduces allocations, but so can you in Java or C# (even moreso after Java gets value types). Not to mention that the golang gc cannot handle GBs (let alone TBs of heap space) the way the JVM routinely does. The golang runtime cannot devirtualize interface implementations the way the JVM does[1] or .NET does. I'm sure there are more examples to think of. [1] https://youtu.be/lunJmMBkqLo?t=1072 https://youtu.be/lunJmMBkqLo?t=1072
  - Thaxll 7y ago
    Go GC can easily handle GBs of heap, especially if you're careful with pointers.
    - apta 7y ago
      I benchmarked etcd with 10G-50GB heap space and it didn't do a good job at all, lots of CPU time spent in GC.
      - todd8 7y ago
        The performance of the etcd system is complex[1], there’s raft consensus, replication, security, snapshots, networking, and basically a lot going on. Perhaps, your benchmarks really do reflect problems that go has with gc, but perhaps some other part amonst the numerous moving parts are causing the poor benchmark results. I’m not sure that we can conclude from your results that go has gc problems when the heap is large. [1] https://github.com/etcd-io/etcd/blob/master/Documentation/op-guide/performance.md https://github.com/etcd-io/etcd/blob/master/Documentation/op...
        apta 7y ago
        From what I recall, having a large-ish number of watchers resulted in memory usage to go up significantly. The gc started thrashing as CPU usage went up. Put performance dropped with gc cycles.
icholy 7y ago
> Programmers who write re-usable libraries (eventually) come to hate Go. > the Go standard library is amazing for productivity. In conclusion, you're not good at writing Go libraries.
zeveb 7y ago
> Programmers who leverage Sequences/Streams, immutability and functional programming tend to hate Go. I dunno, applying the Reader/Writer pattern to other objects in order to get sequences & streams works pretty well in Go. > If Go the language, didn't come with its stdlib and wasn't pushed by Google, you wouldn't have so many Go fans. I think the latter part is very true. Go had the very good fortune to be a Pike tool put out by Google back when, ‘hey, Google are producing this!’ was a good thing. I like Go, but I also like Plan 9 — and it never took off. Neither did Newsqueak or Alef. But Go did, in large part, I think, due to Google’s positive reputation a decade ago.
- rakoo 7y ago
  The Reader/Writer interfaces are beautiful in their simplicity, but they're only useful if you want to stream raw, non-Go data. If you want to iterate over a slice or a channel, basically as soon as your data is fit into Go datastructures you don't have a simple and beautiful pattern for working with them as a flow of data.
  - zeveb 7y ago
    You can always implement a FooReader, which iterates over a flow of Foo objects (which might, for example, be items in a slice or channel). We do this all the time. It is, as you note, quite simple and I think elegant too.
    - lenkite 7y ago
      Yes, I have done this, but I was talking more about streams that I can splice, filter, map, join, pair, slice, window, buffer, groupby, scan, skip, take, switch, zip, reduce, etc. Not really possible without generics, lambdas and a good core of functional routines. Once you get used to this and the speed, productivity and elegance with which problems can be solved, using Golang feels a bit primitive and painful. The same Go code is usually 5x-10x longer.

adtac 7y ago

>Programmers who desire tight control over performance [...] will obviously hate Go. Curious, why do you say that? Go tries very hard to prevent abstracted, hidden costs like (con|de)structors, so performance is quite obvious. Could you explain a bit more? I understand the memory management part.

apta 7y ago
The golang gc is not tunable, at least compared to the JVM GC for example. It is tuned for latency, not throughput. So, if you're writing high-throughput code, you can't really do much. You can try to write code that reduces allocations, but so can you in Java or C# (even moreso after Java gets value types). Not to mention that the golang gc cannot handle GBs (let alone TBs of heap space) the way the JVM routinely does. The golang runtime cannot devirtualize interface implementations the way the JVM does[1] or .NET does. I'm sure there are more examples to think of. [1] https://youtu.be/lunJmMBkqLo?t=1072 https://youtu.be/lunJmMBkqLo?t=1072
- Thaxll 7y ago
  Go GC can easily handle GBs of heap, especially if you're careful with pointers.
  - apta 7y ago
    I benchmarked etcd with 10G-50GB heap space and it didn't do a good job at all, lots of CPU time spent in GC.
    - todd8 7y ago
      The performance of the etcd system is complex[1], there’s raft consensus, replication, security, snapshots, networking, and basically a lot going on. Perhaps, your benchmarks really do reflect problems that go has with gc, but perhaps some other part amonst the numerous moving parts are causing the poor benchmark results. I’m not sure that we can conclude from your results that go has gc problems when the heap is large. [1] https://github.com/etcd-io/etcd/blob/master/Documentation/op-guide/performance.md https://github.com/etcd-io/etcd/blob/master/Documentation/op...
      - apta 7y ago
        From what I recall, having a large-ish number of watchers resulted in memory usage to go up significantly. The gc started thrashing as CPU usage went up. Put performance dropped with gc cycles.

icholy 7y ago

> Programmers who write re-usable libraries (eventually) come to hate Go. > the Go standard library is amazing for productivity. In conclusion, you're not good at writing Go libraries.

zeveb 7y ago

> Programmers who leverage Sequences/Streams, immutability and functional programming tend to hate Go. I dunno, applying the Reader/Writer pattern to other objects in order to get sequences & streams works pretty well in Go. > If Go the language, didn't come with its stdlib and wasn't pushed by Google, you wouldn't have so many Go fans. I think the latter part is very true. Go had the very good fortune to be a Pike tool put out by Google back when, ‘hey, Google are producing this!’ was a good thing. I like Go, but I also like Plan 9 — and it never took off. Neither did Newsqueak or Alef. But Go did, in large part, I think, due to Google’s positive reputation a decade ago.

rakoo 7y ago
The Reader/Writer interfaces are beautiful in their simplicity, but they're only useful if you want to stream raw, non-Go data. If you want to iterate over a slice or a channel, basically as soon as your data is fit into Go datastructures you don't have a simple and beautiful pattern for working with them as a flow of data.
- zeveb 7y ago
  You can always implement a FooReader, which iterates over a flow of Foo objects (which might, for example, be items in a slice or channel). We do this all the time. It is, as you note, quite simple and I think elegant too.
  - lenkite 7y ago
    Yes, I have done this, but I was talking more about streams that I can splice, filter, map, join, pair, slice, window, buffer, groupby, scan, skip, take, switch, zip, reduce, etc. Not really possible without generics, lambdas and a good core of functional routines. Once you get used to this and the speed, productivity and elegance with which problems can be solved, using Golang feels a bit primitive and painful. The same Go code is usually 5x-10x longer.