> 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.
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.
At the same time, comparing without acknowledging that it is an implemenation issue, it is also not being fully honest.
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.
> comparing without acknowledging that it is an implemenation issue
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.
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.
> 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.
CLU, Cedar, Modula-2+, Modula-3, Oberon, Oberon-2, Oberon-07, Active Oberon, Component Pascal, Eiffel, Sather, BETA, D, Nim, Swift, C#, F# are all examples of GC based languages with value types that can be used without any kind of boxing.
Impressive erudition and interresting list of nice languages, some of which I'd never heard about, thank you.
Yes indeed not all GCed languages suffer from mandatory boxing. I've been both picky and wrong, which is not a nice place to find oneself in :)
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.