That's just it. I don't think there's any such thing. I think there are "best practices", but if Rust is to compete against the giants, there really shouldn't be prescribed way of doing things. Unsafe is what allows Rust to go head-to-head with C++ & co. I love that people can choose to use it to push performance boundaries or explore alternate solutions to problems, even if I might not want that particular crate in my dependency tree.
There are tools available to inspect the code you're bringing in. In any language and ecosystem, you should audit your dependencies and actively choose. I don't think we should start restricting how people use this core language feature, though, that's a slippery slope. If the core Rust team can't agree, I can't really imagine everyone who uses Rust agreeing, and I think that's a good thing.
I know what unsafe means to me, and how I want it handled in my projects, but if that was the "One True Way" and everything else is taboo, we close a door that I feel would be to our collective detriment.
Don't get me wrong, I wholeheartedly agree that there shouldn't be a specific "One true way." What I understood to be the meaning was just more defined best practices or more examples of when unsafe is okay to use. I absolutely think that leaving it up to the developers is important, and feels somewhat related to freedom of expression in some ways.
What I've taken away from the reactions I've read has been that the rust community needs to chill when it comes to unsafe usage, so having it show up as the escape hatch it's meant to be is a good thing. It's become clear to me from today that at least a good chunk of the community simply views unsafe as a bad thing, which is different from the sentiments I've seen given by the language team that unsafe is as much a language feature as lifetimes are.
So I guess that's more of what I mean, unsafe needs to be brought more to the forefront in a way that it shows off great things that unsafe can be used for instead of making unsafe itself the taboo.
Definitely, wholeheartedly agree. At least in this case, the actix-web repo should have had a disclaimer front-and-center on the readme about how this particular project viewed the issue.
a good chunk of the community simply views unsafe as a bad thing
I think that there is some general misunderstanding about all the safe/unsafe deal, because some code is safe doesn't mean it can't fail, just say that there is no undefined behavior, your logic can still be wrong, that's why Rust doesn't mean you don't need testing. So some trust in the developer is still important.
Unsafe in the other hand doesn't mean that there are undefined behavior inside, just that the compiler is unable to check for it.
I don't know the details of what happened with the complainers and the main dev, but I wonder is that if so many people felt so strongly against some aspect of the project and where technically proficient enough to be certain that those unsafe where unnecessary, why nobody offered patches and if they did and wasn't accepted why nobody forked the project, that's how it works isn't it. Also, between 0.7 when I saw this whole mess started to v2 a lot of progress was made getting rid of unsafe code.
I think the main dev didn't manage properly the community and part of them became haters, so no matter what changes where made, it was too late.
Maybe the main dev didn't wanted to work with others, not ideal, but his project, his prerogative. Forking is always an option, sadly I'm far from being able to do something like that.
To me just someone capable enough to fork can critique so heavily and in that case, stop critiquing and fork the damn thing.
I'll be here praying to the coding gods (No Robert Martin, you are not a god) that some organization forks Actix, Rust need some bedrock in this, doesn't even need to be the best, but stable and reliable. Just like in Python, whether you like it or not, you can try Flash, Tornado or whatever fancy new thing, but at the end of the day you can always go back to Django and you can be pretty sure it's gonna be there.
I think that there is some general misunderstanding about all the safe/unsafe deal, because some code is safe doesn't mean it can't fail, just say that there is no undefined behavior, your logic can still be wrong, that's why Rust doesn't mean you don't need testing. So some trust in the developer is still important.
Totally agree with this. One thing I really like about rust is that stuff like unit testing feels really easy to do, even where I haven't really been taught to do testing outside of the debugger and print statements at university. The fact that stuff like this exists for rust alone should be proof enough that "safe" doesn't mean "bug free" and "unsafe" doesn't automatically mean "bug riddled"
As far as the forking stuff, I totally agree as well, but I'm also not proficient enough in rust or ready in general to maintain an open source project. Most of my info with this incident is 2nd or 3rd hand at best, but from what I got, some PR's were made and rejected, which spiraled out of control. They really should have just forked it if it was that important to them.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
That's just it. I don't think there's any such thing. I think there are "best practices", but if Rust is to compete against the giants, there really shouldn't be prescribed way of doing things. Unsafe is what allows Rust to go head-to-head with C++ & co. I love that people can choose to use it to push performance boundaries or explore alternate solutions to problems, even if I might not want that particular crate in my dependency tree.
There are tools available to inspect the code you're bringing in. In any language and ecosystem, you should audit your dependencies and actively choose. I don't think we should start restricting how people use this core language feature, though, that's a slippery slope. If the core Rust team can't agree, I can't really imagine everyone who uses Rust agreeing, and I think that's a good thing.
I know what unsafe means to me, and how I want it handled in my projects, but if that was the "One True Way" and everything else is taboo, we close a door that I feel would be to our collective detriment.
Don't get me wrong, I wholeheartedly agree that there shouldn't be a specific "One true way." What I understood to be the meaning was just more defined best practices or more examples of when unsafe is okay to use. I absolutely think that leaving it up to the developers is important, and feels somewhat related to freedom of expression in some ways.
What I've taken away from the reactions I've read has been that the rust community needs to chill when it comes to unsafe usage, so having it show up as the escape hatch it's meant to be is a good thing. It's become clear to me from today that at least a good chunk of the community simply views unsafe as a bad thing, which is different from the sentiments I've seen given by the language team that unsafe is as much a language feature as lifetimes are.
So I guess that's more of what I mean, unsafe needs to be brought more to the forefront in a way that it shows off great things that unsafe can be used for instead of making unsafe itself the taboo.
Definitely, wholeheartedly agree. At least in this case, the
actix-webrepo should have had a disclaimer front-and-center on the readme about how this particular project viewed the issue.Ever used a
Vec<T>? Repent! ;)I think that there is some general misunderstanding about all the safe/unsafe deal, because some code is safe doesn't mean it can't fail, just say that there is no undefined behavior, your logic can still be wrong, that's why Rust doesn't mean you don't need testing. So some trust in the developer is still important.
Unsafe in the other hand doesn't mean that there are undefined behavior inside, just that the compiler is unable to check for it.
I don't know the details of what happened with the complainers and the main dev, but I wonder is that if so many people felt so strongly against some aspect of the project and where technically proficient enough to be certain that those unsafe where unnecessary, why nobody offered patches and if they did and wasn't accepted why nobody forked the project, that's how it works isn't it. Also, between 0.7 when I saw this whole mess started to v2 a lot of progress was made getting rid of unsafe code.
I think the main dev didn't manage properly the community and part of them became haters, so no matter what changes where made, it was too late.
Maybe the main dev didn't wanted to work with others, not ideal, but his project, his prerogative. Forking is always an option, sadly I'm far from being able to do something like that.
To me just someone capable enough to fork can critique so heavily and in that case, stop critiquing and fork the damn thing.
I'll be here praying to the coding gods (No Robert Martin, you are not a god) that some organization forks Actix, Rust need some bedrock in this, doesn't even need to be the best, but stable and reliable. Just like in Python, whether you like it or not, you can try Flash, Tornado or whatever fancy new thing, but at the end of the day you can always go back to Django and you can be pretty sure it's gonna be there.
Totally agree with this. One thing I really like about rust is that stuff like unit testing feels really easy to do, even where I haven't really been taught to do testing outside of the debugger and print statements at university. The fact that stuff like this exists for rust alone should be proof enough that "safe" doesn't mean "bug free" and "unsafe" doesn't automatically mean "bug riddled"
As far as the forking stuff, I totally agree as well, but I'm also not proficient enough in rust or ready in general to maintain an open source project. Most of my info with this incident is 2nd or 3rd hand at best, but from what I got, some PR's were made and rejected, which spiraled out of control. They really should have just forked it if it was that important to them.