5 ms·
> I'm not sure how you get from 50% slowdown to fast. A mere 50% slowdown over C given Go's ergonomics? That's amazing. Although, you and the parent are talki
by Mawr 5y ago
> I'm not sure how you get from 50% slowdown to fast.
A mere 50% slowdown over C given Go's ergonomics? That's amazing.
Although, you and the parent are talking about different things. He didn't say "Go is 50% slower than C" he said well written Go is up to 50% slower than well written C. I'd expect average Go code to be 100%+ slower than average C code, which is likely what you're talking about.
> That's my point - in the space of ahead-of-time compiled, statically typed languages Go produces code that runs significantly slower than other languages.
That's not the space Go is in. You forgot a huge factor - memory management. Go has a GC and therefore is not anywhere near the same space as C/Rust/C++. Thus, such comparisons are inherently flawed - Go isn't competing on speed with C/Rust/C++, but with Java/C#.
- vegai_ 5y ago>I'd expect average Go code to be 100%+ slower than average C code Sorry to nitpick, but that means the Go code will never complete.
- native_samples 5y agoI didn't forget memory management, point 2 in my list is about the tradeoffs involved in GC. What you and 37ef_ced3 are giving me here is a list of reasons why it's OK for Go to be slow or at least slower than C++, which is fine. Go inhabits a particular point in the design space and it balances performance against other factors - great. My beef was with the statement that Go is known to be "unusually both fast and easy". It's not known for that. It's known to be a sort of middle-ground jack of all trades. If someone told me they were using Go because it was fast, I would think they didn't know much about programming languages, or I'd have to read a lot of context into what they were saying (maybe they only had experience with Python before, as is the case for many Go programmers).