Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I strongly believe that if I would code anything significant my Rust could would be more correct.

The reasons are types and rusts multi threading guarantees, which become even more helpful when doing refactorings



It won't because the number #1 factor in bugs is the number of lines. The Python code will be significantly shorter and thus contain less bugs.


That feels a bit overly reductive. I have a hard time believing GolfScript and APL are among the least error prone languages, for example.


Leaving joke languages aside, it is very much true. If you use less lines of code to implement a software feature, the software feature will on average have less bugs.

Programmers write bugs per line, something like Python which only uses 33% of the lines and thus contains only around 33% of the bugs. On the other hand, if you go down the prove things are correct at compile time you will eliminate around 5% of the bugs.

So you can choice between eliminating 67% of the bugs by making the language simpler to use or 5% of the bugs by doing formal checking.


Has someone done this analysis with Rust? I highly doubt it holds for Rust programs. Seriously.


Just finished my learning Rust project (very basic version of minecraft). It's great for writing highly parallel high performance code.

At no point was the memory of my program ever replaced with the number 53 nor did memory become corrupt due to multiple threads accessing the same areas at the same time. Much better than C++.

Did my Rust project suddenly contain no errors or did it never crash? Well no. How did it crash?

Array indexing (called default instead of new which created an invalid version of the struct)

Infinite loop (logic error causing it to add the result each loop to the input vector rather than the output vector).

That said Rust is almost certainly going to kill C++. It's a lot better.


Nobody claims that Rust code contains no errors, but less.

Rust removes types of errors that can happen. Logic errors don't belong to the types of errors Rust 'removes'


When you are using a duck typed language, the overwhelming majority 90%+ of errors are logic errors.


By definition this is true. Duct type languages don't care about whether your program is expected to work at compile time. They just run it and hope it does so it's all "logic errors".

I've experienced an array indexing issue in Rust exactly once and when it happened the stack trace told me exactly where and then I did exactly what you did: changed default to new or something and called append instead of my_vec[N] = foo. This issue was caught in my test btw.

That leaves infinite loop which is a problem in any language if you aren't intending to loop infinitely. So it's simply not something Rust fixes. I must say the number if times I've had a program infinitely loop and it be a problem that made it through a basic test of the logic is minuscule compared to the number of times I've had a program just shit the bed with poorly managed pointers or corrupt memory.

So you're basically proving our point. Rust eliminated all your bugs except an infinite loop and an array index out of bounds. I bet your mincraft clone is running flawlessly and you have Rust to thank.

What Rust has shown me is that programmers by and far make more unforced semantic errors (like not properly managing a pointer or accessing memory without proper synchronization) than they do logic errors. When you remove all the silly BS errors, you're left with surprisingly few problems to solve and you can almost surely blame yourself and find and fix the issue when one does crop up. It's way different. If you haven't, try writing Minecraft in Java.


> Programmers write bugs per line

Source?

Hack more code into one line -> less bugs for the overall program? doubt

Use Typescript instead of JS (thus add a few loc) -> more bugs? certainly doubt


That's really a question for Google or Stack Overflow.

One source would be: https://www.oreilly.com/library/view/code-complete-2nd/07356...


I think the metric you’re looking for is bugs per line not raw total bugs. Bugger programs have more bugs is trivially true if all programs had the same rate of bugs per line.




Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: