Comment by nickpsecurity | Hacker News Reader

Comment by nickpsecurity | Hacker News Reader

Parent Full thread

There's actually a lot of people who want actual, experimental data to back a language's claims about safety. A subset of them use C and C++. I occasionally argue with them about safety benefits of other languages. They demand more proof than the design, esp field data. I do keep stuff like this as experimental evidence that will add up for such empiricists over time. Although, I prefer controlled experiments where you teach amateurs C, modern C++, and Rust over a specific time followed by testing (esp fuzzing) of their code to test the safety claims. Run it in a dozen different places to see if results are consistent.

There's also folks that just study these things to identify patterns in problems created, prevented, or detected (at what effectiveness) in various languages and techniques in software development. Along similar vein, each bug report also provides (in theory) a test case for automated tools that detect bugs. It's very important to have a huge, diverse pile of code to test those tools with. That's because each one's algorithms might have blind spots missing bugs. The more code and bugs we have, the better we can assess those algorithms' accuracy. And then build better algorithms. :)

It seems fairly obvious that if Language A's design prevents a certain class of bugs possible in Language B's design, A is safer than B. If someone isn't satisfied by this, they probably are biased against Language A. I'd tell the hypothetical person to try writing a buffer overflow vulnerability in safe Rust.

That said, I can't find the source right now but I believe the quote is something along the lines a sizable percentage of Firefox's security bugs would be less severe or nonexistent in Rust vs. C++.

Usually with the argumentation that nicksecurity is referring to, they eventually switch to is "but Language A still allows for bugs class type X thus why bother".

So one then needs to resort to statistics and other stuff as argument validation.

For example, even after being proven wrong with Godbolt that it is possible to write safer code in C++, while keeping the same or even less hardware requirements, many embedded C devs still argue that it is not worthwhile for safer code.

Rust, just like other (almost) memory safe systems languages will get the same human judgement.

Don't get me wrong, I love Rust, but I think any programming beginner starting with Rust as a first language is pretty likely to fail.

Ownership is a hugely important part of designing programs, and it's something people need to come to terms with eventually, but a language where you can't do even hello world without understanding ownership adds a lot of mental overhead to the learning process when someone is still not even comfortable with for loops and function calls.

`cargo new $project_name` literally generates a hello world program so it is misleading to say you need to understand ownership to write `hello world`.

That being said ownership is rather hard, but liberal usage of `.clone()` can get you pretty far.

That's a different subject entirely. Beginners should learn from resources teaching fundamentals, both primitives and patterns like abstraction/decomposition, using a simple language with minimal, incidental complexity. Once they grok that, my next recommendation is using another simple, but real-world, language like Python or Go with lots of code they can practice on. Read, modify, and debug. Then, with key skills, they can tackle hard stuff like C, C++, and Rust.

Pyret at pyret.org is a good candidate since there's a group called Bootstrap successfully teaching it to middle schoolers. That's bootstrapworld.org.

Far as Rust, Ill also note people exploring the language or doing quick-and-dirty coding can just use reference counting if they want. Rust supports that. There's a performance hit but that's probably fine in those use cases.

Reply on news.ycombinator.com