Rust

I didn't say it's a war or anything like that, I actually like both languages, I just don't see much of a point to Go anymore for my priorities. Look at my final paragraph:

So if syntax matters more than the benefits Rust provides, use Go. But if correctness is more important and you're willing to put up with some verbosity, use Rust.

Go makes many things easy, and that's absolutely a good trait to have. My point is that, long term, it has enough footguns that I'd rather put in the time to use Rust, which will prevent most of those by forcing me to contend with concurrency issues upfront.

If I want something quick, I'll probably use Python. With Python, I have a lot fewer options to screw myself over with concurrency long term, which means worse performance, but I don't need that for something quick.

I think Go makes sense if your project will remain small and focused, performance is really important (but not critical), and you're familiar with it. It's easy to write, easy to deploy, and has a high quality standard library. But long term, it has a lot of footguns that become serious issues as projects get larger.

Generics

Agreed. Go doesn't need generics, what it needs imo are scope guards similar to Rust's Mutex or Python's with. defer is close, but it's too easy to make a mistake. I have longed for deterministic destructors, but Go leans way too heavily on its GC to make that feasible.

Interfaces are good enough in most cases to provide what generics are intended to provide. I think there are problems in the implementation (e.g. interface{}((*int)(nil)) != nil; I've run into something similar way too often), but the concept is fine.

1. I never said Rust is the best language. I just said I don't have a use case anymore for Go, because either I'll want Python or Rust.
2. Yes, and I named some both in my original comment and this one.
3. Again, I don't use Rust for everything. I made that clear I'm my original comment and this one.
4. Yes, Rust's async is a bit tedious, and I mentioned that in my initial comment. However, you also get a lot of help from the compiler to eliminate most tricky concurrency bugs. I think that's a fair price to pay for software that's intended to be maintained long term. Go doesn't, so I can't recommend it for larger projects. Python gets halfway there, so it's good enough for prototyping and smaller projects, so that's what I reach for instead of Go, and that's with using Go for almost 10 years (I started with 1.0).

C++

Yes, I think C++ is actually harmful, I see no value in using it whatsoever. The only reason I think it is still being used is inertia, so many libraries use it that it just has the lowest barrier to getting started. But that's not a very good sales pitch (use C++ because everyone else does!).

I much rather write in C than C++ because at least that way I know I'm not likely to make assumptions that do not hold, so I'm much more careful.

Rust sucks at async and multithreading

That's just not true. It's perhaps the best language I've ever used for async and multithreading, and I've used plenty.

But I seem to be looking for something different than you. I want correctness so I don't have as many tricky concurrency bugs to contend with in production, and I'm fine with development being a bit slower to get that. Async and multithreaded Rust can still have bugs, but at least not concurrent modification bugs.

You seem to be looking for quick prototypes, and Rust won't give you that. That said, Rust has gotten a lot better in terms of async ergonomics in the last year or two, and I've found it incredibly productive for my async-heavy projects that the difference between prototype and production code isn't that large. Once I noticed the kinds of issues that the borrow checker catches, I adjusted how I structure the code to be more provably correct, and I very rarely have compile issues anymore.

Go makes it way too easy to write multithreaded code, to the point where it's easy to assume things are correct when they aren't. Go is technically memory safe, but only in a "we'll protect the system from your mistakes" sense and not a "we'll help you avoid the mistakes" sense. Python is also memory safe, and it comes at the problem by making it difficult to write multithreaded code in the first place. That's absolutely fine for prototyping.