[drewg123]

Golang's use of a potentially unbounded number of threads is just insane. I used to be fairly bullish on golang, but this, combined with the fact that its garbage collected, makes me feel its just unsuitable for production use.

[floating-io]

You can have this problem with any kind of thread -- including OS threads -- if you do an unbounded spawn loop. Go is hardly unique in this.

Goroutines are actually better AFAIK because they distribute work on a thread pool that can be much smaller than the number of active goroutines.

If my quick skim created a correct understanding, then the problem here looks more like architecture. Put simply: does the memcached client really require a new TCP connection for every lookup? I would think you would pool those connections just like you would a typical database and keep them around for approximately forever. Then they wouldn't have spammed memcache with so many connections in the first place...

(edit: ah, it looks like they do use a pool, but perhaps the pool does not have a bounded upper size, which is its own kind of fail.)

[slopinthebag]

Rust's async doesn't have this issue. Or at least, it's the same issue as malloc in an unbounded loop, but that's a more general issue not related to async or threading.

15-20 thousand futures would be trivial. 15-20 thousand goroutines, definitely not.

[floating-io]

I don't know enough about rust to confirm or deny that -- but unless rust somehow puts a limit on in-flight async operations, I don't see how it would help.

The problem is not resource usage in go. The problem is that they created umpteen thousand TCP connections, which is going to kill things regardless of the language.

[verdverm]

case in point, an old HN post about scaling Go to 1M websocket connections

https://news.ycombinator.com/item?id=21865715

[slopinthebag]

Go can scale but only if you sidestep goroutines and use something like https://github.com/lesismal/nbio (which is awesome, highly endorse)

[tombert]

Why does garbage collection make it unsuitable for production use? A lot of production software is written in garbage collected languages like Java. Pretty much the entire backend for iTunes/Apple Music is written in Java, and it's not doing any kind of fancy bump allocator tricks to avoid garbage. In my mind, kind of hard to argue that Apple Music is not "production use".

There are certainly plenty of projects where garbage collection is too slow, but I don't know that they're the majority, and more people would likely prefer memory safety by default.

[madeofpalk]

Based on my experience of Apple Music being pretty bad at streaming music, i would say that it's not ready for 'production use'.

[tombert]

Ok, judging by this job posting [1] it looks like Spotify uses Java as well.

[1] https://www.lifeatspotify.com/jobs/senior-backend-engineer-a...

[slopinthebag]

Everything is understood by comparison. Unsuitable for production use, compared to what is the more apt question.