4 ms·

Yes that's true. Coverity and similar are even slower. But then rust errors out on a lot of things the C++ analyzer wouldn't, a lot of those things are actuall

by nn3 7y ago

Yes that's true. Coverity and similar are even slower. But then rust errors out on a lot of things the C++ analyzer wouldn't, a lot of those things are actually being reasonable code. For example I discovered recently that you cannot swap two pointer variables in rust without using unsafe. Surely there is some deep reason for that, that is really important until they can figure out how to fix it in some future Rust version, which they undoubtedly will. It's not that swapping is an obscure operation, many important and fundamental algorithms depend on it. I'm probably overly cynical there, but I sometimes feel that all these arbitrary restrictions that make code hard to write make people feel better about rust because if they get their code to actually compile it's a sense of achievement that makes them proud. Kind of like a journey to find yourself or something like that. But then i see that there is actually some progress in Rust to relax some of these restrictions (e.g. non lexical lifetimes in the borrow checker). If my theory above is true that would actually lower Rust's popularity over time. True? Probably not. But it's an interesting thought.

carlmr 7y ago
>For example I discovered recently that you cannot swap two pointer variables in rust without using unsafe. Surely there is some deep reason for that, that is really important until they can figure out how to fix it in some future Rust version, which they undoubtedly will. Wouldn't this work? https://doc.rust-lang.org/std/mem/fn.swap.html https://doc.rust-lang.org/std/mem/fn.swap.html >But then i see that there is actually some progress in Rust to relax some of these restrictions (e.g. non lexical lifetimes in the borrow checker). If my theory above is true that would actually lower Rust's popularity over time. True? Probably not. But it's an interesting thought. I'm not sure. Sometimes these restrictions are there, because it's too difficult to decide what should happen. I don't think it's malevolence on the language creators side. And I do think usability is always better. I find that I'm running into way fewer such situations now than last year though, so I think a lot is happening here.
- commit 7y ago
  >Wouldn't this work? https://doc.rust-lang.org/std/mem/fn.swap.html https://doc.rust-lang.org/std/mem/fn.swap.html If you click the [src] link on that page, you'll see that the implementation of std::mem::swap uses unsafe. I'm no Rust expert, but I'm also not aware of a way to swap pointers without unsafe.
  - carlmr 7y ago
    Ah I thought you meant without using unsafe yourself. The goal of unsafe is to reduce the attack surface where you need to check your code more thoroughly. So by encapsulating this in a library function that's well tested you don't need to create such a section yourself. But if you do need unsafe it's not wrong, and if only a small part of your code needs unsafe then it's much easier to verify that your code is doing what it should.

by nn3 7y ago

carlmr 7y ago

>For example I discovered recently that you cannot swap two pointer variables in rust without using unsafe. Surely there is some deep reason for that, that is really important until they can figure out how to fix it in some future Rust version, which they undoubtedly will. Wouldn't this work? https://doc.rust-lang.org/std/mem/fn.swap.html https://doc.rust-lang.org/std/mem/fn.swap.html >But then i see that there is actually some progress in Rust to relax some of these restrictions (e.g. non lexical lifetimes in the borrow checker). If my theory above is true that would actually lower Rust's popularity over time. True? Probably not. But it's an interesting thought. I'm not sure. Sometimes these restrictions are there, because it's too difficult to decide what should happen. I don't think it's malevolence on the language creators side. And I do think usability is always better. I find that I'm running into way fewer such situations now than last year though, so I think a lot is happening here.

commit 7y ago
>Wouldn't this work? https://doc.rust-lang.org/std/mem/fn.swap.html https://doc.rust-lang.org/std/mem/fn.swap.html If you click the [src] link on that page, you'll see that the implementation of std::mem::swap uses unsafe. I'm no Rust expert, but I'm also not aware of a way to swap pointers without unsafe.
- carlmr 7y ago
  Ah I thought you meant without using unsafe yourself. The goal of unsafe is to reduce the attack surface where you need to check your code more thoroughly. So by encapsulating this in a library function that's well tested you don't need to create such a section yourself. But if you do need unsafe it's not wrong, and if only a small part of your code needs unsafe then it's much easier to verify that your code is doing what it should.