Go channels are bad

I thought Go had gc. Why would you ever need reference counts?

Non-memory resources that exist within your application.

Example: Perhaps once no instances of an object are in use, you want to remove that object from persistent storage such as a DB.

Does Go not have finalizers? These are mostly solved problems since the Smalltalk era. Haven't learned Go yet and from what I read I'd be better off with Rust or something that would stretch my brain more like Haskell. When I read about it I get the sense that we are reinventing stuff from the 90s. But hey, it's hip.

Sometimes you need to guarantee that resources are cleaned up in a timely fashion. Finalizers don't help here.

Piggy backing off @catnaroek, go does have finalizers too though.

Example: Recently built a small service that responds to requests and walks various files looking for data.

The service can be asked to unload (close) the file, but it's hard to say whether it's in-use at the time without some kind of reference count to current requests using the file.

Go does have runtime.SetFinalizer: https://golang.org/pkg/runtime/#SetFinalizer

But beware of finalizer ordering issues.

That's kinda what dup() is for. Reference counting happens in the kernel.