3 ms·

Yes. But there's also substantial cost in abandoning existing C/C++ codebases and rewriting them from scratch. Since the advances of C++11, something like Safer

Yes. But there's also substantial cost in abandoning existing C/C++ codebases and rewriting them from scratch. Since the advances of C++11, something like SaferCPlusPlus[1] (a memory safe dialect/subset of C++) might be a more practical/expedient way to address memory safety in many cases. An automated conversion (assistance) tool is being worked on, but could use more bodies if anyone's looking for a project to contribute to. :) [1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus-BenchmarksGame https://github.com/duneroadrunner/SaferCPlusPlus-BenchmarksG...

coldtea 10y ago
>Yes. But there's also substantial cost in abandoning existing C/C++ codebases and rewriting them from scratch. Fortunately, we don't have too. We can always a) just write NEW stuff in Rust, or b) just use Rust to extend and piecemeal replace old apps (since it supports linking to C and/or C++ libs).
- duneroadrunner 10y ago
  > or b) just use Rust to extend and piecemeal replace old apps (since it supports linking to C and/or C++ libs). Yes, Rust's FFI support is nice, but rewriting piecemeal is still rewriting. (And retesting.) It should be faster and easier to just replace unsafe elements in existing code. Of course, that doesn't conflict with choosing Rust for new components and rewrites of existing components when the time and resources are available. Btw, I haven't investigated lately, what is the state of Rust interoperability with C++ interfaces?
  - kbenson 10y ago
    > Btw, I haven't investigated lately, what is the state of Rust interoperability with C++ interfaces? Not that I'm an expert on the matter, I think it's still through C interop both directions. There was a github project for a Rust module submitted to HN recently[1] to correctly deal with C++ name mangling, and I think it was mentioned that the plan is for it to eventually be used as part of the future C++ interop plans, but I could be misremembering. 1: https://news.ycombinator.com/item?id=13706799 https://news.ycombinator.com/item?id=13706799
tmccrmck 10y ago
There's also checkedc from Microsoft. https://github.com/Microsoft/checkedc https://github.com/Microsoft/checkedc

coldtea 10y ago

>Yes. But there's also substantial cost in abandoning existing C/C++ codebases and rewriting them from scratch. Fortunately, we don't have too. We can always a) just write NEW stuff in Rust, or b) just use Rust to extend and piecemeal replace old apps (since it supports linking to C and/or C++ libs).

duneroadrunner 10y ago
> or b) just use Rust to extend and piecemeal replace old apps (since it supports linking to C and/or C++ libs). Yes, Rust's FFI support is nice, but rewriting piecemeal is still rewriting. (And retesting.) It should be faster and easier to just replace unsafe elements in existing code. Of course, that doesn't conflict with choosing Rust for new components and rewrites of existing components when the time and resources are available. Btw, I haven't investigated lately, what is the state of Rust interoperability with C++ interfaces?
- kbenson 10y ago
  > Btw, I haven't investigated lately, what is the state of Rust interoperability with C++ interfaces? Not that I'm an expert on the matter, I think it's still through C interop both directions. There was a github project for a Rust module submitted to HN recently[1] to correctly deal with C++ name mangling, and I think it was mentioned that the plan is for it to eventually be used as part of the future C++ interop plans, but I could be misremembering. 1: https://news.ycombinator.com/item?id=13706799 https://news.ycombinator.com/item?id=13706799

tmccrmck 10y ago

There's also checkedc from Microsoft. https://github.com/Microsoft/checkedc https://github.com/Microsoft/checkedc