5 ms·

> 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 c

by 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.
    - pdimitar 3y ago
      > 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. Perfectly valid, though in the light of this I'd say your arguments against Rust come off as biased in favor of a single use-case and I am sure you're aware of this. > No need to snark. Okay, though I am guessing you understood that the snark was because you criticized something that's beyond the control of at least 95% of all working programmers everywhere. I get the stream of consciousness part, I just didn't feel that that part of your comment was helpful of the discussion. Sorry if I came across as rude. > 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.). I've read all your other comments and I am not disputing that you are arguing in good faith; IMO that much is visible, I just find it slightly puzzling how your stance on it is kind of going up and down. :) The second part of your quote above is a bit bizarre because it's been quite a while since I've seen Rust zealotry on HN (at least 2.5 years IIRC). Every community has bad apples, IMO you don't need to preemptively defend against the a-holes that every community has (and that haven't shown up on HN for a long time, as far as I can tell at least). > The thing is, my work is a hobby that pays. While that likely does wonders for your mental health (and makes me envy you and get saddened that it's not the case for me) it also comes with this unique drawback that you already observed: you get called out by the programmers who don't work in the area(s) they love for not utilizing guard rails that are a good practice in a team setting. This is also likely made even worse by the fact that you work solo. Again, good for you, for real, but that also makes you biased in a way that seems... not very team-cooperative. I don't stamp PRs with an approval if they don't cover a certain baseline of testing, type specs (for dynamic languages), some docs / comments, and the like. Tinkering is nice and all but I'd probably make your life living hell if I had to review your PRs. :D (Have to stop here for a few secs to giggle.) > I'm not a zealot living with a single language. Nor is any Rust dev that I knew (dozens). ¯\_(ツ)_/¯ > My beef is always with the community of a language, not the language itself. OK, that's valid but I'd still urge you to reassess your opinion of the Rust community. I haven't met a legit a-hole in years. There are always some dismissive people on this or that forum but meh, vanishing minority to the point that I don't remember the last time I received a semi-snarky response on a subreddit or on the Rust Users forum. And finally: > You have a very wrong image of me in your head. That is quite likely, written text does not carry tone and spirit at all. Though that always has two sides: I misconstrued some of your comments more negatively than I should but maybe you also didn't come across as neutral as you are saying that you are (example: you seem to be negatively biased towards the Rust community). No harm done IMO, and I don't think that I disagree strongly with anything you said. I am mostly saying that you working what you love and working solo is keeping you quite disconnected from what are good team practices. Maybe you have a compiler in your brain as you have alluded to but I will trust a good test suite over a human brain every day.

by Too 3y ago

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.
  - pdimitar 3y ago
    > 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. Perfectly valid, though in the light of this I'd say your arguments against Rust come off as biased in favor of a single use-case and I am sure you're aware of this. > No need to snark. Okay, though I am guessing you understood that the snark was because you criticized something that's beyond the control of at least 95% of all working programmers everywhere. I get the stream of consciousness part, I just didn't feel that that part of your comment was helpful of the discussion. Sorry if I came across as rude. > 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.). I've read all your other comments and I am not disputing that you are arguing in good faith; IMO that much is visible, I just find it slightly puzzling how your stance on it is kind of going up and down. :) The second part of your quote above is a bit bizarre because it's been quite a while since I've seen Rust zealotry on HN (at least 2.5 years IIRC). Every community has bad apples, IMO you don't need to preemptively defend against the a-holes that every community has (and that haven't shown up on HN for a long time, as far as I can tell at least). > The thing is, my work is a hobby that pays. While that likely does wonders for your mental health (and makes me envy you and get saddened that it's not the case for me) it also comes with this unique drawback that you already observed: you get called out by the programmers who don't work in the area(s) they love for not utilizing guard rails that are a good practice in a team setting. This is also likely made even worse by the fact that you work solo. Again, good for you, for real, but that also makes you biased in a way that seems... not very team-cooperative. I don't stamp PRs with an approval if they don't cover a certain baseline of testing, type specs (for dynamic languages), some docs / comments, and the like. Tinkering is nice and all but I'd probably make your life living hell if I had to review your PRs. :D (Have to stop here for a few secs to giggle.) > I'm not a zealot living with a single language. Nor is any Rust dev that I knew (dozens). ¯\_(ツ)_/¯ > My beef is always with the community of a language, not the language itself. OK, that's valid but I'd still urge you to reassess your opinion of the Rust community. I haven't met a legit a-hole in years. There are always some dismissive people on this or that forum but meh, vanishing minority to the point that I don't remember the last time I received a semi-snarky response on a subreddit or on the Rust Users forum. And finally: > You have a very wrong image of me in your head. That is quite likely, written text does not carry tone and spirit at all. Though that always has two sides: I misconstrued some of your comments more negatively than I should but maybe you also didn't come across as neutral as you are saying that you are (example: you seem to be negatively biased towards the Rust community). No harm done IMO, and I don't think that I disagree strongly with anything you said. I am mostly saying that you working what you love and working solo is keeping you quite disconnected from what are good team practices. Maybe you have a compiler in your brain as you have alluded to but I will trust a good test suite over a human brain every day.