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.
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.