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