CVEs/LOC not a great metric
CVEs/LOC not a great metric
Posted Dec 4, 2024 20:32 UTC (Wed) by khim (subscriber, #9252)In reply to: CVEs/LOC not a great metric by Cyberax
Parent article: NonStop discussion around adding Rust to Git
And does it help? If I replace newNubers with numbers problem remains, of course.
The issue in that code is not that append is used incorrectly, but in the fact that append-using function is used incorrectly.
Which is precisely and exactly the same class of bugs that make C/C++ programs fail, most of the time!
You may as well say that malloc should be paired with free and anyone who doesn't do that is “holding it wrong”.
Whether it's a hashmap that someone incorrectly modifies, or changing a struct which is not supposed to be changed… it's the exact same pattern: something is changed when it shouldn't be changed, or, alternatively, something is not changed when it should be changed.
The latter case couldn't be handled by the language efficiently (that's firmly #1 in farnz classification), but the former could be handled, in many cases. And most serious languages before Go (like C/C++, Java, C#, etc) had a way to handled that to some degree (approaches are different, const in C doesn't work like final in Java and C# in/ref readonly have different scope from both of them), but only “improved C” language developed in XXI century decided that “you are holding it wrong” is the best answer to these concerns.
Sure, the languages that Go actually replaces (JavaScript, Python or Ruby) had no such mechanisms either… which partially explains why C++ developers don't flock to Go and most developers switch to Go from dynamically-typed languages. But even they are slowly growing them (JavaScript have const these days)!
But still it's kind of funny that Go developers were telling to themselves that they are doing a better alternative for C++, not better alternative for Python…
Posted Dec 4, 2024 21:18 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link] (1 responses)
Yes, it helps. Because it's clear that you're mutating a passed-by-value object.
Posted Dec 5, 2024 11:58 UTC (Thu)
by khim (subscriber, #9252)
[Link]
I guess it helps a tiny bit (it's similar to the level of protection JavaScript Note: I'm not saying that Go is worse than C (although it's, most likely, worse than C++), I'm just saying that for majority of the “memory safe” languages said “memory safety” doesn't make programs safer or more robust to a degree that people expect. They add memory safety not to make them safer or more reliable, but, in 90% of cases, to make them “simpler”, or “more flexible”, etc. And if you eliminate 70% of bugs but make remaining 30% of bugs 2-3 times easier to make… the net result is still positive, but it's not as large as many expect.
Posted Dec 5, 2024 0:07 UTC (Thu)
by intgr (subscriber, #39733)
[Link]
TBF JavaScript's const is almost useless. It only prevents you from re-assigning the variable in the scope.
It does nothing to prevent mutation or side-effects: when the *value* referenced by variables is inadvertently mutated.
You can have a const Array variable and still mutate it many times in a function, pass it to another function that mutates the array etc.
CVEs/LOC not a great metric
CVEs/LOC not a great metric
const or Java's final provides), but if you are to use it like that, 99% of time, then why in 15 years of development nothing that doesn't force me to type the same thing twice was provided?CVEs/LOC not a great metric