4 ms·

I'm a big proponent of choosing the right tool for the job at hand. On the other hand, I'm a big opponent of throwing stones because of emotions. C/C++ can be

I'm a big proponent of choosing the right tool for the job at hand. On the other hand, I'm a big opponent of throwing stones because of emotions. C/C++ can be made memory safe. You need to use a couple of data structures and need to be a little bit more vigilant and make periodic tests. If the developers can't bother to learn them, that's fine. However, saying something is impossible and being adamant about that without research is harmful as it is. I sometimes say things about Rust, people correct me, and I learn. Some people see the evidence contrary to their beliefs and get triggered because they were wrong in the first place. This is what I'm bothered about. I don't use C or C++ only. I'm not against Rust either. I'm against positioning of Rust and C/C++ from Rust community's perspective. That's all. Lastly, I'm not a proponent of reckless coding either. Totally contrary. I take pride in writing robust code. However, I want to be able to write code which breaks on purpose to see what hardware does, to understand the failure modes or gotchas of the architecture I'm running on.

Too 3y ago
> C/C++ can be made memory safe. In theory, in small toy projects or with a massive NASA budget - Yes. In any other project, with normal (aka too short) time constraints and average skilled developers, it’s not. 35 years of trying, has proven us humans that, several times over.
- bayindirh 3y ago
  I think it's much simpler than that, because I did it myself, on a HPC scale high performance materials simulation code. Is it simple? Yes. It's easy? No, because you need to design for that and be mindful during implementation (const correctness, guarantees by design, valgrind tests, unit sealing, etc.). I think it can be made much simpler with smart pointers, etc. if speed is not that important. We push humans too much to develop things fast. C++ is not very conductive to that, yet it's the only tool which works in some cases. I won't retype my views about Rust because it's all over this thread. Just I'll tell that I'm against vilifying C/C++ as evil because they can be held wrong. I believe things can and shall be able to held wrong. Knowing failure modes and shortcomings is a plus. Because you can then hold dangerous things right, and appreciate things which promote holding things right.
  - pdimitar 3y ago
    > I think it can be made much simpler with smart pointers, etc. if speed is not that important. Why all the complex dances, and you even lose performance by doing them as well? Use Rust and it's going to solve most of those troubles for you. Though granted, you can make a mess in Rust as well (by using various escape hatches) but you really have to try in order to do so. > We push humans too much to develop things fast. I agree, most programmers agree in fact. So when are you talking in front of the UN and when do the worldwide regulation against this problem begin? When will companies start getting a 10% revenue fine for not adhering to the regulation? ...You're preaching to the choir here. We all know the ideal theoretical reality. I too wish I had more generous deadlines. > Just I'll tell that I'm against vilifying C/C++ as evil because they can be held wrong. It boils down to: Rust can be held wrong in much less ways than C/C++. That's the core argument. Everything else is more or less a distraction, my own comment here included. Computers should work for us, not we for them. Rust helps my human brain not to misstep. You'd likely label me as incompetent but I'd disagree and say "none of the gnarly details of the bound checking and lifetimes arw interesting for me, I'm writing the code, compiler will correct me if I assumed wrongly". Me and the compiler are a team and we both do what we do best. > I believe things can and shall be able to held wrong. As another poster said: do it in your hobby work. If I have to deal with subtle memory safety errors in your professional code just because you have such a life credo then I will curse at you and label you as incompetent. I love tinkering. I keep it to myself and to other hobbyists. Professional work should be, you know, professional.
    - bayindirh 3y ago
      > Why all the complex dances, and you even lose performance by doing them as well? Simple. Because Rust doesn't have BLAS, at least not yet. Though I doubt that I'll ever migrate my high performance code to Rust. > So when are you talking in front of the UN and when do the worldwide regulation against this problem begin? No need to snark. I write my comments as streams of consciousness, and I just wrote what I feel. I know it's a simple fact, but I'm not here for stone matches. > Rust can be held wrong in much less ways than C/C++. That's the core argument. Yep, and I'm very aware of this one. I think I need to clarify once more: I'm not against Rust. I'm against weaponization of Rust (via LLVM, via RIIR w/MIT, radical evangelism, etc.). > Computers should work for us, not we for them. I agree. I want to freedom to explore. Because I'm a hardware geek, and I like to PEEK, POKE, and understand. > You'd likely label me as incompetent... No, I don't do that. You have a very wrong image of me in your head. I'm only pro-choice in programming languages. If they are not interesting for you, that's OK, plus your interests are not my business. I have no interest in dictating anything to you or to form you to my liking. On the other hand, I operate from a slightly different perspective. When I write code, I execute it in my mind at the same time, like a computer. Lifetimes, etc., the whole circus. This helps me to write better code. Then I pass it to compiler, with -Werror nonetheless. The code I write compiles without warning, otherwise it's unacceptable. > As another poster said: do it in your hobby work. The thing is, my work is a hobby that pays. I always select the tools before starting a job. What we're writing? Is it speed critical? Is it security critical? What happens if it fails, etc. Put the specs, define the required tools for the job, then start the blueprint in that language. If that's Rust? Go? C++? Erlang? Bash? Malbolge? Select the appropriate one. Don't know it? Doesn't matter. Go, learn. This is how I do it. I'm not a zealot living with a single language. There are no bad languages, only bad solutions to problems at hand. My beef is always with the community of a language, not the language itself. That's being said, I'm waiting gccrs to start Rust, because I have a single rule: Toolchain must be GPL licensed. I don't like to depend on a toolchain a vendor can fork and close. The code must stay buildable.
