I don't think the tribalism is even really in the language communities themselves as much as it is among onlookers, casual users, or otherwise fans of either language. (Note that there is certainly plenty of enthusiasm for each language in its respective community).
Rust in particular seems to have a large following of people who aspire to use it but haven't really learned it or used it in anger (this especially used to be the case). Basically they (like me) appreciate the ideas of strong static guarantees, strong performance characteristics, and the general aesthetic of Rust code compared to other high-performance languages or other "functional languages".
But those people (and to a lesser extent, many in the Rust community proper) tend to believe that Rust is optimal for those use cases that are conventionally considered to be Go's purview, which is to say they believe Rust is more productive than Go, Python, Ruby, Java, etc for the sorts of applications that those languages are regularly used for (SaaS application backends and other network services). They argue that you just need a little more experience with Rust and you will hit some productivity nirvana; however, each year, I (and many others with experience in this domain) get another year of experience with Rust (as a hobbyist--not full-time development) and still I'm far more productive in Python and Go than I am with Rust.
And I don't think the "just need a little more experience" argument holds water. It's based on the idea that the borrow checker and memory management in general become progressively more natural. Well, I have a decade of C and C++ experience and manual memory management is very natural (almost said "super natural") to me, and the trend is asymptotic--with more experience you do indeed get better with the borrow checker and memory management, but it never quite reaches the point where it's in the same ballpark as a garbage collector (where you truly don't need to think about memory management outside of hot spots).
Of course, GC languages also don't help you deal with race conditions, but 99% of the code we write in these domains isn't subject to race conditions (and if you are writing something that is pervasively subject to race conditions, it might well be worth considering Rust).
Note that there are a handful of very smart, well-respected (and deservedly so) people who also have lots of experience with Rust and who are familiar with the domain in question who disagree with me. I think theirs is the niche opinion, but I think it's worth hearing them out and forming your own opinion.
I agree; however, a point of clarification: If you model the resource as an object then the ownership system precludes concurrent use of that resource within the process (the ownership analog for RAII). However, if you have multiple processes attempting to access the same resource, then no, of course those static guarantees don't help, and (perhaps to your implicit point) this multihost/multiprocess model is the more common case in saas applications.
Rust in particular seems to have a large following of people who aspire to use it but haven't really learned it or used it in anger (this especially used to be the case). Basically they (like me) appreciate the ideas of strong static guarantees, strong performance characteristics, and the general aesthetic of Rust code compared to other high-performance languages or other "functional languages".
But those people (and to a lesser extent, many in the Rust community proper) tend to believe that Rust is optimal for those use cases that are conventionally considered to be Go's purview, which is to say they believe Rust is more productive than Go, Python, Ruby, Java, etc for the sorts of applications that those languages are regularly used for (SaaS application backends and other network services). They argue that you just need a little more experience with Rust and you will hit some productivity nirvana; however, each year, I (and many others with experience in this domain) get another year of experience with Rust (as a hobbyist--not full-time development) and still I'm far more productive in Python and Go than I am with Rust.
And I don't think the "just need a little more experience" argument holds water. It's based on the idea that the borrow checker and memory management in general become progressively more natural. Well, I have a decade of C and C++ experience and manual memory management is very natural (almost said "super natural") to me, and the trend is asymptotic--with more experience you do indeed get better with the borrow checker and memory management, but it never quite reaches the point where it's in the same ballpark as a garbage collector (where you truly don't need to think about memory management outside of hot spots).
Of course, GC languages also don't help you deal with race conditions, but 99% of the code we write in these domains isn't subject to race conditions (and if you are writing something that is pervasively subject to race conditions, it might well be worth considering Rust).
Note that there are a handful of very smart, well-respected (and deservedly so) people who also have lots of experience with Rust and who are familiar with the domain in question who disagree with me. I think theirs is the niche opinion, but I think it's worth hearing them out and forming your own opinion.