> 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.

▲

shakow 3 days ago | parent | next [-]

Go is not fast though.

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.

▲

pjmlp 2 days ago | parent [-]

Not quite true if using GCC Go as compiler, however they seem to have dropped development after Go got generics.

You are comparing quality of implementation, not languages.

▲

shakow 2 days ago | parent [-]

> 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.

▲

pjmlp 2 days ago | parent [-]

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.

▲

shakow 2 days ago | parent [-]

> 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.

	▲	pjmlp 2 days ago \| parent [-]
		I seriously doubt it, given how many discussions go on HN or similar sites, revealing a complete lack of knowledge in compiler design. 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/

▲

cheshire_cat 3 days ago | parent | prev | next [-]

Go is fast compared to Python or Ruby. Go is not fast compared to C.

I think people that talk about GC'd languages being slow are usually not building Rails or Django apps in their day to day.

▲

on_the_beach 3 days ago | parent [-]

Not a Go programmer I'm guessing.

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.

	▲	quotemstr 3 days ago \| parent [-]
		> Go can be made to run much faster than C. 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.

▲

somanyphotons 2 days ago | parent | prev | next [-]

Go is middle-pack fast, not fast-fast.

There are always going to be problem sets where the GC causes significant slowdown.

▲

rixed 3 days ago | parent | prev [-]

> How is it that people simultaneously believe > 1) GC makes a language slow, and > 2) Go is fast?

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.

▲

quotemstr 3 days ago | parent [-]

> also because of the boxing

Not every GC boxes primitives. Most don't.

▲

rixed 3 days ago | parent [-]

Sure. What about non primitives?

▲

pjmlp 2 days ago | parent [-]

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.

	▲	rixed 2 days ago \| parent [-]
		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 :)