One limitation is that Go doesn’t have the idea of NUMA. Tbh, I do know little or no about this, I’m undecided how related is that this or whether or not that is related in any respect.
One other limitation is rubbish assortment. Your Go program solely have one centralized GC. While you scan for stay object, it locks the entire course of. Go GC is generational GC, which suggests it’s fairly sensible. Object that lives lengthy sufficient received’t be scanned as typically. So, for those who can restrict the variety of short-lived object, you might scale back the GC overhead. However, in an effort to know which object is previous or younger, that you must do some type of bookkeeping everytime you assign to a pointer, which may add overhead to your program as properly.
Channel could be a limiting issue too. Golang’s channel is a builtin language function, so it’s arduous to experiment with that. For instance, let’s say you’ve a greater channel implementation than Golang. Possibly your implementation is healthier in efficiency, however not as generic (possibly it solely permits a single shopper). Effectively, you possibly can’t change golang’s runtime. You may construct your personal multi-producer-single-consumer channel in golang manually utilizing sync.Mutex, and possibly sync.Cond, however then you possibly can’t make your personal mutex.
Or possibly, you’ve your personal scheduler that’s higher than golang’s scheduler. Possibly it’s higher on your usecase. Effectively, you possibly can’t implement it in Golang. The scheduler is already a part of Go. I assume, for those who actually need to attempt, you possibly can clone Go’s supply code, modify the runtime code, and compile it your self, however it’s simply simpler to make use of one other language like C++.
So, I feel for language like C, C++, Odin, Zig, and Rust, there are extra issues you possibly can management. In Go, some issues are already carried out in Go runtime and it’s arduous to alter it.
