At this point, why not just use C?
The benefit of using Go is keeping the memory safety for like 90% of the application, with just a tiny unsafe code portion.
In C, 100% of the source code is unsafe.
On the other hand, if implanting a faster allocator fixes performance problems, then there's something bigger amiss in the overall application design. Creating and destroying small objects at such a high frequency that memory management overhead becomes noticeable isn't a good idea in any case, GC or not.
Is something that not even the Linux kernel with its careful and throughout patch review process is not able to achieve.
The idea that "you can't write safe C" is a big joke. C is as safe as you make it.
https://msrc-blog.microsoft.com/2019/07/16/a-proactive-appro...
https://www.chromium.org/Home/chromium-security/memory-safet...
https://cwe.mitre.org/data/definitions/416.html
https://www.zdnet.com/article/chrome-70-of-all-security-bugs...
Is it perhaps better to focus on context? That is,cost vs benifit wrt context:
- How much safety and what kind and level of safety assurances does the specific application need?
- How much does it cost in development time/friction, application performance, engineering complexity, [insert other relevant cost axes] to achieve the desired level of safety and safety assurances?
Naturally this is a kind of expenses that 99% of the companies aren't going to spend until it finally becomes a legal liability to have security exploits on the software.