The tradeoff is between performance, safety and ergonomics. With GC languages you lose the first one.
That's a myth that just won't die. How is it that people simultaneously believe
1) GC makes a language slow, and
2) Go is fast?
Go's also isn't the only safe GC. There are plenty of good options out there. You are unlikely to encounter a performance issue using one of these languages that you could resolve only with manual memory management.
Easy one: either not the same people, or people holding self contradicting thoughts.
GC are slow not only because of scanning the memory but also because of the boxing. In my experience, 2 to 3 times slower.
Still a better tradeoff in the vast majority of cases over manual memory management. A GC is well worth the peace of mind.
Not every GC boxes primitives. Most don't.
I think people that talk about GC'd languages being slow are usually not building Rails or Django apps in their day to day.
Go can be made to run much faster than C.
Especially when the legacy C code is complex and thus single threaded, Go's fabulous multicore support means you can be exploiting parallelism and finishing jobs faster, with far less effort than it would take to do it in C.
If you measure performance per developer day invested in writing the Go, Go usually wins by a wide margin.
Not literally the case.
> If you measure performance per developer day invested in writing the Go, Go usually wins by a wide margin.
I can accept that performance/hour-spent is better in Go than C, but that's different from Go's performance ceiling being higher than C's. People often confuse ceilings with effort curves.
It's plenty fast compared to commonly used languages such as JS, PHP or Python, but can easily be let in the dust by Java and C#, which arguably play in the same court.
And AOT-compiled, no GC languages like C++, Rust or Zig just run circles around it.
You are comparing quality of implementation, not languages.
But comparing languages in a vacuum has 0 value. Maybe some alien entity will use physic transcending time and space to make TCL the fastest language ever, but right now I won't be writing heavy data-processing code in it.
For example, comparing languages with LLVM based implementations, usually if the machine code isn't the same, reveals that they aren't pushing the same LLVM IR down the pipe, and has little value for what the grammar actually looks like.
Because that's implicit at this point – I'm not going to prefix with “because Earth geometry is approximately Euclidian at our scale” every time I'm telling a tourist to go straight ahead for 300m to their bus station.
Just like when people say “C++ is fast”, of course they refer to clang/g++/msvc, not some educational university compiler.
Of course the authors of many of such comments aren't to blame, they only know what they know, hence why https://xkcd.com/386/
There are always going to be problem sets where the GC causes significant slowdown.