Why Go and Rust are not rivals, but damn enemies
Note A translator is just a translation of an article that reflects an alternative point of view on the topic “Go vs. Rust”. It is not necessary to show your disagreement with the opinion of the author on the translator’s karma, thank you.
This article is a short answer to Dave Cheney ’s blog post “Why Go and Rust are not rivals . ” I highly recommend you read his arguments! You will probably also enjoy the great discussion on Reddit.
In fact, Go and Rust solve the same problem: both came to our world to make the life of programmers easier. Go to ugliness simplified the concept of competitive (aka multi-threaded) programming and it seems to me that it made programming a pleasant experience, because the code on Go is really nice to read. At the same time, Rust gave us powerful zero-cost abstractions ... for pattern matching. Sounds justified, doesn't it? Jokes, jokes, but Rust really made many difficult things easier (a common misconception: he didn't get rid of them). His diabolical type system allows you to guarantee the safety of memory, and including, get rid of the state of the race, which sounds very tempting.
If my memory serves me, Rob Pike (Go language dad) once said that he was very surprised at how everything turned out. Go thought of as a lifeline for C / C ++ programmers, but in the end, people began to think of it as an alternative or even a replacement for Ruby or Python! I think it's just awesome, it could not turn out better.
')
Well, then what does Go have to do with Rust? Rust looks like a powerful and safe replacement for C ++, which, as it turned out, has little to do with Go. Then why do these guys compete at all? Peace, friendship, cookies! But nooooo:
Those who believe that the biggest problem of C ++ is its “unsafe” nature (let's forget for a moment about smart pointers from the latest standards, which by their nature are quite safe) are very much mistaken. The biggest problem with C ++ is that the code in this language is hard to write, read, debug, profile and maintain. In fact, there are several known ways to achieve secure memory management. Ask C programmers for C ++, this is an imaginary problem!
Again, C ++ programs are hard to read, write, debug, and maintain. And this has little to do with memory management! Rust is no different from C ++. And you cannot solve this problem by multiplying entities, adding more and more concepts. Here Go's very cool: “less” exponentially “more” ( less is exponentially more ).
That Go, that Rust - both try to make our lives easier, apart from the fact that Go already really encourages its programmers, helping to write readable and easily supported code with a reasonable number of abstractions, while Rust is hunting for the great and terrible problem of Memory Management . Go and Rust will always be blood enemies and it is somewhat sad to admit that the latter has already lost this war.
This article is a short answer to Dave Cheney ’s blog post “Why Go and Rust are not rivals . ” I highly recommend you read his arguments! You will probably also enjoy the great discussion on Reddit.
In fact, Go and Rust solve the same problem: both came to our world to make the life of programmers easier. Go to ugliness simplified the concept of competitive (aka multi-threaded) programming and it seems to me that it made programming a pleasant experience, because the code on Go is really nice to read. At the same time, Rust gave us powerful zero-cost abstractions ... for pattern matching. Sounds justified, doesn't it? Jokes, jokes, but Rust really made many difficult things easier (a common misconception: he didn't get rid of them). His diabolical type system allows you to guarantee the safety of memory, and including, get rid of the state of the race, which sounds very tempting.
If my memory serves me, Rob Pike (Go language dad) once said that he was very surprised at how everything turned out. Go thought of as a lifeline for C / C ++ programmers, but in the end, people began to think of it as an alternative or even a replacement for Ruby or Python! I think it's just awesome, it could not turn out better.
')
Well, then what does Go have to do with Rust? Rust looks like a powerful and safe replacement for C ++, which, as it turned out, has little to do with Go. Then why do these guys compete at all? Peace, friendship, cookies! But nooooo:
Both languages appeared about the same time; both crap, how ambitious;
Both appeared so that we could more easily write reliable software;
Applications often overlap (server software, system utilities, etc.).
Those who believe that the biggest problem of C ++ is its “unsafe” nature (let's forget for a moment about smart pointers from the latest standards, which by their nature are quite safe) are very much mistaken. The biggest problem with C ++ is that the code in this language is hard to write, read, debug, profile and maintain. In fact, there are several known ways to achieve secure memory management. Ask C programmers for C ++, this is an imaginary problem!
Again, C ++ programs are hard to read, write, debug, and maintain. And this has little to do with memory management! Rust is no different from C ++. And you cannot solve this problem by multiplying entities, adding more and more concepts. Here Go's very cool: “less” exponentially “more” ( less is exponentially more ).
That Go, that Rust - both try to make our lives easier, apart from the fact that Go already really encourages its programmers, helping to write readable and easily supported code with a reasonable number of abstractions, while Rust is hunting for the great and terrible problem of Memory Management . Go and Rust will always be blood enemies and it is somewhat sad to admit that the latter has already lost this war.
Source: https://habr.com/ru/post/262841/
All Articles