3 ms·

From the article > This is especially true when it comes to the more complicated ones like moves and futures, but also true for simpler ones like borrows. What

by epage 8y ago

From the article > This is especially true when it comes to the more complicated ones like moves and futures, but also true for simpler ones like borrows. What I didn’t know when I wrote about it in frustration a month ago is that it doesn’t take a little longer longer to be effective in Rust compared to other languages, it takes 10 to 20 times longer. I think futures might be exacerbating the authors problems. There was a recent post [0] that does a good job explaining why futures are so hard and how the in-progress async/await features fix it. [0] https://aturon.github.io/2018/04/24/async-borrowing/ https://aturon.github.io/2018/04/24/async-borrowing/

Animats 8y ago
Too many articles about Rust talk about why the current language sucks, but some feature in progress will fix it. Rust started out with roughly the complexity level of C++, and it's become more complex from there.
- lossolo 8y ago
  I agree with both of your comments, I've noticed exactly the same thing. Every feature that fix something brings more complexity and have probability that will not interact nicely with some other features which means you need to make another feature that will fix that and then that feature... Soon people will use different dialects of the language like in C++ and like in C++ only few will be able to say that they really know the language. How will managing huge enterprise projects will look like in future? With average developers maintaining it and not language experts like in case of Mozilla Servo? Time will tell I suppose. I am little bit pessimistic but I hope to be proven wrong.
