5 ms·

This is from memory, I would welcome any corrections. Actix was written with a lot of unsafe code[0], which some people considered unnecessary and potentially

This is from memory, I would welcome any corrections. Actix was written with a lot of unsafe code[0], which some people considered unnecessary and potentially dangerous in a web framework. In some cases the unsafe code may have been performing better than equivalent safe code. In other cases, it was possible to rewrite with safe code without losing performance. People submitted patches to replace unsafe code with safe code. The maintainer of Actix responded with hostility to some of these patches, and (at least for some of the patches) did not seem to see the reason why people wanted these changes. Subsequently, a lot of hostility was directed at the maintainer on various public Internet fora. Ultimately, the maintainer of Actix deleted the repository from GitHub, but then had a change of heart and restored it, with a new maintainer. [0] unsafe code according to the Rust definition of unsafe: https://doc.rust-lang.org/book/ch19-01-unsafe-rust.html https://doc.rust-lang.org/book/ch19-01-unsafe-rust.html

Dowwie 7y ago
Your description is accurate and fair
undecisive 7y ago
That seems a pretty balanced summary from my understanding of it. One thing that I think should be noted: a lot has been said about this framing the original developer as unwilling. I'd say an unfair amount - from what I've seen, "cautiousness" would be a better description of his attitude, and hostility seems to have been shown when people blindly wade in ignoring all the discussion. So for example, back in 2018, here he is publicly mulling it over: https://github.com/actix/actix-web/issues/289#issuecomment-395800266 https://github.com/actix/actix-web/issues/289#issuecomment-3... and https://github.com/actix/actix-web/issues/289#issuecomment-397827214 https://github.com/actix/actix-web/issues/289#issuecomment-3... Here he is actively working to reduce the reliance on unsafe practices: https://github.com/actix/actix-web/issues/289#issuecomment-397840016 https://github.com/actix/actix-web/issues/289#issuecomment-3... Here he actively and very concisely points out his actual viewpoint: https://github.com/actix/actix-web/issues/289#issuecomment-398739160 https://github.com/actix/actix-web/issues/289#issuecomment-3... ... and there are plenty of other examples in this and other tickets. Massive actions were taken by others and himself to significantly reduce the unsafe code where possible, and yet it seems the abuse kept coming. I'd be interested to hear whether the new maintainer has had similar experiences. Unfortunately, our preferences in software development, often a product of a desire to generalise a specific overreaction, tend to become quasi-religious and puritanical. Members get outcast from their communities for trying to speak sense. I hope that this debacle will cause the community to mature, though I fear many will see it as a win and galvanise their viewpoint. We must remember that silver bullets can kill more than just werewolves.
imtringued 7y ago
I do not understand the motivation for deleting the repository. Most maintainers just quit but they don't go out of their way to take down the project when they go.
- throwaway17_17 7y ago
  I think it’s basic human instinct, paraphrased by the saying ‘taking my ball and going home’. I mean if people are not treating you how you want to be treated, why should I go and leave them with my stuff. Not saying I agree with what he did, but I do get it.
tinco 7y ago
For non-rusties: unsafe means turning off Rust's advanced safety features, reducing its safety level to that of C or C++. Which is to say, it's as safe as almost all software you're using right now. Of course, one usually turns off the safety features because one is trying to do something tricky to squeeze out performance or achieve some low level feat, so it's also an indicator that something is dangerous is going on. In your C++ you might add a comment explaining the behaviour you're relying on to convince any reader of the correctness of your code. The cool thing about Rust is that anywhere you don't have the unsafe block, you're (theoretically) certain there's no tricky business going on without even having to read the code. There was a lot of commotion in the community because many rustaceans take a lot of pride in having this safety features. They took offense at disabling those features, risking Rust's reputation of safety, for seemingly meaningless goals (such as winning the TechEmpower benchmarks). It's not disabling the safety features that makes the code faster btw, it's the tricks you're allowed to do when the safety is off that might yield performance improvements.
- cesarb 7y ago
  > For non-rusties: unsafe means turning off Rust's advanced safety features, reducing its safety level to that of C or C++. Actually, it's a bit more subtle: unsafe allows using some things which are not protected by "Rust's advanced safety features", like dereferencing raw pointers, and using these things can "reduce its safety level to that of C or C++" (for that module). However, if these things are not used, the safety is not reduced; you can take a block of Rust code which has no "unsafe", put it in an "unsafe" block, and it will be identically safe as before.
