4 ms·

I really enjoyed using Go in my Distributed Systems course in college, and I've enjoyed using it as a replacement for Python for little scripts I've written sin

I really enjoyed using Go in my Distributed Systems course in college, and I've enjoyed using it as a replacement for Python for little scripts I've written since the typed aspect of it makes it easier for me to go back and read what I've done. But, I have not enjoyed the Go micro service we use at work. We went with Go thinking the coroutine thread implementation would significantly improve performance over a Java microservice, but the service turned out to be GC limited. And the overall lack of support for most language features has made this codebase much larger than it needed to be. I wish I could convince my team to try Rust for our next service

derefr 6y ago
> but the service turned out to be GC limited Go indeed has a lousy GC (compared to the JVM, at least.) This is why, in most production Go codebases I've seen, there's heavy reliance on https://golang.org/src/sync/pool.go https://golang.org/src/sync/pool.go (or a NIH knocked-together version of it, if the author doesn't realize sync/pool exists.) Try just switching a few of your most-oft-called constructors to allocate from a pool. It's pretty much the lowest-hanging fruit for Go performance gains.
- likeabbas 6y ago
  Right, but if we go with Rust we won’t have to worry about GC issues