The point of Rust is ostensibly to provide a safer version of C++-like semantics, not necessarily to avoid the same level of complexity. Especially if you're directly using unsafe code (which is necessary in some cases, like FFI), it's not really clear to me that Rust was "meant" to be doing something wildly different here. The large majority of the code not needing to use unsafe will still be better off even if this type of thing is necessary in some places.
(To preempt any potential explanations about this: yes, I understand the reference being made with that quote. I just don't think it actually applies here at all)
> rust, you were meant to replace c++, not join it...
Turns out that not all of the C++ noise people make fun of is due to C++, sometimes the problems you want to solve with Rust or C++ is just hard to express simply to the compiler.
FYI to non-Rust devs wondering what's going on with this code: Those two abstractions (FFISafe and WithOffset) are not standard Rust abstractions. They're something the author is building within their own library: https://github.com/memorysafety/rav1d/blob/25e5574/src/ffi_s...
So for all of the complaining about Rust abstractions and syntax in this thread, keep in mind that these particular abstractions that caused this problem are not standard. If you just want to call an extern "C" function you can do so directly in an unsafe block. The article should be read as the author debugging their Rust wrapper types, not as a generic article about calling C functions from Rust.
Not related to the topic, but seeing this tidbit in the article took me by surprise;
> PSA: if you don’t see syntax highlighting, disable the 1Password extension.
This linked to the following discussion that's been ongoing for over a week (with acknowledgement from 1password that they're looking into it but as far as can tell no ETA on the fix or explanation for why it's happening in the first place):
I know that browser extensions are in general a pretty terrible ecosystem in terms of security, but am I off-base for thinking this is not a great look for 1password? Maybe I'm just underestimating how hard this is to solve generally, but my expectation would be that it shouldn't be that hard to keep track of which circumstances you're loading entire external scripts to manipulate the DOM and not do it accidentally in places you have no need for it.
Title reminded me of something completely unrelated:
FFI overhead is not to be neglected sometimes. I've seen cases where replacing a python or js lib with an in isolation much faster native Rust or C lib with bindings had the end result being a decrease in real-world performance due to it being in a hot path or loop and the overhead being more significant than the savings were. There is no substitute for real-world benchmarks.
12 comments
[ 2.3 ms ] story [ 36.1 ms ] thread(To preempt any potential explanations about this: yes, I understand the reference being made with that quote. I just don't think it actually applies here at all)
Turns out that not all of the C++ noise people make fun of is due to C++, sometimes the problems you want to solve with Rust or C++ is just hard to express simply to the compiler.
So for all of the complaining about Rust abstractions and syntax in this thread, keep in mind that these particular abstractions that caused this problem are not standard. If you just want to call an extern "C" function you can do so directly in an unsafe block. The article should be read as the author debugging their Rust wrapper types, not as a generic article about calling C functions from Rust.
> PSA: if you don’t see syntax highlighting, disable the 1Password extension.
This linked to the following discussion that's been ongoing for over a week (with acknowledgement from 1password that they're looking into it but as far as can tell no ETA on the fix or explanation for why it's happening in the first place):
https://www.1password.community/discussions/developers/1pass...
I know that browser extensions are in general a pretty terrible ecosystem in terms of security, but am I off-base for thinking this is not a great look for 1password? Maybe I'm just underestimating how hard this is to solve generally, but my expectation would be that it shouldn't be that hard to keep track of which circumstances you're loading entire external scripts to manipulate the DOM and not do it accidentally in places you have no need for it.
FFI overhead is not to be neglected sometimes. I've seen cases where replacing a python or js lib with an in isolation much faster native Rust or C lib with bindings had the end result being a decrease in real-world performance due to it being in a hot path or loop and the overhead being more significant than the savings were. There is no substitute for real-world benchmarks.