3 ms·

Rust is surely fine, and an improvement over C, but its main advantage is that all the rust code is written now, when everyone takes more care about security.

Rust is surely fine, and an improvement over C, but its main advantage is that all the rust code is written now, when everyone takes more care about security. It doesn't have to deal with 40 years of bad legacy code written by sloppy developers. You can obtain similar quality in a C modern code-base, using tools like static and dynamic analyzers. In fact, today the hardest issues came from multi-threading. I won't even dare to write multi-threading apps without helgrind/TSAN. And Rust doesn't help in this regard. From: https://doc.rust-lang.org/nomicon/races.html https://doc.rust-lang.org/nomicon/races.html 'So it's perfectly "fine" for a Safe Rust program to get deadlocked or do something incredibly stupid with incorrect synchronization.'

blub 10y ago
Some people take more care about writing safe & secure code today. Most only care just enough to switch to Java or Python in order not to care any more. The big question for me is what will happen when those same developers writing insecure C and C++ code start writing rust? Will they find ways to subvert the safety checks? Will they even want to subject themselves to them in the first place?
_yosefk 10y ago
I find it rather daring to use raw POSIX threads or similar, hoping that automated debugging tools operating at this abstraction level, such as Helgrind or TSAN, will pinpoint your bugs. The problem is that the state space of a thread-based program synchronizing with mutexes is too large to explore at a reasonable time. More about this: http://yosefk.com/blog/checkedthreads-bug-free-shared-memory-parallelism.html http://yosefk.com/blog/checkedthreads-bug-free-shared-memory... and http://yosefk.com/blog/making-data-races-manifest-themselves.html http://yosefk.com/blog/making-data-races-manifest-themselves... Which higher-level abstraction to use is a question and depends on the problem at hand; for throughput computing in C, Cilk is perhaps the best today (I guess you could call my own project checkedthreads a bit of a Cilk knock-off.) AFAIK, Rust developers are more interested in higher-level abstractions than Go developers (Go's built-in goroutines being on par with threads in terms of ability of automated debugging tools to flag bugs; perhaps there's work in Go on higher-level abstractions but the vibe I felt, perhaps mistakenly, is that these are non-problems, which I disagree with: http://yosefk.com/blog/parallelism-and-concurrency-need-different-tools.html http://yosefk.com/blog/parallelism-and-concurrency-need-diff...)
atilaneves 10y ago
Similar quality in a modern C codebase? No. Much better than in the past, yes, but not similar. Even if the quality _were_ similar, it'd be disproportionally more expensive to write. I just left a job in which C code was being written from scratch, in 2016. The code was awful. Coverity didn't prevent it from being awful.
nsuser2 10y ago
> And Rust doesn't help in this regard. From: https://doc.rust-lang.org/nomicon/races.html https://doc.rust-lang.org/nomicon/races.html Data races are mostly prevented through rust's ownership system: it's impossible to alias a mutable reference, so it's impossible to perform a data race. Interior mutability makes this more complicated, which is largely why we have the Send and Sync traits (see https://doc.rust-lang.org/nomicon/races.html https://doc.rust-lang.org/nomicon/races.html).

blub 10y ago

Some people take more care about writing safe & secure code today. Most only care just enough to switch to Java or Python in order not to care any more. The big question for me is what will happen when those same developers writing insecure C and C++ code start writing rust? Will they find ways to subvert the safety checks? Will they even want to subject themselves to them in the first place?

_yosefk 10y ago

I find it rather daring to use raw POSIX threads or similar, hoping that automated debugging tools operating at this abstraction level, such as Helgrind or TSAN, will pinpoint your bugs. The problem is that the state space of a thread-based program synchronizing with mutexes is too large to explore at a reasonable time. More about this: http://yosefk.com/blog/checkedthreads-bug-free-shared-memory-parallelism.html http://yosefk.com/blog/checkedthreads-bug-free-shared-memory... and http://yosefk.com/blog/making-data-races-manifest-themselves.html http://yosefk.com/blog/making-data-races-manifest-themselves... Which higher-level abstraction to use is a question and depends on the problem at hand; for throughput computing in C, Cilk is perhaps the best today (I guess you could call my own project checkedthreads a bit of a Cilk knock-off.) AFAIK, Rust developers are more interested in higher-level abstractions than Go developers (Go's built-in goroutines being on par with threads in terms of ability of automated debugging tools to flag bugs; perhaps there's work in Go on higher-level abstractions but the vibe I felt, perhaps mistakenly, is that these are non-problems, which I disagree with: http://yosefk.com/blog/parallelism-and-concurrency-need-different-tools.html http://yosefk.com/blog/parallelism-and-concurrency-need-diff...)

atilaneves 10y ago

Similar quality in a modern C codebase? No. Much better than in the past, yes, but not similar. Even if the quality _were_ similar, it'd be disproportionally more expensive to write. I just left a job in which C code was being written from scratch, in 2016. The code was awful. Coverity didn't prevent it from being awful.

nsuser2 10y ago

> And Rust doesn't help in this regard. From: https://doc.rust-lang.org/nomicon/races.html https://doc.rust-lang.org/nomicon/races.html Data races are mostly prevented through rust's ownership system: it's impossible to alias a mutable reference, so it's impossible to perform a data race. Interior mutability makes this more complicated, which is largely why we have the Send and Sync traits (see https://doc.rust-lang.org/nomicon/races.html https://doc.rust-lang.org/nomicon/races.html).