shakow 3y ago
> C/C++ can be made memory safe Famous last words.
pjc50 3y ago
> C/C++ can be made memory safe .. but it's much harder to prove your work is memory safe. sel4 is memory safe C, for example. The safety is achieved by a large external theorem prover and a synced copy written in Haskell. https://github.com/seL4/l4v https://github.com/seL4/l4v Typechecks are form of proof. It's easier to write provably safe Rust than provably safe C because the proofs and checker are integrated.
- bayindirh 3y ago
  I have never claimed that it's easy. I said doing it is simple, and prone to errors, and needs to be verified either by design or tests, ideally both. I'm aware of seL4. They're doing an amazing job of verifying what they have written. However, why I'm is so adamant is because I have done something similar myself, albeit in a weaker form, but at least I verified that every part of my code is not doing funny things by vigorously testing it in valgrind in different scenarios both in units and end to end. Again, I'm not against Rust. I'm against vilifying languages.
  - throwaway2037 3y ago
    C++ uber fan here. > C/C++ can be made memory safe > I have never claimed that it's easy. So... you didn't say much. I can rewrite your sentence with assembler or machine code. Again, not much said.
    - bayindirh 3y ago
      I have actually said so much more around the thread. Maybe you should give a look at them.

Too 3y ago

> C/C++ can be made memory safe. In theory, in small toy projects or with a massive NASA budget - Yes. In any other project, with normal (aka too short) time constraints and average skilled developers, it’s not. 35 years of trying, has proven us humans that, several times over.

