8 ms·

> Do you prefer the uncertainty of silent miscompilations and undefined behavior to upfront compiler errors? Yes because then I don't have to spend hours writi

> Do you prefer the uncertainty of silent miscompilations and undefined behavior to upfront compiler errors? Yes because then I don't have to spend hours writing esoteric spaghetti code to prove something to the compiler that is trivially known to be true. Your error is assuming static lifetime checking is free. As an engineer, I use judgement to make context-dependent trade offs. If you like playing the compiler olympics, or your employer forces you to, please use Rust.

zozbot234 2y ago
"Trivially known to be true" until the code evolves making your unstated assumptions not hold and everything breaks, often in complex and unintuitive ways involving interactions across modules. This is why these automated soundness checks are valuable.
- restalis 2y ago
  "until the code evolves [...]" That is already a desirable place to be, where you managed to get a working implementation ready to evolve. My issue with opinionated languages like Rust is that they make development more expensive. I then afford to pay the necessary work-effort for fewer projects than I otherwise could if I was to focus more on the problem(s) at hand instead of that and other mandatory constraints forced upon me by the compiler. I very much want my development tools to limit themselves on being tools, to assist me on the part of the problem I chose to focus on with little to no cost paid for their usage. I want to be able to focus on prototyping some working solution first, and only then, if the project's needs really warrant it, to switch on paying the development cost for other aspects, be it safety or whatnot.
oxnrtr 2y ago
[flagged]
adastra22 2y ago
> to prove something to the compiler that is trivially known to be true I don't think you've ever done any serious work with lifetimes. I've been a rust developer for a number of years, and I have never once encountered a situation where the rust compiler forces me to add annotations for something which is trivially true. Never. What actually happens is 95% of the time I never have to add lifetime annotations anyway because the compiler infers the correct annotation from the lifetime elision rules. The remaining 1 in 20 instances is when the borrow checker yells at me, and literally every single time it is due to a latent logic bug in my code. For example, accessing memory after it's been freed, or using a container after it has been consumed. Stuff that C++ would call "undefined behavior" and are generally considered Very Bad Things by C++ developers as well. It boggles my mind that you don't want the compiler to tell you that “you have a logic error here.”
roland35 2y ago
I've found that often when I am writing esoteric spaghetti rust code... I need to start thinking about what I am trying too do! Most of the time it's a bad idea :)
- HelloNurse 2y ago
  If one needs to "prove something to the compiler" it is usually something both complex and against the grain; on the other hand lifetime annotations are usually just "promise something to the compiler" to allow it to make a better job.
deleted 2y ago
[deleted]
rramadass 2y ago
> As an engineer, I use judgement to make context-dependent trade offs. Well said. This is why i am firmly in the Stroustrup camp of backward compatibility/zero overhead/better-C/etc. goodness of "old C++". I need to extend/maintain/rewrite tons of them and that needs to be as painless as possible. The current standards trajectory needs to be maintained. The OP article is a rather poor one with no insights but mere hoopla over nothing.
- munchler 2y ago
  If it's hoopla over nothing, why do you firmly identify with one of the factions defined by the article?
  - rramadass 2y ago
    What a silly question! There is no major schism in the C++ community as the article implies; merely a strong difference of opinion on certain proposals. This is normal in any committee. But since people are strongly wedded to their own proposals it might seem more severe than it actually is.
th2oi34234234 2y ago
LOL; someone has definitely played with type-systems here.
wiseowise 2y ago
> Yes because then I don't have to spend hours writing esoteric spaghetti code to prove something to the compiler that is trivially known to be true. And that’s exactly the reason why we need more safety in C++. I’m terrified at amount of code in real world written with this mindset.
- virgilp 2y ago
  At the same time, you should recognize that not all real code in the world is used to run planes & thermonuclear power plants. For a lot of the business software, it's actually fine if it's not perfectly safe. So if it's cheaper/ faster to develop it without paying the price of static safety checks, who is to say that this was a bad tradeoff? I actually love the ideas that Rust brought forth. It definitely has a place in the ecosystem, and I'm glad to hear critical software is being rewritten in Rust! But that doesn't mean that C++ should copy it.
  - lmm 2y ago
    > For a lot of the business software, it's actually fine if it's not perfectly safe. Is it fine if it silently gives the wrong answer? If so, why are you bothering with the software at all? In my experience all nontrivial C++ codebases have silent memory corruption bugs (at least when built with popular compilers).
    - virgilp 2y ago
      Well, let's put it like this: - Webkit, GCC, and a few others are non-trivial C++ codebases that are (I argue) useful. - In your experience, since they are non-trivial, they have silent memory corruption bugs (i.e. they are not "perfectly safe"). Does this answer the "why bother with software at all" question?
      - SpaceNugget 2y ago
        Most C++ developers care greatly about the quality of their code, and suggesting that since the code isn't in a life threatening situation like a flight controller or medical device it can be buggy with no repercussions is pretty silly. Your examples of GCC and Webkit are both projects that have spent enormous amounts of effort to be as memory safe as they can be, and have both had many memory safety related CVEs in the past. As was already pointed out, you still have to pay the cost of engineering memory safe code, even when your compiler/static analysis doesn't have your back.

