GO uses a garbage collector because it has to: removing this GC fundamentally complicates parallelism. If it’s manual management, then who owns the data? Of course there are ways to work around, but none of them are free; in fact those can be even more expensive.
Assuming it enforces single ownership, then the allocator is responsible for freeing resources. How can it know the resource can be freed, if the resource is processed in another thread? Inter-thread communication? The complexity will be insane. Pass ownership? There’s no move semantic in GO. Reference counting? No such a thing in GO either.
I even have a feeling that those 1.1k stars are fake.
Concurrency without parallelism is just like Python/JS, a single thread drives all the coroutines, and it’s the easier one, as the runtime doesn’t really need to lock.
GO on the other hand has parallelism. It maps goroutines to a thread pool, which requires locking, making things more complicated.
This is also why Rust has two types of reference counting, Rc and Arc.
How can you even hint at anything being fake? The repo is 6 (six!) months old and has one whole contributor, 2 issues and 1 PR. Cleary a large community of stargazers and a perfect language.
If you want memory safety without garbage collection your option is Rust.
There are no other options. Go is fast but the garbage collection technically makes it a soft real time system (or rather it cannot be used for hard systems).
This AI slop is so baffling.
GO uses a garbage collector because it has to: removing this GC fundamentally complicates parallelism. If it’s manual management, then who owns the data? Of course there are ways to work around, but none of them are free; in fact those can be even more expensive.
Assuming it enforces single ownership, then the allocator is responsible for freeing resources. How can it know the resource can be freed, if the resource is processed in another thread? Inter-thread communication? The complexity will be insane. Pass ownership? There’s no move semantic in GO. Reference counting? No such a thing in GO either.
I even have a feeling that those 1.1k stars are fake.
Concurrency isn’t parallelism
True, and that’s exactly why I said parallelism.
Concurrency without parallelism is just like Python/JS, a single thread drives all the coroutines, and it’s the easier one, as the runtime doesn’t really need to lock.
GO on the other hand has parallelism. It maps goroutines to a thread pool, which requires locking, making things more complicated.
This is also why Rust has two types of reference counting, Rc and Arc.
How can you even hint at anything being fake? The repo is 6 (six!) months old and has one whole contributor, 2 issues and 1 PR. Cleary a large community of stargazers and a perfect language.
/s
If you want memory safety without garbage collection your option is Rust.
There are no other options. Go is fast but the garbage collection technically makes it a soft real time system (or rather it cannot be used for hard systems).