> It might be counterintuitive, but garbage collectors in multithreaded code can be very efficient.

What has garbage collector to do with multithreaded code? Once you have two or more threads which needs to share data, they need to sync and you'd end up using some kind of lock, which will affect the performance. GC doesn't make anything efficient or less efficient here. It might make the code simpler as you don't have to worry about allocation/deallocation, but I don't see how it's magically going to remove the lock.

No, you don't. All you need is to create a folder `bin` and any file with `main` fn in it will create a binary.

And tell me how that pointer semantics would do * a very strict type checking * Pattern matching * Algeberic data type

Plenty of people don't write Rust for additional memory safety, they write Rust because the features provided by it is overall very balanced & encourages developer to write code which handles almost all edge cases.

This, from my limited experience working on AOSP at Google, only the newer code were being written in Rust, not the existing code. But that was 2 years ago.

I agree with simplicity and ease of learning Go.

> 3 years working with I might have had at most 3 times nil pointer crashes in prod

I've been running a rust app for my personal trading app and a small service at a very large FAANG company for more than 3 years, and guess what I'm yet to see a nil crash.