5 ms·

Another option is to use a memory safe subset of C++ [1]. It should be less work to migrate existing C drivers as (reasonable) C code maps directly into the saf

Another option is to use a memory safe subset of C++ [1]. It should be less work to migrate existing C drivers as (reasonable) C code maps directly into the safe C++ subset. And the migration can be done incrementally with corresponding incremental safety benefits. [1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus https://github.com/duneroadrunner/SaferCPlusPlus

pjmlp 8y ago
Only if the team plays along regarding static analysers and compiler warnings as errors.
- newnewpdro 8y ago
  Wouldn't you simply enforce this with automation if you were making a serious effort? It's already quite common for github PR's to require myriad CI tests to pass before anything can be merged... those can incorporate static analysis and warnings as errors.
  - pjmlp 8y ago
    Still needs to have the buy-in from the team. Try to be that clever guy putting such gates into place without having the team be on the same wave length. Github is a bubble, there are tons of software projects out there, using a myriad of build infrastructures, or even just doing plain old IDE builds (yes I know, but it is as it is).
    - newnewpdro 8y ago
      Convincing your team to switch languages is infinitely more difficult than adding infrastructure to enforce good hygiene. So I don't really see what your point is, it's moot.
      - pjmlp 8y ago
        This whole thread started about enforcing behaviors that are largely ignored by enterprise developers outside HN bubble. In no point there was a mention of switching languages.
        newnewpdro 8y ago
        Ah, this had left an lingering impression in my mind: "Why do that, if there are languages that do it by design?" But I see it wasn't your comment, my bad :)
shmerl 8y ago
Why do that, if there are languages that do it by design?
- duneroadrunner 8y ago
  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 container) 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/implications%20of%20the%20lifetime%20checker%20restrictions.md https://github.com/duneroadrunner/misc/blob/master/201/8/Jul...

pjmlp 8y ago

Only if the team plays along regarding static analysers and compiler warnings as errors.

newnewpdro 8y ago
Wouldn't you simply enforce this with automation if you were making a serious effort? It's already quite common for github PR's to require myriad CI tests to pass before anything can be merged... those can incorporate static analysis and warnings as errors.
- pjmlp 8y ago
  Still needs to have the buy-in from the team. Try to be that clever guy putting such gates into place without having the team be on the same wave length. Github is a bubble, there are tons of software projects out there, using a myriad of build infrastructures, or even just doing plain old IDE builds (yes I know, but it is as it is).
  - newnewpdro 8y ago
    Convincing your team to switch languages is infinitely more difficult than adding infrastructure to enforce good hygiene. So I don't really see what your point is, it's moot.
    - pjmlp 8y ago
      This whole thread started about enforcing behaviors that are largely ignored by enterprise developers outside HN bubble. In no point there was a mention of switching languages.
      - newnewpdro 8y ago
        Ah, this had left an lingering impression in my mind: "Why do that, if there are languages that do it by design?" But I see it wasn't your comment, my bad :)

shmerl 8y ago

Why do that, if there are languages that do it by design?

duneroadrunner 8y ago
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 container) 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/implications%20of%20the%20lifetime%20checker%20restrictions.md https://github.com/duneroadrunner/misc/blob/master/201/8/Jul...