Despite not having any need for Rust (just as I have no need for C++ in the things I work on - performance at that level just doesn’t matter for my projects), I am continually surprised at just how great Rust is as a language and as a community. It just seems to be filled with helpful friendly people. It’s certainly not the only community that’s friendly, I’ve found Python and Lisp to both be pretty friendly communities too, but reading stuff like:
There’s been quite a bit of noise recently about the amount of unsafe code in the actix-web framework. I won’t discuss the merits of grabbing the pitchforks as soon as someone writes code of a buggy and unidiomatic nature…
And then I click on the link and it’s a bunch of people calmly and rationally discussing some code. For the Rust community, that is grabbing the pitchforks: people saying that some code is concerning in its use of unsafe.
Compare to some communities (cough Javascript) where it’s not unusual to see pull requests and issues on GitHub and other platforms flooded with hundreds of comments absolutely dogpiling someone that wrote some silly code when they were a new programmer that, totally unbeknownst to them, was picked up and used by someone in a large company (with no oversight, clearly) and is now a dependency of a major library.
Also, cool article.
EDIT:
The code is a bit convoluted, because of the reason described in the comment. drop can panic 5, so the function must decrement the length before dropping an element. In case of a panic, the last element of the Vec will be a valid one.
I was under the impression a panic in Rust was unrecoverable. Does it matter if the data structure is left in an inconsistent state if drop panics? I thought that not having to reason about exception safety was considered a selling point of not having exceptions.
I was under the impression a panic in Rust was unrecoverable. Does it matter if the data structure is left in an inconsistent state if drop panics? I thought that not having to reason about exception safety was considered a selling point of not having exceptions.
Panics in Rust are unrecoverable within a task. You can catch them (for example, before unwinding into a piece of C-code, which is undefined) using catch_panic. Still, there’s guarantees around panic, and that being that all owned values affected are properly _drop_ped and especially, memory safety is not violated in the process. Now, imagine the panicing code has the data structure borrowed and triggers the panic. The original value continues to exist and must be in a consistent state.
Mutexes are a good example of a structure that has to deal with that problem. As Mutexes cannot reason about the operations on the data they contain, they become poisoned in such a situation.
Safe Rust allows you not having to reason about exception safety, unsafe on the other hand… is unsafe Rust ;).
Panics in drops are rare (and generally recommended against), but they may happen…
Another observation: in this case, they may lead to a memory leak, but leaking is safe in Rust. Dropping twice is illegal.
While you’re right about Rust community being friendly (even by force at times), the actix discussion wasn’t all happiness. The unsafety was first sort of ignored by the devs, which made some people claim that the developers of actix are completely untrustworthy, and shouldn’t be trusted in any future project either. That understandably made the actix devs a bit unhappy, probably on the verge of just dropping everything and walking away, but fortunately they decided to fix things instead.
So it was pretty good in the end, but the road there was a bit worse than you described, IMHO.
You have all those great approaches about correctness, and then you see here and there developers trying random explicitly unsafe hacks depending on internals of data types, that not even C++ developers would try.
I mean, when was the last time when you randomly tried to nuke the internal length of an C++ std::vector to speed things up, using simultaneously dangerous means and a complex reasoning (but probably undocumented, and maybe incorrect) justifying that there actually was no risk in your opinion?
And on top of that do it in, not in some kind of insane computation kernel trying to grab the last bit of perf, but in merely an HTTP library?
Well at least I’m happy this particular missed optim has been fixed. One less reason to resort to insane unsafe hacks.
(On a sidenote, it is sometimes better to only modify a variable in memory if it doesn’t already has the good value, but this would be mostly for scaling concurrent accesses of the same cacheline on multiple CPU, so this does not really apply here – and also sometimes compilers fuck you up by using a cmov but then it is a completely different story :p )
I disagree with this. If anything, I suspect this idea has come from C++, where std::vector’s API contains functions to explicitly reduce the length without shrinking the capacity. This is partly to avoid invalidating iterators, but is also used to e.g. avoid unnecessary allocations when emptying a vector and immediately refilling it with a simply quantity of elements.
Despite not having any need for Rust (just as I have no need for C++ in the things I work on - performance at that level just doesn’t matter for my projects), I am continually surprised at just how great Rust is as a language and as a community. It just seems to be filled with helpful friendly people. It’s certainly not the only community that’s friendly, I’ve found Python and Lisp to both be pretty friendly communities too, but reading stuff like:
And then I click on the link and it’s a bunch of people calmly and rationally discussing some code. For the Rust community, that is grabbing the pitchforks: people saying that some code is concerning in its use of
unsafe.Compare to some communities (cough Javascript) where it’s not unusual to see pull requests and issues on GitHub and other platforms flooded with hundreds of comments absolutely dogpiling someone that wrote some silly code when they were a new programmer that, totally unbeknownst to them, was picked up and used by someone in a large company (with no oversight, clearly) and is now a dependency of a major library.
Also, cool article.
EDIT:
I was under the impression a panic in Rust was unrecoverable. Does it matter if the data structure is left in an inconsistent state if
droppanics? I thought that not having to reason about exception safety was considered a selling point of not having exceptions.Panics in Rust are unrecoverable within a task. You can catch them (for example, before unwinding into a piece of C-code, which is undefined) using
catch_panic. Still, there’s guarantees around panic, and that being that all owned values affected are properly _drop_ped and especially, memory safety is not violated in the process. Now, imagine the panicing code has the data structure borrowed and triggers the panic. The original value continues to exist and must be in a consistent state.Mutexes are a good example of a structure that has to deal with that problem. As Mutexes cannot reason about the operations on the data they contain, they become poisoned in such a situation.
Safe Rust allows you not having to reason about exception safety, unsafe on the other hand… is unsafe Rust ;).
Panics in drops are rare (and generally recommended against), but they may happen…
Another observation: in this case, they may lead to a memory leak, but leaking is safe in Rust. Dropping twice is illegal.
While you’re right about Rust community being friendly (even by force at times), the actix discussion wasn’t all happiness. The unsafety was first sort of ignored by the devs, which made some people claim that the developers of actix are completely untrustworthy, and shouldn’t be trusted in any future project either. That understandably made the actix devs a bit unhappy, probably on the verge of just dropping everything and walking away, but fortunately they decided to fix things instead.
So it was pretty good in the end, but the road there was a bit worse than you described, IMHO.
Interesting observation from reddit
I disagree with this. If anything, I suspect this idea has come from C++, where std::vector’s API contains functions to explicitly reduce the length without shrinking the capacity. This is partly to avoid invalidating iterators, but is also used to e.g. avoid unnecessary allocations when emptying a vector and immediately refilling it with a simply quantity of elements.