burntsushi 7y ago
A small but crucially important clarification: it wasn't just that there was a lot of `unsafe` code, but that some portion of it was unsound. You can read more about what I mean by unsound in this context here: https://docs.rs/dtolnay/0.0.7/dtolnay/macro._03__soundness_bugs.html https://docs.rs/dtolnay/0.0.7/dtolnay/macro._03__soundness_b...
- undecisive 7y ago
  Interesting - thanks for sharing that. Though that article does make things a little clearer, I get the impression we should really have three circles on a venn diagram - essentially, I'm decoupling the concepts of "unsound" and "bug": - Bug - i.e. some unintended action of a piece of code - unsound - i.e. code that can be used (or abused) to produce unsafe effects - unsafe-bleed - i.e. code that cannot be proven to be safe at compile time, or even potentially code that can be proven to be unsound, that a third-party developer could legitimately use without knowing it was unsafe/unsound. The question I'm curious about is what the proposed PRs fixed. It's clear they didn't fix a bug; the API used was part of the undocumented internals (afaik), and all internal uses of the code were reportedly clean. It maybe "fixed" an unsoundness, future developers of the project may indeed have misused this code and received undefined behaviour as a result (again, I don't know how common or uncommon the particular misuse would be in the rust community) I don't know whether this fixed an unsafe-bleed though; whether a third party has access to these objects and has the ability to combine them in such a way as to produced undefined behaviour. My question to you is: is this a Bug, such that the code did not perform as expected; Is there a bleed of unsafety here, where the permissions model of rust allows access outside the crate to these implementation details; or is it just unsoundness - and if so, could the unsoundness have been mitigated some other (more performant) way?
  - Rusky 7y ago
    In the most recent issue, there was in fact demonstrated "unsafe-bleed," in the sense that client code could hit undefined behavior by using public safe APIs a particular way.
  - burntsushi 7y ago

Dowwie 7y ago

Your description is accurate and fair

undecisive 7y ago

That seems a pretty balanced summary from my understanding of it. One thing that I think should be noted: a lot has been said about this framing the original developer as unwilling. I'd say an unfair amount - from what I've seen, "cautiousness" would be a better description of his attitude, and hostility seems to have been shown when people blindly wade in ignoring all the discussion. So for example, back in 2018, here he is publicly mulling it over: https://github.com/actix/actix-web/issues/289#issuecomment-395800266 https://github.com/actix/actix-web/issues/289#issuecomment-3... and https://github.com/actix/actix-web/issues/289#issuecomment-397827214 https://github.com/actix/actix-web/issues/289#issuecomment-3... Here he is actively working to reduce the reliance on unsafe practices: https://github.com/actix/actix-web/issues/289#issuecomment-397840016 https://github.com/actix/actix-web/issues/289#issuecomment-3... Here he actively and very concisely points out his actual viewpoint: https://github.com/actix/actix-web/issues/289#issuecomment-398739160 https://github.com/actix/actix-web/issues/289#issuecomment-3... ... and there are plenty of other examples in this and other tickets. Massive actions were taken by others and himself to significantly reduce the unsafe code where possible, and yet it seems the abuse kept coming. I'd be interested to hear whether the new maintainer has had similar experiences. Unfortunately, our preferences in software development, often a product of a desire to generalise a specific overreaction, tend to become quasi-religious and puritanical. Members get outcast from their communities for trying to speak sense. I hope that this debacle will cause the community to mature, though I fear many will see it as a win and galvanise their viewpoint. We must remember that silver bullets can kill more than just werewolves.

imtringued 7y ago

I do not understand the motivation for deleting the repository. Most maintainers just quit but they don't go out of their way to take down the project when they go.

throwaway17_17 7y ago
I think it’s basic human instinct, paraphrased by the saying ‘taking my ball and going home’. I mean if people are not treating you how you want to be treated, why should I go and leave them with my stuff. Not saying I agree with what he did, but I do get it.

tinco 7y ago

For non-rusties: unsafe means turning off Rust's advanced safety features, reducing its safety level to that of C or C++. Which is to say, it's as safe as almost all software you're using right now. Of course, one usually turns off the safety features because one is trying to do something tricky to squeeze out performance or achieve some low level feat, so it's also an indicator that something is dangerous is going on. In your C++ you might add a comment explaining the behaviour you're relying on to convince any reader of the correctness of your code. The cool thing about Rust is that anywhere you don't have the unsafe block, you're (theoretically) certain there's no tricky business going on without even having to read the code. There was a lot of commotion in the community because many rustaceans take a lot of pride in having this safety features. They took offense at disabling those features, risking Rust's reputation of safety, for seemingly meaningless goals (such as winning the TechEmpower benchmarks). It's not disabling the safety features that makes the code faster btw, it's the tricks you're allowed to do when the safety is off that might yield performance improvements.

cesarb 7y ago
> For non-rusties: unsafe means turning off Rust's advanced safety features, reducing its safety level to that of C or C++. Actually, it's a bit more subtle: unsafe allows using some things which are not protected by "Rust's advanced safety features", like dereferencing raw pointers, and using these things can "reduce its safety level to that of C or C++" (for that module). However, if these things are not used, the safety is not reduced; you can take a block of Rust code which has no "unsafe", put it in an "unsafe" block, and it will be identically safe as before.

burntsushi 7y ago

A small but crucially important clarification: it wasn't just that there was a lot of `unsafe` code, but that some portion of it was unsound. You can read more about what I mean by unsound in this context here: https://docs.rs/dtolnay/0.0.7/dtolnay/macro._03__soundness_bugs.html https://docs.rs/dtolnay/0.0.7/dtolnay/macro._03__soundness_b...

undecisive 7y ago
Interesting - thanks for sharing that. Though that article does make things a little clearer, I get the impression we should really have three circles on a venn diagram - essentially, I'm decoupling the concepts of "unsound" and "bug": - Bug - i.e. some unintended action of a piece of code - unsound - i.e. code that can be used (or abused) to produce unsafe effects - unsafe-bleed - i.e. code that cannot be proven to be safe at compile time, or even potentially code that can be proven to be unsound, that a third-party developer could legitimately use without knowing it was unsafe/unsound. The question I'm curious about is what the proposed PRs fixed. It's clear they didn't fix a bug; the API used was part of the undocumented internals (afaik), and all internal uses of the code were reportedly clean. It maybe "fixed" an unsoundness, future developers of the project may indeed have misused this code and received undefined behaviour as a result (again, I don't know how common or uncommon the particular misuse would be in the rust community) I don't know whether this fixed an unsafe-bleed though; whether a third party has access to these objects and has the ability to combine them in such a way as to produced undefined behaviour. My question to you is: is this a Bug, such that the code did not perform as expected; Is there a bleed of unsafety here, where the permissions model of rust allows access outside the crate to these implementation details; or is it just unsoundness - and if so, could the unsoundness have been mitigated some other (more performant) way?
- Rusky 7y ago
  In the most recent issue, there was in fact demonstrated "unsafe-bleed," in the sense that client code could hit undefined behavior by using public safe APIs a particular way.
- burntsushi 7y ago