garbage collection has to be done, if you don't free after you malloc in C/C++ you can blow up and end up with an OOM panic and be force killed by the kernel
coroutine scheduling only runs a background process when you are running on more than one kernel thread because it tries to parallelise as much as possible
this is one of the other deficiencies of go - if you need to do bulk compute it's better to refactor your processing unit as an independent process and coordinate them with an IPC, i have also done this, the difference is about 20% for compute bound heavy processing (it was a crypto miner) - vanity mining addresses, also, another example of what benefits in Go from this, whereas in languages with explicit access to kernel thread control can do this natively
Replies (3)
Thanks. I am early in learning Go but definitely liking it so far, and I respect the tradeoffs they have made to keep the language simple and performant.
I watch/read a lot of tech content that discusses language features & limitations, but at the end of the day I’m still only an expert in Python and SQL. And I even then, just the data wrangling areas of Python.
I imagine a good data stack being Go for networking and Extract/Load jobs, and then dbt/SQL for data modeling. Probably don’t even need Python until you get into AI/ML.
it truly boggles my mind that python is the AI/ML language when it's literally 10x slower than Go/C/etc
LLMs need to be written in C also, really, so they can be compiled for GPU processing, because they are built from special types of hash collision searches
i'll stick with GC... the cases that need special handling to avoid it interfering with latency are very small and that's a small price to pay for the greatly increased simplicity of the language
