| GO v. Rust is a tough compare and kind of a bad question. I work in a very large C/C++ organization and the build concern over our 1000s of libraries is a giant chore to do well in a DEVOPS context. GO is so much better. RUST is routinely seen worse than GO here. Compilation is slow but anecdotally dependency management in RUST is orders of 10 better that C/C++ and comparable to GO. There are a few stories in HN where cloud providers, big data types have been burned by GC. But it's not routine. Their ability to find and fix root cause required in-depth diagnostics. If your system is complex your tooling better have good support there. GO definitely does. Here's what I say: if you are I/O bound GO is just fine. GO has great libraries for all manner of HTML/socket work. It works well with protobuf, compression, REST APIs, UUIDs. Its SQL library is great. If you are low latency bound or need latency in a narrow range you'd better do a POC in GO and RUST and make an informed choice. There's plenty of GO programmers and fewer good RUST programmers. There are more HN posts from people learning RUST reporting the borrow aspect of RUST is tough to learn and tougher to do right. RUST kind of memory management isn't routinely found in other languages. RUST is meant to be a better C++. It's meant to excel in the niche area of system like libraries by yielding C/C++ performance without memory C/C++ memory problems which are perhaps the largest security attack area. RUST will not remove all data races. It reduces them - which is good - but do not over interpret. In this sense RUST is smart: they've picked a good market, and their tools make good sense there. C++ is not necessarily the go-to for bare metal programming. So neither would RUST be. Most of the Linux kernel is C not C++, for example. We know that calling C-libraries from a non-C language is routine. To RUST? Not sure. To C++? That's a harder ask but you're probably not the only one who's doing it - at least that. |