This article is a little response to Dave Cheney’s blog post “Why Go and Rust are not competitors”. I highly recommend to give it a read! You also might enjoy a related lovely discussion on Reddit.
In fact, both Go and Rust solve exactly the same problem: both came here to make our lives easier. Go made concurrent programming easy as ABC and from my perspective, made programming kinda fun, since Go code is a pleasure to read. In the meantime, Rust gave us a powerful zero-cost abstractions for pattern matching. Sounds reasonable, ain’t it? Jokes aside, Rust made tricky things easier (a common misconception: it didn’t make it dissapear). Its devil’s type system gives you guaranteed memory safety and ability to get rid of data races, which sounds soopa doopa attractive.
IIRC, Rob Pike (Go’s daddy) once said he was surprized how the things turned out. Go was expected to become a lifebuoy for C++ programmers, but eventually people started thinking of it as of replacement for Ruby/Python. In my humble opinion, that’s great, it couldn’t turn out better!
Alright, so what does Rust have to do with Go? Rust seems like a solid and safe replacement for C++, what hardly has anything to do with Go. So why would you want them to compete?
- Both appeared at the relatively same time, both brand new;
- Both came here, so we could be able to write reliable software;
- Areas of application do heavily overlap.
For those of you who think that the biggest problem of C++ is its “unsafe” nature (let’s forget, for a while, that modern C++ programming is based on smart pointers, which are safe) are wrong. The biggest trouble in C++ is that the code is hard to read, maintain and debug. There are couple of ways to achieve safe memory management in C++. Believe it or not, it’s rather an imaginary issue.
Software in C++ is hard to read, maintain and debug. It hardly has anything to do with memory management. Rust is no different. You wouldn’t solve this major issue by introducing way more new entities, you’d make it even worse. Go does an awesome service here: less is exponentially more.
tl;dr: Both Go and Rust try to make our lives easier, except the fact that Go actually benefits its developers, by helping them to produce a readable and easy-to-maintain source with justified amount of abstractions, when Rust, in the meantime, hunts an imaginary issue of memory management. Go and Rust will always be sworn enemies, though the last one has already lost it.
