It seems to be a multi-paradigm language like C++. I guess it's advertised for system programming because it's looking for its niche, but I don't see it replacing C for low level stuff due to the learning curve.
It seems to be a multi-paradigm language like C++. I guess it's advertised for system programming because it's looking for its niche, but I don't see it replacing C for low level stuff due to the learning curve.
For example, C++ Core Guidelines [0] is longer than Rust Book. Core Guidelines is itself a great example of things one needs to keep in the head while writing C++ code.
Look at implementation of something as basic as optional<T> [1]. The amount of things one needs to know is so high most C++ developers would never attempt it.
[0]: https://github.com/isocpp/CppCoreGuidelines/blob/master/CppC...
[1]: https://github.com/akrzemi1/Optional/blob/master/optional.hp...
That's actually simpler to do in Nim than you'd think, but I understand what you mean. I might expand my implementation to be const and see how complex it makes it!
C++ has a massive amount of accidental complexity. To mention just two: the difference between () and {} initialisation (for some types) especially in the presence of perfect forwarding, and a set of feature/their interactions that means there's a bug in the following very reasonable looking code (can you find it?):
std::unordered_map<T, U> map;
// ... initialize map ...
const U *selected = nullptr;
for (const std::pair<T, U>& p : map) {
if (condition) { selected = &p.second; }
}
// use selected
(Credit to Effective Modern C++.)Rust may seem more complex because the compiler is noisier, but it is significantly simpler to write correctly: a computer is finding the weirdest bugs.
You are right regarding the C++ accidental complexity though. Issues like the one you highlighted tend to happen when working with pointers. They are very hard to detect during code review (I didn't see it), but I would have rejected the code at review anyway because it should be replaced by std::find. Taking raw pointers into containers is also not reasonable except for vector.
> I would have rejected the code at review anyway because it should be replaced by std::find
That specific example, sure, but there's other ways to have escaping pointers in for loops.
> Taking raw pointers into containers is also not reasonable except for vector.
The map types are explicitly designed to allow taking pointers, e.g.
> References and pointers to either key or data stored in the container are only invalidated by erasing that element, even when the corresponding iterator is invalidated. -- http://en.cppreference.com/w/cpp/container/unordered_map
How many C or C++ programmers will understand this: (1..n + 1).fold(1, |accum, x| accum * x)?
Anyway, I am just offering my opinion as someone doing mostly C++ programming. I have no problem with a language like Swift or Go, but feel that Rust is too complicated for what it offers.
Taking a pointer into containers refers to &p.second. We now have a pointer to an iterator's member variable. That is unreasonable.
The reasonable thing would be to use an interator to keep track of the selected item, this is what they are designed for.
The fix to avoid this is to use auto. If instead of pair, you used auto&& p: map, this would not be an issue