4 ms·
Not really that surprising. I spent a good chunk of time trying to make a Go program as fast as a well written Rust one (tokei) which I wrote about here https:/
by boyter 8y ago
Not really that surprising. I spent a good chunk of time trying to make a Go program as fast as a well written Rust one (tokei) which I wrote about here https://boyter.org/posts/sloc-cloc-code/ https://boyter.org/posts/sloc-cloc-code/ and in the end the GC was what held me back.
I suspect its possible to get Go programs for the most part close to the performance of Rust but in the end the lower level and fewer abstractions mean a well written Rust or C/C++ program will almost always be faster.
I wonder how different these benchmarks would be if the Go runtime was set to have GC disabled though. A fairly simple thing to try out and see.
- ashleyn 8y agoGC at the systems level is an idea that has had its chance. 40 something years out, and we all mostly use C, with Rust being the only contender to knock it off its perch. It's probably time to give up the dream; GC is only good if you're willing to assume the always-moderate cost of its implementation, relegating it to scripting languages.
- PopsiclePete 8y agoGo doesn't really play in the "systems level" field all that much, tho. They even removed the "systems" bit from the Go home page. Go doesn't compete with C, unless C was the wrong choice to begin with. Nobody is writing an OS in Go. It competes with Python and Node. I've reduced my Python/Node code by roughly 92.5% after Go reached 1.0 and I couldn't be happier.