DEV Community

Discussion on: That About Wraps It Up For Actix-Web

redoxeon profile image
Mike Harding

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.

Thread Thread
deciduously profile image
Ben Lovy Author

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

Ever used a Vec<T>? Repent! ;)

Thread Thread
ghost profile image
Ghost

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.

Thread Thread
redoxeon profile image
Mike Harding

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.