←back to thread

Problems with Go channels (2016)

(www.jtolio.com)
159 points mpweiher | 3 comments | 13 Apr 25 05:43 UTC | HN request time: 0.001s | source
Show context
anacrolix ◴[13 Apr 25 12:52 UTC] No.43672435[source]▶
I've been using Go since 2011. One year less than the author. Channels are bad. No prioritization. No combining with other synchronisation primitives without extra goroutines. In Go, no way to select on a variable number of channels (without more goroutines). The poor type system doesn't let you improve abstractions. Basically anywhere I see a channel in most people's code particular in the public interface, I know it's going to be buggy. And I've seen so many bugs. Lots of abandoned projects are because they started with channels and never dug themselves out.

The lure to use channels is too strong for new users.

The nil and various strange shapes of channel methods aren't really a problem they're just hard for newbs.

Channels in Go should really only be used for signalling, and only if you intend to use a select. They can also act as reducers, fan out in certain cases. Very often in those cases you have a very specific buffer size, and you're still only using them to avoid adding extra goroutines and reverting to pure signalling.

replies(4): >>43672565 #>>43673084 #>>43673101 #>>43675349 #
hajile ◴[13 Apr 25 14:33 UTC] No.43673101[source]▶
This is almost completely down to Go's type terrible system and is more proof that Google should have improved SML/CML (StandardML/ConcurrentML) implementations/libraries rather than create a new language. They'd have a simpler and more powerful language without all the weirdness they've added on (eg, generics being elegant and simple rather than a tacked-on abomination of syntax that Go has).
replies(2): >>43673319 #>>43678543 #
hesdeadjim ◴[13 Apr 25 15:05 UTC] No.43673319[source]▶
Go user for ten years and I don’t know what happened, but this year I hit some internal threshold with the garbage type system, tedious data structures, and incessant error checking being 38% of the LoC. I’m hesitant to even admit what language I’m considering a full pivot to.
replies(5): >>43673766 #>>43673782 #>>43674588 #>>43675348 #>>43677473 #
myaccountonhn ◴[13 Apr 25 19:49 UTC] No.43675348[source]▶
OCaml is underrated IMO. It's a systems language like Go with a simple runtime but functional with a great type system and probably best error handling out of any language I've used (polymorphic variants).
replies(2): >>43675360 #>>43677468 #
treyd ◴[13 Apr 25 19:52 UTC] No.43675360[source]▶
OCaml and Go are not considered systems programming languages, in part due to having required heavy runtimes and garbage collection.
replies(1): >>43677596 #
1. 9rx ◴[14 Apr 25 02:39 UTC] No.43677596[source]▶
So they're scripting languages?
replies(1): >>43678115 #
2. hajile ◴[14 Apr 25 04:42 UTC] No.43678115[source]▶
Scripting languages would be (usually interpreted) languages for doing small snippets of code. Examples would be bash, Applescript, python, etc.

Application languages are generally managed/GC'd languages with JITs or AOT compilation for doing higher-performance apps. Examples would be Java, Go, Ocaml, Haskell, etc.

System languages are generally concerned with portability, manual memory layout, and direct hardware access as opposed to managed APIs. Examples would be C/C++, Rust, Zig, Pascal, etc.

replies(1): >>43678269 #
3. 9rx ◴[14 Apr 25 05:12 UTC] No.43678269[source]▶
Traditionally,

Scripts are programs that carry out a specific task and then exit. If failure occurs, it is usually on the operator to fix the issue and run the script again. I agree that bash, AppleScript, Python, etc. are geared towards these types of programs.

Applications are programs with interfaces (not necessary graphical, but can be) that are used interactively. If failure occurs, the software usually works with the user to address the problem. It's not completely unheard of to use Go here, but I wouldn't call that its strength.

Systems are "forever"-running programs to provide foundational services other programs. If failure occurs, the software usually does its best to recover automatically. This is what Go was designed for – specifically in the area of server development. There are systems, like kernels, that Go wouldn't be well suited for, but the server niche was always explicit.

Your pet definitions are fine too – it is a perfectly valid take – but know that's not what anyone else is talking about.