Conversation

Maybe the biggest unanswered question about Rust is how much the borrow checking rules can help performance by improving compiler alias information. (There is some use of noalias but it's not very aggressive yet.) If they do by a lot, that changes the calculus for using Rust...
21
284
Like, if the borrow check helps runtime performance, then why wouldn't you use Rust over alternatives? It'd be safer *and* faster.
5
98
Replying to
Have a newbie write a linked list in rust to see the problem. I'm a fan, but you really have to understand things before you jump in. Obviously we all WANT devs to know their tools before writing a line of code, but other languages can be a bit more forgiving while folks learn.
2
1
Replying to and
Not more difficult to write a correct linked list implementation with Box<T> (singly-linked) or Rc<T> / Weak<T> than malloc in C. Those types exist in C++ as a higher level, easier to use replacement for malloc/new (std::unique_ptr<T>, std::shared_pointer<T>, std::weak_ptr<T>).
1
What do you think happens if you do the same thing in those languages? Try writing a doubly-linked list with std::unique_ptr<T> for both next and prev pointers in C++ you can turn it into a memory corruption (double-free) or other issues if you work around it. It's not easier.
Replying to and
With C you can get a 99% correct solution and feel some level of progress as you learn. This isn't really an option with rust. With C you can work through runtime errors, and with rust you can't even compile. Not all programs need to be 100% correct - especially when learning.
1
Replying to and
That's not how memory corruption works in C at all and it doesn't simply manifest as a 'runtime error'. You seem to be talking about a dynamically typed language like Python, not C. It's in no way easier to do this task at a much lower level where you get incomprehensible bugs.
1
Show replies