zozbot234 2y ago

"Trivially known to be true" until the code evolves making your unstated assumptions not hold and everything breaks, often in complex and unintuitive ways involving interactions across modules. This is why these automated soundness checks are valuable.

restalis 2y ago
"until the code evolves [...]" That is already a desirable place to be, where you managed to get a working implementation ready to evolve. My issue with opinionated languages like Rust is that they make development more expensive. I then afford to pay the necessary work-effort for fewer projects than I otherwise could if I was to focus more on the problem(s) at hand instead of that and other mandatory constraints forced upon me by the compiler. I very much want my development tools to limit themselves on being tools, to assist me on the part of the problem I chose to focus on with little to no cost paid for their usage. I want to be able to focus on prototyping some working solution first, and only then, if the project's needs really warrant it, to switch on paying the development cost for other aspects, be it safety or whatnot.

oxnrtr 2y ago

[flagged]

adastra22 2y ago

> to prove something to the compiler that is trivially known to be true I don't think you've ever done any serious work with lifetimes. I've been a rust developer for a number of years, and I have never once encountered a situation where the rust compiler forces me to add annotations for something which is trivially true. Never. What actually happens is 95% of the time I never have to add lifetime annotations anyway because the compiler infers the correct annotation from the lifetime elision rules. The remaining 1 in 20 instances is when the borrow checker yells at me, and literally every single time it is due to a latent logic bug in my code. For example, accessing memory after it's been freed, or using a container after it has been consumed. Stuff that C++ would call "undefined behavior" and are generally considered Very Bad Things by C++ developers as well. It boggles my mind that you don't want the compiler to tell you that “you have a logic error here.”

roland35 2y ago

I've found that often when I am writing esoteric spaghetti rust code... I need to start thinking about what I am trying too do! Most of the time it's a bad idea :)

HelloNurse 2y ago
If one needs to "prove something to the compiler" it is usually something both complex and against the grain; on the other hand lifetime annotations are usually just "promise something to the compiler" to allow it to make a better job.

deleted 2y ago

[deleted]

rramadass 2y ago

> As an engineer, I use judgement to make context-dependent trade offs. Well said. This is why i am firmly in the Stroustrup camp of backward compatibility/zero overhead/better-C/etc. goodness of "old C++". I need to extend/maintain/rewrite tons of them and that needs to be as painless as possible. The current standards trajectory needs to be maintained. The OP article is a rather poor one with no insights but mere hoopla over nothing.

munchler 2y ago
If it's hoopla over nothing, why do you firmly identify with one of the factions defined by the article?
- rramadass 2y ago
  What a silly question! There is no major schism in the C++ community as the article implies; merely a strong difference of opinion on certain proposals. This is normal in any committee. But since people are strongly wedded to their own proposals it might seem more severe than it actually is.

th2oi34234234 2y ago

LOL; someone has definitely played with type-systems here.

wiseowise 2y ago

> Yes because then I don't have to spend hours writing esoteric spaghetti code to prove something to the compiler that is trivially known to be true. And that’s exactly the reason why we need more safety in C++. I’m terrified at amount of code in real world written with this mindset.

virgilp 2y ago
At the same time, you should recognize that not all real code in the world is used to run planes & thermonuclear power plants. For a lot of the business software, it's actually fine if it's not perfectly safe. So if it's cheaper/ faster to develop it without paying the price of static safety checks, who is to say that this was a bad tradeoff? I actually love the ideas that Rust brought forth. It definitely has a place in the ecosystem, and I'm glad to hear critical software is being rewritten in Rust! But that doesn't mean that C++ should copy it.
- lmm 2y ago
  > For a lot of the business software, it's actually fine if it's not perfectly safe. Is it fine if it silently gives the wrong answer? If so, why are you bothering with the software at all? In my experience all nontrivial C++ codebases have silent memory corruption bugs (at least when built with popular compilers).
  - virgilp 2y ago
    Well, let's put it like this: - Webkit, GCC, and a few others are non-trivial C++ codebases that are (I argue) useful. - In your experience, since they are non-trivial, they have silent memory corruption bugs (i.e. they are not "perfectly safe"). Does this answer the "why bother with software at all" question?
    - SpaceNugget 2y ago
      Most C++ developers care greatly about the quality of their code, and suggesting that since the code isn't in a life threatening situation like a flight controller or medical device it can be buggy with no repercussions is pretty silly. Your examples of GCC and Webkit are both projects that have spent enormous amounts of effort to be as memory safe as they can be, and have both had many memory safety related CVEs in the past. As was already pointed out, you still have to pay the cost of engineering memory safe code, even when your compiler/static analysis doesn't have your back.