- dbaupp 8y ago
  Every time you say this, someone rebuts you, or asks you to explain, but you seem to completely ignore any feedback. Could you be more specific? Rust has nowhere near the incidental complexity of C++: there's so many features/syntaxes in C++ that have surprising interactions. For various reasons (such as not aiming for direct C compatibility), Rust has been able to avoid those for the most part. Even just initialization syntax in C++ is complicated. For instance, what does this print? #include <iostream> #include <string> #include <vector> class Foo { public: Foo(int a) { std::cout << "Foo " << a << std::endl; } }; int main() { Foo paren(0); Foo brace{0}; std::vector<int> int_paren_0(0); std::vector<int> int_brace_0{0}; std::vector<int> int_paren_2(2); std::vector<int> int_brace_2{2}; std::cout << "int_paren_0 " << int_paren_0.size() << std::endl; std::cout << "int_brace_0 " << int_brace_0.size() << std::endl; std::cout << "int_paren_2 " << int_paren_2.size() << std::endl; std::cout << "int_brace_2 " << int_brace_2.size() << std::endl; std::vector<std::string> string_paren_0(0); std::vector<std::string> string_brace_0{0}; std::vector<std::string> string_paren_2(2); std::vector<std::string> string_brace_2{2}; std::cout << "string_paren_0 " << string_paren_0.size() << std::endl; std::cout << "string_brace_0 " << string_brace_0.size() << std::endl; std::cout << "string_paren_2 " << string_paren_2.size() << std::endl; std::cout << "string_brace_2 " << string_brace_2.size() << std::endl; } Trick question! It segfaults, because string_brace_0 (and only that one, not even string_brace_2) is trying to be a vector of size 1 with an element constructed using the std::string(const char *) constructor (i.e. the 0 literal is becoming a null pointer to pass to that constructor), and this calls strlen on a null pointer. If the string_brace_0 stuff is removed, it prints Foo 0 Foo 0 int_paren_0 0 int_brace_0 1 int_paren_2 2 int_brace_2 1 string_paren_0 0 string_paren_2 2 string_brace_2 2 That is, constructing Foo is the same with () or {}, constructing vector<int> with () is different to {} (the latter uses the explicit initializer_list constructor), and constructing a vector<string> with () is different to {} sometimes, and the same other times! Unfortunately, random interactions like this aren't an isolated occurrence in C++ (especially due to C compatibility stuff, but it can't be avoided even using only "modern C++" constructs, as above): I suspect if you name any feature of Rust, someone will be able to demonstrate that the equivalent part of C++ is significantly more complicated to use[1]. That is, C++ is probably more complex than Rust on a per-feature level, not just some nebulous whole-language complexity. [1]: The borrow checker is possibly the only thing that this doesn't work for, but I think there's a fair argument that it is actually simpler in Rust: a C++ programmer ends up having to do something similar, in their head, with no computer assistance.

by epage 8y ago

Animats 8y ago

Too many articles about Rust talk about why the current language sucks, but some feature in progress will fix it. Rust started out with roughly the complexity level of C++, and it's become more complex from there.

lossolo 8y ago
I agree with both of your comments, I've noticed exactly the same thing. Every feature that fix something brings more complexity and have probability that will not interact nicely with some other features which means you need to make another feature that will fix that and then that feature... Soon people will use different dialects of the language like in C++ and like in C++ only few will be able to say that they really know the language. How will managing huge enterprise projects will look like in future? With average developers maintaining it and not language experts like in case of Mozilla Servo? Time will tell I suppose. I am little bit pessimistic but I hope to be proven wrong.
dbaupp 8y ago
Every time you say this, someone rebuts you, or asks you to explain, but you seem to completely ignore any feedback. Could you be more specific? Rust has nowhere near the incidental complexity of C++: there's so many features/syntaxes in C++ that have surprising interactions. For various reasons (such as not aiming for direct C compatibility), Rust has been able to avoid those for the most part. Even just initialization syntax in C++ is complicated. For instance, what does this print? #include <iostream> #include <string> #include <vector> class Foo { public: Foo(int a) { std::cout << "Foo " << a << std::endl; } }; int main() { Foo paren(0); Foo brace{0}; std::vector<int> int_paren_0(0); std::vector<int> int_brace_0{0}; std::vector<int> int_paren_2(2); std::vector<int> int_brace_2{2}; std::cout << "int_paren_0 " << int_paren_0.size() << std::endl; std::cout << "int_brace_0 " << int_brace_0.size() << std::endl; std::cout << "int_paren_2 " << int_paren_2.size() << std::endl; std::cout << "int_brace_2 " << int_brace_2.size() << std::endl; std::vector<std::string> string_paren_0(0); std::vector<std::string> string_brace_0{0}; std::vector<std::string> string_paren_2(2); std::vector<std::string> string_brace_2{2}; std::cout << "string_paren_0 " << string_paren_0.size() << std::endl; std::cout << "string_brace_0 " << string_brace_0.size() << std::endl; std::cout << "string_paren_2 " << string_paren_2.size() << std::endl; std::cout << "string_brace_2 " << string_brace_2.size() << std::endl; } Trick question! It segfaults, because string_brace_0 (and only that one, not even string_brace_2) is trying to be a vector of size 1 with an element constructed using the std::string(const char *) constructor (i.e. the 0 literal is becoming a null pointer to pass to that constructor), and this calls strlen on a null pointer. If the string_brace_0 stuff is removed, it prints Foo 0 Foo 0 int_paren_0 0 int_brace_0 1 int_paren_2 2 int_brace_2 1 string_paren_0 0 string_paren_2 2 string_brace_2 2 That is, constructing Foo is the same with () or {}, constructing vector<int> with () is different to {} (the latter uses the explicit initializer_list constructor), and constructing a vector<string> with () is different to {} sometimes, and the same other times! Unfortunately, random interactions like this aren't an isolated occurrence in C++ (especially due to C compatibility stuff, but it can't be avoided even using only "modern C++" constructs, as above): I suspect if you name any feature of Rust, someone will be able to demonstrate that the equivalent part of C++ is significantly more complicated to use[1]. That is, C++ is probably more complex than Rust on a per-feature level, not just some nebulous whole-language complexity. [1]: The borrow checker is possibly the only thing that this doesn't work for, but I think there's a fair argument that it is actually simpler in Rust: a C++ programmer ends up having to do something similar, in their head, with no computer assistance.