

Understanding go compiler tools (2) - freedrull
http://yugui.jp/articles/865

======
barrkel
Letting the OS free memory at process exit is a very viable approach for
single-purpose tools that don't run a reasonable risk of running out of
memory. (Structs over unions are also more debuggable and less prone to bugs.)

On the other hand, if you ever want to turn what you wrote into a library
instead of a standalone process, not having taken more care over memory
management will hurt.

For compilers, there's often a happy medium available: pool / arena-based
allocation, with one pool per translation unit.

------
chc
For anyone who isn't familiar: Yugui is part of the Ruby Core team, so she
knows a bit about language implementation.

------
pbiggar
I read an estimate that about 40% of programmer time spent writing a C or C++
program goes into memory management. Compilers often don't really need
sophisticated memory management techniques, as they don't run for very long.
Go in particular seems designed to never compile really large compilation
units (like you might in C++).

tl;dr if I was writing a Go compiler, I wouldn't worry about memory management
either.

~~~
stcredzero
What is the world coming to, if three sentences need a tl;dr?

Might some functions behave like some compilers?

~~~
barrkel
The moral equivalent in a function is alloca(), but that can be a fast path to
stack overflow.

