4 ms·
I think the author cheats a little bit, because in the first example on "IEF" he compares a function declaration containing an explicit visibility modifier "pub
by self_awareness 3y ago
I think the author cheats a little bit, because in the first example on "IEF" he compares a function declaration containing an explicit visibility modifier "public" to the default Rust version (private).
But in reality, omitting Java visibility keyword puts the function into the "default" visibility rules, which is package-private. So, public in the same package, but private when seen from other packages. So the impact is severily limited, depending on the architecture of the application (it's de facto public for applications contained in 1 package).
Still, Rust version is more restrictive, so the point holds, but I think it should be fixed somehow.
- OskarS 3y agoYeah, I had the same reaction, it was a very bad strawman: the author had explicitly set the function to be public in the Java example, and then not done so in the Rust example, and then argued that Rust is safer. But that's absurd: you deliberately made dropDatabase public in Java, which you could just as easily do in Rust by making it pub. The author just opted not to do that in order to argue that Rust is safer. Your argument is fair that the "default" state in Rust is more restrictive, but the difference honestly is tiny. In practice, basically all Java code I've seen always explicitly states whether every function is private, public or protected, that's just how you write Java. Should it be compiler-enforced that you always do so? Maybe, but we're really splitting hairs here.
- self_awareness 3y agoTrue, I've written "the argument holds" in strictly theoretical sense that Rust version is more restrictive, but since the degree of this restriction is so small, I don't think this particular trait has any impact on security of anything.