3 ms·
I had one experience with Go. It was slow because the GC kept kicking in. So we won’t use Go again in favor of time-tested C++. GC is a major reason we are usin
by BenFrantzDale 4y ago
I had one experience with Go. It was slow because the GC kept kicking in. So we won’t use Go again in favor of time-tested C++. GC is a major reason we are using C++ over Go. In my mind it’s a half-speed language. I’m also very put off by Rob Pike’s “Look, we replaced C++!” attitude when he somehow doesn’t seem to grok zero-cost abstractions. C++ has plenty of issues, but it doesn’t have GC and it goes further, providing standard allocators: both PMR for convenience and most use cases, and statically, for truly zero runtime cost.
- hbogert 4y agoRob pike said they intended to replace c++, that didn't happen to his own accord.
- BenFrantzDale 4y agoRight. It seems like they set out to replace some misunderstood or outdated view of C++. They’ve clearly had success, but it’s no C++ successor.
- funny_falcon 4y agoI haven't seen Go's hit larger than 25% in our production. Usually that means we have to keep average CPU load below 70%. (Since GC cames once in several minutes, it is usually not seen in per-minute averages) That is ok for us, since Go significantly boosts development compared to stricter language. It is "marketplace" thing, so we have enough money to spend on additional 50% servers compared to "extremely efficient No-GC" solutions. It all depends.