[weberc2]

> Go isn't really in the same league as Rust, C++, or C. It's syntax is deceptively C like, and it has an equally poor type system, but it's performance is closer to Java, which is a few orders of magnitude slower than C++. Despite pushing outdated concepts like null and raw pointers on to the programmer, it has a runtime with a stop the world GC with no guarantees about object placement on the stack or heap

Man, stating your opinions as fact is one thing, but every other claim you made above is empirically incorrect. Rust is a fantastic language on its own merits; no need to make stuff up about “the competition”.

[ilovecaching]

> it's performance is closer to Java

Go vs Java https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

Go vs C++ https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

> pushing outdated concepts like null and raw pointers on to the programmer

I mean this is just a fact. Are you disputing nil and *?

> it has a runtime with a stop the world GC

https://blog.golang.org/ismmkeynote

"On the Y axis we have GC latency in milliseconds. On the X axis we have time. Each of the points is a stop the world pause time during that GC. "

> with no guarantees about object placement on the stack or heap

From the F.A.Q.

" How do I know whether a variable is allocated on the heap or the stack?

From a correctness standpoint, you don't need to know. Each variable in Go exists as long as there are references to it. The storage location chosen by the implementation is irrelevant to the semantics of the language."

> but every other claim you made above is empirically incorrect.

Seems you're empirically incorrect.

[weberc2]

The benchmarks game is just that: a game. Notably, Go programs are prohibited from doing certain optimizations that are permissible for C++ programs. The conventional wisdom is that Go and Java are within the same order of magnitude as C++ though still slower. I’d accept that they are a full order slower, but not multiple orders.

> Do you dispute nil and *

I dispute that Go’s pointer is a “raw pointer” in any meaningful sense of the word. In C++, raw pointers may be uninitialized, they may be cast from any int, they don’t imply any automatic cleanup of the pointee, and they are subject to pointer arithmetic—none of this is possible with Go pointers except via the “unsafe” package. So basically none of the criticism of raw pointers applies to Go pointers.

> Go has a stop the world GC

You are correct here, Go has a stw GC. It’s probably not suitable for RTOS, but its pauses are on the order of microseconds, so most of the conventional GC criticism doesn’t apply.

> Stack vs heap

The language doesn’t have semantics for stack vs heap allocation, but that doesn’t mean it’s hard to control where things are allocated. In particular, the compiler can spit out where its allocating and you can adjust accordingly. It’s far easier to do this in the hot path than to have to specify where every piece of memory is allocated across your program.

> seems like you’re empirically incorrect

Quite the opposite, actually. There’s nothing wrong with not knowing or being mistaken, but there’s no need for overt snarkiness.

[igouy]

> The benchmarks game is just that: a game.

The name "benchmarks game" signifies nothing more than the fact that programmers contribute programs that compete (but try to remain comparable) for fun not money.

It's what you make of it.

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

> Go programs are prohibited from doing certain optimizations that are permissible for C++ programs

Which programs? Which "certain optimizations"?

[weberc2]

That benchmarks game quote supports my point (not sure if you quoted it to contradict me or not?). As for prohibited optimizations, arena allocation is the one that comes to mind since it’s the standard way to avoid O(n) allocs.

[igouy]

> That benchmarks game quote supports my point…

As-long-as your point was not intended to be dismissive in any way.

> prohibited optimizations

Go programs are not prohibited from using arena allocation provided by a generally available library — that is what the C++ programs do.

Unfortunately there doesn't seem to be a generally available Go library that provides arena allocation. Of course, Go does provide GC.

[weberc2]

It is dismissive of the idea that the game can tell you meaningful things about a programming language’s average or percentile performance or even its peak performance.

> Go programs are not prohibited...

Right, and this is why the Go benchmarks for allocations aren’t very meaningful. Using arenas (or other kinds of preallocation) is a common optimization in Go even if Go doesn’t have a library for it.

I’m sure you’re well aware of all of this since you evidently contributed to these benchmarks, but for other readers, here’s a good thread about why these benchmarks aren’t meaningful.

[igouy]

> … it's performance is closer to Java …

You seem to be quoting yourself out-of-context ;-)

In full, you wrote — "… but it's performance is closer to Java, which is a few orders of magnitude slower than C++" — and that is not shown by those measurements.