3 ms·
You can't expect a program in Go to compete with Rust or C++. When they say it's "fast" they mean relative to something like Python.
by intelVISA 3y ago
You can't expect a program in Go to compete with Rust or C++.
When they say it's "fast" they mean relative to something like Python.
- dathinab 3y agoI don't think language comparisons make sense here as a ton of performance is application dependent. So when it says it's "fast" it should be "fast" compared to many but not necessary all alternative similar software ignoring any language (which it probably is, some of the alternatives are not fast even through they are written in C AFIK). Through in this case I would say it being "fast enough" for many use-cases is the relevant part.
- diarrhea 3y agoI was under the impression GCed languages aren’t necessarily slower than non-GC. Rust still cleans up after itself (RAII and destructors). The difference is in latency, predictability and perhaps total memory use; but not actual speed, I thought.
- steveklabnik 3y agoThe part you're missing is secondary effects of designing a language around GC. Most of the time, that means that everything is heap allocated. So even if a GC and RAII-style management did the same amount of work (and they generally don't, GC's often do less when allocating, for example) while doing allocation/deallocation, non-GC'd languages tend to allocate less in the first place. Additionally, if we're talking about overall performance, indirection can be quite bad on cache locality, so it's not even purely about the speed of allocation/deallocating, but about pointer chasing. Some GC'd languages also offer tools to manage these problems, of course, all I mean to say is that there are a lot of factors at play here.