
Allocation Efficiency in High-Performance Go Services - mrbbk
https://segment.com/blog/allocation-efficiency-in-high-performance-go-services/
======
kenhwang
When you need to start worrying about memory allocation control, garbage
collection latency, pointers, byte padding, and CPU instructions per
operation, Go might be not be the best tool for the job anymore. Seems like
Rust might be a better choice here? Instead of reverse engineering what the
compiler might do, then structuring the code in subtle ways to get the
compiler to actually do what you intend to do, why not pick a language that
lets you command the compiler do to what you want?

~~~
blaisio
Garbage collection simplifies but does not eliminate memory management. That's
okay, because even though it does not eliminate the need for memory management
completely, it does still save the programmer from an awful lot of work.

Anyway, the choice of Rust vs Go should not be based on a single factor like
"Rust is not garbage collected". Especially since many common coding patterns
require some form of garbage collection, even in Rust!

~~~
pjmlp
I love the work they are doing in regards to low level systems coding and
safety, but in general a GC + ability to statically allocate feels more
productive, specially as former Oberon user and Modula-3 fan.

------
krakensden
The interface problem seems like something the compiler team should fix or
mitigate. I worry this post is going to cause a lot of premature
restrictionism.

~~~
achille-roussel
I agree, there's area for improvement for the compiler here and hopefully in
the future we won't have to worry about those issues. For now those are
constraints we have to deal with to make our software more efficient
unfortunately.

------
robbles
I noticed there's a go:noescape compiler directive that seems to provide an
escape hatch for a lot of this unexpected compiler behaviour:

[https://golang.org/cmd/compile/#hdr-
Compiler_Directives](https://golang.org/cmd/compile/#hdr-Compiler_Directives)

Does that actually work?

~~~
achille-roussel
go:noescape is meant to be used on functions that are implemented in assembly
because escape analysis only works on Go code. As far as I know a etting this
tag on a function that is implemented in Go has no effect.

