I found GO looking for a better way to handle concurrency and errors - at the time I was working in a JS ecosystem and anytime I heard someone talk about golangs error handling, my ears would perk with excitement.

So many of my debugging journeys started with `Cannot access property undefined`, or a timezone issue ... so I've never complained about gos error handling -- to much is better than not any (js world) and I need to know exactly where the bug STARTED not just where it crashed.

The concurrency model is exactly what I was looking for. I spent a lot of time working on error groups, waitgroups and goroutines to get it to click; no surprises there -- they are great.

I grew to appreciate golangs standard library. I fought it and used some libs I shouldn't have at first, but realized the power of keeping everything standard once I got to keeping things up to date + maintenance; Ive had solid MONTHS to update a 5y/o JS codebase.

What TOTALLY threw me off wasgolangs method receivers -- they are fantastic. Such a light little abstraction of a helper function that ends up accidentally organizing my code in extremely readable ways -- I'm at risk of never creating a helper function again and overusing the craaaap out of method receivers.

Thanks for taking the time to listen to me ramble -- I'm still in my litmus test phase. HTTP API, with auth, SSE and stripe integration -- typical SAAS; then after, a webstore type deal. Im having a great time over here. Reach out of you have any advice for me.

My understanding is after a GC the spans which have no reachable objects are marked as idle and remain with the go process for future allocations. This is leading to overall memory usage of the process to be high by 50% that wants needed.

I want to understand by default when does the go process return the idle memory to the OS?