DUduneroadrunner·Dec 30, 2018
Well like I said, if you already have a driver written in C (or C++), translating it to the safe subset of C++ would be less work as most of the code would remain unchanged and the unsafe elements (like pointers, arrays, etc.) map to direct (safe) replacements. And your driver maintainers/authors may already be familiar with C++ (if not big fans of it :) .
While the OP may demonstrate that other languages aren't always that bad in practice, I think the consensus is that Rust and C/C++ are the appropriate languages when maximum efficiency and minimum overhead are desired.
While Rust is a good option, the (safe subset of the) language has an intrinsic shortcoming that doesn't seem to be generally acknowledged. The forthcoming C++ "lifetime checker" (static analyzer) has the same issue [1]. Essentially, if you have a list (or any dynamic con
Read the rest
tainer) of references to a given set of existing objects, you cannot (temporarily) insert a reference to a (newly created) object that may not outlive the container itself.
In my view, this is a problem. The workarounds are intrusive, inconvenient and/or involve significant overhead. Which makes it tempting to just resort to unsafe Rust in those cases. (And of course this specific example is representative of a whole class of situations with a similar dilemma.) The safe C++ subset doesn't suffer the same issue. (Because in some sense, C++ is still a more "powerful" language.)
[1] https://github.com/duneroadrunner/misc/blob/master/201/8/Jul...