> Very nice multi-threading via Go routines and channels. Impressive semantics in simple syntax, requiring no synchronization mechanism on the user side.

Except for all the times they are required and Go doesn’t tell you: https://eng.uber.com/data-race-patterns-in-go/

Go’s fundamental semantics are standard not-safe shared-memory multi threading. It provides an mpmc queue as a built-in out of necessity (since no generics originally, which would have made for an awkward situation), but really the only thing that’s notable about it is `select`, not `go` or `chan`.

In in some ways `go` is even a downgrade from other languages: you can’t get a handle on the goroutine and thus have to muck around with side-channels to even know that a subroutine has terminated let alone get its result.

>In in some ways `go` is even a downgrade from other languages: you can’t get a handle on the goroutine and thus have to muck around with side-channels to even know that a subroutine has terminated let alone get its result.

You sound like you don't know why they explicitly refuse to add the ability to get a handle on the goroutine. If you do know, you are misleading people by omitting it.

My thoughts on your thoughts:

* Go also includes the complete build system, package management (although it wasn't there from the beginning), code documentation, testing and fuzzing. Also the standard library is much more extensive than in Rust ("batteries included").

* Doctests: since you mention them explicitly, Go has those too: https://go.dev/blog/examples

* "Large garbage collector penalty": that obviously depends on your application and what you consider acceptable. I would say that in most cases the easier development enabled by having GC is worth it, but YMMV. Here's a discussion on the Go garbage collector: https://news.ycombinator.com/item?id=12042302

Wow, very nice! I didn't know that. I love how the language is evolving, it also now has generics.

> slow to compile

In my experience it's the slowest language to compile ever, and the binaries generated are gargantuan.

I was super excited to learn Rust, but that excitement is now 100% gone.

Binary size very much depends on your settings. Rust does not optimise for a small 'hello world' by default, but it's very possible to get small binaries from it if that's a priority for you (for example, the default debug build neither optimizes for size nor strips debug information, as well as statically linking the standard library). Compile times are more sticky problem and most ways to improve it basically involve avoiding certain language features and libraries.

I wonder what other languages you have experience with. C++ is obviously not one of them.

Same. I was about to jump into learning Rust and make it my no.1 language for new projects instead of node.js + TypeScript, but once I learned about the slow compile times I stopped that thought immediately.

For me it was a choice between slow compile times now when it’s safe, or unbounded time solving security and stability issues later when it’s critical.

How "large" is the garbage collector penalty? My understanding is that the Go GC is significantly more efficient than for example JS's mark/sweep approach. Apples to oranges for sure, but I am interested in better understanding how expensive the Go GC is vs Rust performance.

Check out the discord article I posted in the original reply.

If I interpret the graphs correctly, I see:

Golang:

* baseline 20% cpu + spikes to 35% once the GC runs.

* response times of about 1ms + spikes up to 10ms.

Rust:

* baseline 12% cpu + flat, no spiking.

* response times of 20us + flat, no spiking (!).

In terms of scaling, I interpret the results in favor of Rust.

My reasoning is the more you run the GC, the bigger the penalty.

The question here is how much can you disambiguate between the impact of GC and the impact of differently written code plus differently optimizing compiler backend (where Go is still very simple but Rust uses LLVM). If for example the Go code used goroutines and channels in those places where the rewritten Rust code uses asynchronous operations, that alone may account for substantial differences in performance.

Posting links to his blog post is misleading in 2022. The issue they mention in their blog was fixed so it's not an issue now.

That's interesting. Would like to read about the solution more. Do you have a reference?

Just read that article; very informative.

The TLDR is that, especially during GC, P99s and response times are notably worse in Go than Rust. Makes sense.

Go’s GC is not efficient, it is responsive. That is, it trades throughput (and performances, and efficiency) for small pauses and concurrency.