Problems with Go channels (2016)

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.

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

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.

I found Golang to be a gateway drug to Rust for me.

If you want strong control and very unforgiving type system with even more unforgiving memory lifetime management so you know your program can get even faster than corresponding C/C++ programs, then Rust is a no-brainer.

But I did not pick it for the speed, though that's a very welcome bonus. I picked it for the strong static typing system mostly. And I like having the choice to super-optimize my program in terms of memory and speed when I need to.

Modelling your data transformations with enums (sum types) and Result/Option was eye-opening and improved my programming skills in all other languages I am using.

    > you know your program can get even faster than corresponding C/C++ programs

I have seen this argument a few times here are HN. To be clear, I interpret your phrase that Rust "will eventually" be faster than C or C++. (If I read wrong, please correct.) However, I have never seen any compelling evidence that demonstrates equivalent Rust code is faster than C or C++ code. Some lightly Googling tells me that their speeds are roughly equivalent (within 1-2%).

Here is an example of Rust implementation being faster than C.

https://trifectatech.org/blog/zlib-rs-is-faster-than-c/

Discussions on HN of that post at the time more or less debunked the title's claim, from what I recall.