5 ms·

> proving they're implemented correctly never is Let's be clear: Rust is still far away from formal verification; the borrow checker won't save you from logica

> proving they're implemented correctly never is Let's be clear: Rust is still far away from formal verification; the borrow checker won't save you from logical errors. Second, data structures like graphs, trees, hashmaps are well understood and have a lot of algorithms built on top of them. Algorithms with a lot of research behind them, and complexity analysis. While complexity analysis doesn't always equal performance, if I can't use these universal tools in your language, I'll probably think of it as a toy language which stops me from getting stuff done, which is still what most of us are paid for.

unrealhoang 8y ago
Your argument doesn’t make much sense. You can use unsafe and raw pointer to do EVERYTHING you can do in C/C++ and it will be just as safe as you write it in C/C+. And then, you can (ab)use the type system to make sure you or your team cannot use it in the wrong way.
- guitarbill 8y ago
  why would i use rust in the first place if i was disabling the borrow checker? isn't that the main selling point? because of the ecosystem? because it's easier to hire rust programmers than C/C++ programmers, or get more open source contributions from rust vs C/C++? unlikely with a learning curve or community like that.
  - Const-me 8y ago
    Rust only disables these checks very selectively. The idea is good, MS did same in C# since the first version in 2002. Allows to do pointer arithmetic when you really need to, for performance or native interop. What I don’t like about Rust is they use unsafe to workaround language limitations. In C# I have only used unsafe code couple times over the course of 20 years. The standard library doesn’t use unsafe code either, at least in modern .NET all these collections are 100% safe code. The main, safe subset of the language is good enough for the majority of practical applications. In Rust there’s tons of unsafe code in standard library, substantial amount of unsafe code in third-party libraries, and if your software is complex enough, your own code will likely contain usafe as well. This causes safety issues: https://medium.com/@shnatsel/how-rusts-standard-library-was-vulnerable-for-years-and-nobody-noticed-aebf0503c3d6 https://medium.com/@shnatsel/how-rusts-standard-library-was-...
    - steveklabnik 8y ago
      One of the reasons the standard library has a lot of unsafe is that the standard library is small, but one of the criteria for being in the standard library is “uses a lot of unsafe.” We’d rather these things get massive visibility. In all my years with Rust, the only unsafe I’ve needed in any of my applications is when doing FFI, and my toy OS. YMMV.
      - sanxiyn 8y ago
        On the other hand, Rust certainly could use a lot less unsafe in the standard library than it currently does. It just doesn't want to.
- Const-me 8y ago
  > and it will be just as safe as you write it in C C++ standard library containers have guarantees about iterators and pointers invalidation, e.g. std::list never invalidates any of these, unordered_map invalidates iterators when rehashed and never invalidates pointers to either keys or values. This allows building unsafe data structures on top of standard collections, and then compose custom unsafe data structures on top of each other. This makes C++ both safer (at least from memory leaks) and easier to use compared to unsafe rust.
baq 8y ago
> Let's be clear: Rust is still far away from formal verification; the borrow checker won't save you from logical errors. completely agree. > Second, data structures like graphs, trees, hashmaps are well understood and have a lot of algorithms built on top of them. well understood, yes, by authors of textbooks and papers. your average programmer may have understood them once, before he made it to the enterprise and started passing buckets of bits between http endpoints for a living. > Algorithms with a lot of research behind them, and complexity analysis. While complexity analysis doesn't always equal performance, if I can't use these universal tools in your language, I'll probably think of it as a toy language which stops me from getting stuff done, which is still what most of us are paid for. you can write a recursive data structure in Rust in the same way you'd write one in C++ - use unsafe pointers, even the asterisk is the same. nothing is stopping anyone from doing that, in fact there are lots of examples on crates.io and in the stdlib.

unrealhoang 8y ago

Your argument doesn’t make much sense. You can use unsafe and raw pointer to do EVERYTHING you can do in C/C++ and it will be just as safe as you write it in C/C+. And then, you can (ab)use the type system to make sure you or your team cannot use it in the wrong way.

guitarbill 8y ago
why would i use rust in the first place if i was disabling the borrow checker? isn't that the main selling point? because of the ecosystem? because it's easier to hire rust programmers than C/C++ programmers, or get more open source contributions from rust vs C/C++? unlikely with a learning curve or community like that.
- Const-me 8y ago
  Rust only disables these checks very selectively. The idea is good, MS did same in C# since the first version in 2002. Allows to do pointer arithmetic when you really need to, for performance or native interop. What I don’t like about Rust is they use unsafe to workaround language limitations. In C# I have only used unsafe code couple times over the course of 20 years. The standard library doesn’t use unsafe code either, at least in modern .NET all these collections are 100% safe code. The main, safe subset of the language is good enough for the majority of practical applications. In Rust there’s tons of unsafe code in standard library, substantial amount of unsafe code in third-party libraries, and if your software is complex enough, your own code will likely contain usafe as well. This causes safety issues: https://medium.com/@shnatsel/how-rusts-standard-library-was-vulnerable-for-years-and-nobody-noticed-aebf0503c3d6 https://medium.com/@shnatsel/how-rusts-standard-library-was-...
  - steveklabnik 8y ago
    One of the reasons the standard library has a lot of unsafe is that the standard library is small, but one of the criteria for being in the standard library is “uses a lot of unsafe.” We’d rather these things get massive visibility. In all my years with Rust, the only unsafe I’ve needed in any of my applications is when doing FFI, and my toy OS. YMMV.
    - sanxiyn 8y ago
      On the other hand, Rust certainly could use a lot less unsafe in the standard library than it currently does. It just doesn't want to.
Const-me 8y ago
> and it will be just as safe as you write it in C C++ standard library containers have guarantees about iterators and pointers invalidation, e.g. std::list never invalidates any of these, unordered_map invalidates iterators when rehashed and never invalidates pointers to either keys or values. This allows building unsafe data structures on top of standard collections, and then compose custom unsafe data structures on top of each other. This makes C++ both safer (at least from memory leaks) and easier to use compared to unsafe rust.

baq 8y ago

> Let's be clear: Rust is still far away from formal verification; the borrow checker won't save you from logical errors. completely agree. > Second, data structures like graphs, trees, hashmaps are well understood and have a lot of algorithms built on top of them. well understood, yes, by authors of textbooks and papers. your average programmer may have understood them once, before he made it to the enterprise and started passing buckets of bits between http endpoints for a living. > Algorithms with a lot of research behind them, and complexity analysis. While complexity analysis doesn't always equal performance, if I can't use these universal tools in your language, I'll probably think of it as a toy language which stops me from getting stuff done, which is still what most of us are paid for. you can write a recursive data structure in Rust in the same way you'd write one in C++ - use unsafe pointers, even the asterisk is the same. nothing is stopping anyone from doing that, in fact there are lots of examples on crates.io and in the stdlib.