bayindirh 3y ago
I think it's much simpler than that, because I did it myself, on a HPC scale high performance materials simulation code. Is it simple? Yes. It's easy? No, because you need to design for that and be mindful during implementation (const correctness, guarantees by design, valgrind tests, unit sealing, etc.). I think it can be made much simpler with smart pointers, etc. if speed is not that important. We push humans too much to develop things fast. C++ is not very conductive to that, yet it's the only tool which works in some cases. I won't retype my views about Rust because it's all over this thread. Just I'll tell that I'm against vilifying C/C++ as evil because they can be held wrong. I believe things can and shall be able to held wrong. Knowing failure modes and shortcomings is a plus. Because you can then hold dangerous things right, and appreciate things which promote holding things right.
- pdimitar 3y ago
  > I think it can be made much simpler with smart pointers, etc. if speed is not that important. Why all the complex dances, and you even lose performance by doing them as well? Use Rust and it's going to solve most of those troubles for you. Though granted, you can make a mess in Rust as well (by using various escape hatches) but you really have to try in order to do so. > We push humans too much to develop things fast. I agree, most programmers agree in fact. So when are you talking in front of the UN and when do the worldwide regulation against this problem begin? When will companies start getting a 10% revenue fine for not adhering to the regulation? ...You're preaching to the choir here. We all know the ideal theoretical reality. I too wish I had more generous deadlines. > Just I'll tell that I'm against vilifying C/C++ as evil because they can be held wrong. It boils down to: Rust can be held wrong in much less ways than C/C++. That's the core argument. Everything else is more or less a distraction, my own comment here included. Computers should work for us, not we for them. Rust helps my human brain not to misstep. You'd likely label me as incompetent but I'd disagree and say "none of the gnarly details of the bound checking and lifetimes arw interesting for me, I'm writing the code, compiler will correct me if I assumed wrongly". Me and the compiler are a team and we both do what we do best. > I believe things can and shall be able to held wrong. As another poster said: do it in your hobby work. If I have to deal with subtle memory safety errors in your professional code just because you have such a life credo then I will curse at you and label you as incompetent. I love tinkering. I keep it to myself and to other hobbyists. Professional work should be, you know, professional.
  - bayindirh 3y ago
    > Why all the complex dances, and you even lose performance by doing them as well? Simple. Because Rust doesn't have BLAS, at least not yet. Though I doubt that I'll ever migrate my high performance code to Rust. > So when are you talking in front of the UN and when do the worldwide regulation against this problem begin? No need to snark. I write my comments as streams of consciousness, and I just wrote what I feel. I know it's a simple fact, but I'm not here for stone matches. > Rust can be held wrong in much less ways than C/C++. That's the core argument. Yep, and I'm very aware of this one. I think I need to clarify once more: I'm not against Rust. I'm against weaponization of Rust (via LLVM, via RIIR w/MIT, radical evangelism, etc.). > Computers should work for us, not we for them. I agree. I want to freedom to explore. Because I'm a hardware geek, and I like to PEEK, POKE, and understand. > You'd likely label me as incompetent... No, I don't do that. You have a very wrong image of me in your head. I'm only pro-choice in programming languages. If they are not interesting for you, that's OK, plus your interests are not my business. I have no interest in dictating anything to you or to form you to my liking. On the other hand, I operate from a slightly different perspective. When I write code, I execute it in my mind at the same time, like a computer. Lifetimes, etc., the whole circus. This helps me to write better code. Then I pass it to compiler, with -Werror nonetheless. The code I write compiles without warning, otherwise it's unacceptable. > As another poster said: do it in your hobby work. The thing is, my work is a hobby that pays. I always select the tools before starting a job. What we're writing? Is it speed critical? Is it security critical? What happens if it fails, etc. Put the specs, define the required tools for the job, then start the blueprint in that language. If that's Rust? Go? C++? Erlang? Bash? Malbolge? Select the appropriate one. Don't know it? Doesn't matter. Go, learn. This is how I do it. I'm not a zealot living with a single language. There are no bad languages, only bad solutions to problems at hand. My beef is always with the community of a language, not the language itself. That's being said, I'm waiting gccrs to start Rust, because I have a single rule: Toolchain must be GPL licensed. I don't like to depend on a toolchain a vendor can fork and close. The code must stay buildable.

shakow 3y ago

> C/C++ can be made memory safe Famous last words.

pjc50 3y ago

> C/C++ can be made memory safe .. but it's much harder to prove your work is memory safe. sel4 is memory safe C, for example. The safety is achieved by a large external theorem prover and a synced copy written in Haskell. https://github.com/seL4/l4v https://github.com/seL4/l4v Typechecks are form of proof. It's easier to write provably safe Rust than provably safe C because the proofs and checker are integrated.

bayindirh 3y ago
I have never claimed that it's easy. I said doing it is simple, and prone to errors, and needs to be verified either by design or tests, ideally both. I'm aware of seL4. They're doing an amazing job of verifying what they have written. However, why I'm is so adamant is because I have done something similar myself, albeit in a weaker form, but at least I verified that every part of my code is not doing funny things by vigorously testing it in valgrind in different scenarios both in units and end to end. Again, I'm not against Rust. I'm against vilifying languages.
- throwaway2037 3y ago
  C++ uber fan here. > C/C++ can be made memory safe > I have never claimed that it's easy. So... you didn't say much. I can rewrite your sentence with assembler or machine code. Again, not much said.
  - bayindirh 3y ago
    I have actually said so much more around the thread. Maybe you should give a look at them.