6 ms·

Oh no, no, no! Some people may reasonably, with some extreme care and diligence, maybe try to claim they can write safe and UB-free C code. If stars align prope

by akavel 9y ago

Oh no, no, no! Some people may reasonably, with some extreme care and diligence, maybe try to claim they can write safe and UB-free C code. If stars align properly. (See maybe SQLite. Seen as one of the pinnacles of crazy pedantism in C. Also, see the article about errors found recently in SQLite with fuzzing!) But with C++, it's just impossible for a human. It's too big, too quirky, too big, too wide, too deep, too tricky, too big, too complicated, and also too huge. And purposefully (sic! for performance) sprinkled with UB, which means barbed fences, trip-wire mines (to boost your in-flight performance), and hidden pit traps. Writing C++ code longer than a few lines without UB is humanly impossible. Sorry. And that's just about UB, because it's the most unpredictable thing; but there's still exception safety, for example, which you also should be doing, which can "only" spoil your code's logic (and then, obviously, go on writing over random memory, but that's nothing uncommon for us C++ers). Is every line of your C++ codebase exception safe? Yeah, sure. Good luck. And "modern C++" only means more C++. Because backwards compatibility. Unless at some point some quest for a "safe subset of C++" finally gains traction, which may maybe bring back some sanity. I do really hope for that. A personal opinion from a person who loved C++ for quite some time, before diving deep enough to realize how dark is the abyss.

lj3 9y ago
> Oh no, no, no! Some people may reasonably, with some extreme care and diligence, maybe try to claim they can write safe and UB-free C code. If stars align properly. Why the sarcasm?
- akavel 9y ago
  I'm afraid I was not being sarcastic. Sorry. This is a totally honest and dead serious opinion from a long time C & C++ user. ("stars aligning" here means "you must also have luck". As I said: see SQLite.)
  - FRex 9y ago
    Then just delete your entire OS or at least your browser, don't force yourself to use C and C++ software. Seriously. I'll let you keep LLVM so you can play with Rust. There's disliking language or the boilerplate it forces on the programmer which I can REALLY understand in case of these two and there's being a jerk and an idiot and saying any C++ program that isn't few lines is broken by the UB, you need stars aligning to write safe C, they are impossible to write anything substantial, safe and useful in, etc. and anyone who tells you otherwise is implicitly a very bad programmer who does their job wrong and endangers people.
    - cyphar 9y ago
      I'm not sure I agree with the amount of hyperbole in the original post, but you must be joking if you want to claim that browsers or OSes are "safe" in the Rust sense of the word. Use after frees and numerous other memory bugs are discovered all the time in C/C++ programs (including kernels and browsers). This isn't an imaginary problem. Then combine multithreading and you've got a whole extra level of possible issues. Rust does solve many of these problems, and you can prove it does so mathematically. I understand why people don't like the use of the term "safe" because it feels like a value judgement. But I think people's egos really should be a bit less fragile when discussing language choices. > Then just delete your entire OS or at least your browser, don't force yourself to use C and C++ software. With RedoxOS you actually could do that in the near future once it supports some more hardware. The kernel and entire userland (with graphics) is written in Rust. And they did it in 2 years. If nothing else you have to admit that there are some very talented engineers using Rust.
      - FRex 9y ago
        Your point being exactly what? Don't put words in my mouth because I never claimed C and C++ are as safe as Rust, just that they are good enough for millions, including you, to rely on daily with their lives and that Rust itself relies on some C++ (LLVM). I'd even say that yes, C is the least friendly and most spartan language and C++ is the most complex and hard language that are in wide use nowdays but that wasn't the OP's claim. The OP's claim was ridiculous and on the level of opinion people have of Java applets ("totally unsafe", "useless", etc.). These people who have such opinions of them don't run them in their browsers so you should not run any C or C++ on your machine either or you are clearly overdramatizing. Mathematical provability and technical excellence has sadly little to do with adoption - see where JavaScript, Erlang, Haskell, OCalm, Modula, etc. ended up and tell me every language got what it deserved based on its own merit. Fanboying over Rust and RedoxOS (it being impressive or not is besides the point) won't fix all that "doable if stars align C" and "humanly impossible C++ that has UB even after few lines" code out there in the government, power plants (including nuclear), infrastructure, stores, embedded, banks, ... Egos have nothing to do with it. I dislike JavaScript, Java and C# personally (not for any technical reasons but due to my tastes) but if I've seen someone saying the are useless and everything written in them is broken I'd call BS. I'm similarly fond of Free Pascal with LCL for personal GUI toys but if someone said it'll take over the world and destroy Qt and GTK+ behemoths I'd also call BS. Hell, I'd defend your precious little Rust if someone said something stupid about it. There's factual critique (which I have lots of myself and I don't recommend C or C++ to new hobbyist programmers but Python3), there's personal taste (that you mustn't camouflage as technical opinions) and then there's pedal to the metal "I hate the language so it's totally useless and no human can use it" BS like the OP's comment. Rust supposedly targets C and C++ programmers so it shouldn't be acceptable to shit all over their tools and by extension their work, telling them they are stupid for liking these languages and are doing everything wrong as an engineer. The fact that such BS is disallowed in official Rust spaces is really telling of how idiotic and ridiculous it is: https://news.ycombinator.com/item?id=14755394 https://news.ycombinator.com/item?id=14755394
RcouF1uZ4gsC 9y ago
Basically exception safety is a solved problem in Modern C++. If you use RAIIike it was meant to be used, exception safety is not that big a deal.
- tomjakubowski 9y ago
  True, I guess, for "business logic"-y classes. Not true at all for data structures, particularly those that are templates.
  - AnimalMuppet 9y ago
    How is it not true for data structures? Even templated ones?
- akavel 9y ago
  For serious exception safety, you have to be able to prove that all invariants all the code of your class relies on are kept between every 2 subsequent lines of your code in that class. Because exception can occur everywhere. And actually, I oversimplified, because often you must also know what happens in each and every operator you use, including implicit casting operators, and also in your destructors and constructors, including implicit ones. Each of those may or may not throw, and each of those may have some internal state, or modify your state in unexpected ways during an exception. RAII gives you primitives which you trust are written with exception safety w.r.t. their inner invariants. But you build some code on it, which has its own invariants. Do you prove them between every 2 lines of your code every time you change a line in your code? After I read enough about exception safety, I realized how hard it is to keep watertightly.
bandook_raja 9y ago
do you mind me providing a bit personal suggestion? When you've began resorting to play of words like 'barbed fences, trip-wire mines...' instead of providing concrete proof/examples in your post, you've already lost your argument. > Writing C++ code longer than a few lines without UB is humanly impossible. Do you want me to provide one for you? Because that will definitely change your definition of 'humanly impossible' tasks and might also bring you back from realms of using comically bad phrases..
- akavel 9y ago
  Ok, please let me ask you a question: have you read all the fragments of The ISO C++ Standard regarding undefined behavior? I have not, but I've read enough fragments/quotes to raise hair on my back and show me how many assumptions I had and assumed safe were subtly wrong. If you have not read all the fragments, you by definition don't know enough about UB to protect against it! Sorry.
blub 9y ago
I struggle to imagine how you could be more wrong. C offers minimal if any possibilities for writing safe code, while C++ offers many. Anybody who has the faintest clue about both languages should know that.
- pcwalton 9y ago
  I actually feel that C++ memory management is less safe than that of C, because smart pointers provide the same opportunity for use-after-free while being much more opaque about when the destruction occurs. The rules about when destructors of temporaries are called in the evaluation of expressions are subtle.
  - blub 9y ago
    I'd be happy to discuss an example, because right now the idea that smart pointers are opaque about destruction is unfortunately too abstract for me to give a helpful reply to.
    - pcwalton 9y ago
      Consider situations like this: https://stackoverflow.com/questions/17362673/temporary-lifetime-extension https://stackoverflow.com/questions/17362673/temporary-lifet... It's undefined behavior, despite not calling free anywhere. Replace with std::string and it could be use after free. In C, UAF wouldn't happen that silently for heap memory.
      - blub 9y ago
        A similar example was posted by matthieu_m on Reddit a while back, but that's still not worse than C, even if it's an unfortunate gap in compiler diagnostics. From my POV compilers should warn that this code is potentially dangerous. My rule is: never return a reference or pointer from a function to something whose lifetime you don't have control of.
        9y ago
FRex 9y ago
To help protect you from these unsafe programs in obsolete languages I compiled a small list of software in C or C++ that you need to delete ASAP to ensure your safety: 1. Windows OS. 2. Windows kernel (mobile too). 3. Linux kernel (android too). 4. Bash, zsh, csh, fish, etc. 5. C#, Java, Ruby, Python, etc. 6. Parts of Rust backend, namely LLVM :(. 7. Apache, nginx, etc. 8. Filesystems. 9. Most drivers. 10. Router software. 11. Linux graphical environments (most/all are C or C++ and use GTK+ or Qt). 12. Any other kernels/OSes (any BSD, Haiku, iOS, etc.). Be sure to not use rm, bash, zsh, windows explorer right click + delete, etc. to delete these as that'd be relying on definitely broken software written in obsolete languages too! On a more serious note: IF you knew C++ at all you'd really know better than to say things like these and I have no idea where did you get the information about UB, overwriting random memory or using exceptions (Qt is famous for using none at all for a good reason) being common in C++. And what people use is the sane subset. When was the last time you've seen outside of some obscure specific place any of: virtual or non public inheritance, pointers to members, switching [] operator arguments for C arrays, placement new, manually calling destructors, using templates or macros to do compile time programming, etc? Considering your ignorance of the fact you use tons of rock solid C++ software daily I'd think you don't know what most or all of these even are. Rust fanboys like you who speak of C and C++ programmers like of idiots who write unsafe programs that endanger people is exactly why I'm not using Rust (yet?). If a community seems that toxic at a distance I'm not even going to try to come closer. It's even worse than Java or C# fanboys who seem to forget what their VMs are in because they are at least fanboying over HUGE enterprise proven languages. Rust on the other hand does have a few big projects (but Servo is a toy and few lines around hundreds of thousands of C++ in Firefox doesn't make it a Rust project) and looks more promising than D ever did but fanboys are acting like it's the next C++, Java, Julia and C# combined and grasping at straws "one package in choco is in Rust!", "easy to call C code!", ...
- akavel 9y ago
  [edit: ah, potentially my best argument regarding UB, that I thought of in another reply in this thread: so, please tell me now, have you read all the fragments of The ISO C++ Standard regarding UB? Because if not, you by definition don't know when you may be committing UB! :) And what I can tell you, is that I have not read all of them, but I have read enough of them to raise hair on my back and make me absolutely doubt all C++ code I've ever written, or would possibly ever write in future.] Please note I didn't say a word about Rust here :) That's your overinterpretation. First of all, I never actually used Rust; from what I've seen, I feel it has some potential and good ideas; but OTOH, I also get the feeling that one is forced to use 'unsafe' blocks from time to time anyway, so there's still some area for self-inflicted danger. Even standard library has some errors found from time to time and reaching the news. Also the compiler is new so not very much battle proven yet. Also I'm somewhat uneasy about the fact, that Rust seems to be quite a big language already, and still growing in complexity. Not sure what's the solution. But C++, as it is now, in my opinion is most certainly not one. I was employed in a big corporation and working on a moderately big C++ codebase. It totally had UB, overwriting random memory, exceptions, etc. It was common knowledge in the operations that the app crashes randomly lots of times a day and has to be restarted automatically, to the point of this being considered non-issue. Virtual inheritance was avoided; don't recall non-public. Pointers to members, suppose yes. Templates - oh, tons of them, and growing. The company actually has super smart C++ programmers (and I mean it!), submitting proposals to the C++ committee and having them accepted. Now, note the Brian Kernighan's quote about debugging clever code. I once debugged a somewhat more -often-than-normal crash. It ended up proving to be a data race. It was a fun experience, though at times totally depressing. UBs were so common during this debugging that I simply ignored them, or I'd go insane. But when I look at how easy it is to detect and debug races in Go, and how still I have to be careful to avoid races there, and still make them from time to time, I know there are tons of them sleeping undetected in any multithreaded C++ code. And we had valgrind etc (though it was rarely used, as it slowed the app to a crawl). Now, all the perfect "modern" or "subset" C++ you claim is so flawless (for whatever actual definition of "modern" you'd try to choose) is never fully enforceable, because it would be too strict or "not performant". Plain ugly non-modern C++ will spill, I don't believe you'll avoid it in any corporate environment. Maybe in an idealized open-source side project, in theory. As to rm, bash, zsh, Windows Explorer's right click, etc - I'm sure they are broken! Those are the so called "bugs" you hear about so often. I didn't once say I won't use those tools. I only wish they weren't so buggy and unreliable... On the other hand, worth to note that there's always a random cosmic ray from time to time, or a bug in processor's microcode. So even Rust or Idris may not protect you at all time, I suppose plain old asserts may be more reliable as a last line of defence. And back to your first point: again, "you have to delete ASAP" is a strawman from you here. But anyway, Windows totally has tons of security bugs, see all the NSA exploits, recent ransomware, Pwn2Own, etc. Though they seem to have gradually learned since the Win95 and XP days and stuff is slowly improving. Linux, absolutely has bugs and security holes! Linus is famously not treating security holes as serious bugs, isn't he. Filesystems are buggy as hell! SQL database engines have to go to great lengths to try guaranteeing atomicity and reliability of writes over existing filesystems. Drivers, woohoo, those are especially famous for being buggy and of low quality standards, on whatever OS you like. But I never said to not use them. But you can't stop me from wishing and hoping we have them safer and more reliable some day. And maybe hopefully helping to do that too. Stuff like OpenRISC, seL4, GenodeOS (C++! that part makes me uneasy actually, unfortunately), Nix (again C++), maybe even QubesOS, give me some glimmer of hope for a more reliable future.

by akavel 9y ago

lj3 9y ago

> Oh no, no, no! Some people may reasonably, with some extreme care and diligence, maybe try to claim they can write safe and UB-free C code. If stars align properly. Why the sarcasm?

akavel 9y ago
I'm afraid I was not being sarcastic. Sorry. This is a totally honest and dead serious opinion from a long time C & C++ user. ("stars aligning" here means "you must also have luck". As I said: see SQLite.)
- FRex 9y ago
  Then just delete your entire OS or at least your browser, don't force yourself to use C and C++ software. Seriously. I'll let you keep LLVM so you can play with Rust. There's disliking language or the boilerplate it forces on the programmer which I can REALLY understand in case of these two and there's being a jerk and an idiot and saying any C++ program that isn't few lines is broken by the UB, you need stars aligning to write safe C, they are impossible to write anything substantial, safe and useful in, etc. and anyone who tells you otherwise is implicitly a very bad programmer who does their job wrong and endangers people.
  - cyphar 9y ago
    I'm not sure I agree with the amount of hyperbole in the original post, but you must be joking if you want to claim that browsers or OSes are "safe" in the Rust sense of the word. Use after frees and numerous other memory bugs are discovered all the time in C/C++ programs (including kernels and browsers). This isn't an imaginary problem. Then combine multithreading and you've got a whole extra level of possible issues. Rust does solve many of these problems, and you can prove it does so mathematically. I understand why people don't like the use of the term "safe" because it feels like a value judgement. But I think people's egos really should be a bit less fragile when discussing language choices. > Then just delete your entire OS or at least your browser, don't force yourself to use C and C++ software. With RedoxOS you actually could do that in the near future once it supports some more hardware. The kernel and entire userland (with graphics) is written in Rust. And they did it in 2 years. If nothing else you have to admit that there are some very talented engineers using Rust.
    - FRex 9y ago
      Your point being exactly what? Don't put words in my mouth because I never claimed C and C++ are as safe as Rust, just that they are good enough for millions, including you, to rely on daily with their lives and that Rust itself relies on some C++ (LLVM). I'd even say that yes, C is the least friendly and most spartan language and C++ is the most complex and hard language that are in wide use nowdays but that wasn't the OP's claim. The OP's claim was ridiculous and on the level of opinion people have of Java applets ("totally unsafe", "useless", etc.). These people who have such opinions of them don't run them in their browsers so you should not run any C or C++ on your machine either or you are clearly overdramatizing. Mathematical provability and technical excellence has sadly little to do with adoption - see where JavaScript, Erlang, Haskell, OCalm, Modula, etc. ended up and tell me every language got what it deserved based on its own merit. Fanboying over Rust and RedoxOS (it being impressive or not is besides the point) won't fix all that "doable if stars align C" and "humanly impossible C++ that has UB even after few lines" code out there in the government, power plants (including nuclear), infrastructure, stores, embedded, banks, ... Egos have nothing to do with it. I dislike JavaScript, Java and C# personally (not for any technical reasons but due to my tastes) but if I've seen someone saying the are useless and everything written in them is broken I'd call BS. I'm similarly fond of Free Pascal with LCL for personal GUI toys but if someone said it'll take over the world and destroy Qt and GTK+ behemoths I'd also call BS. Hell, I'd defend your precious little Rust if someone said something stupid about it. There's factual critique (which I have lots of myself and I don't recommend C or C++ to new hobbyist programmers but Python3), there's personal taste (that you mustn't camouflage as technical opinions) and then there's pedal to the metal "I hate the language so it's totally useless and no human can use it" BS like the OP's comment. Rust supposedly targets C and C++ programmers so it shouldn't be acceptable to shit all over their tools and by extension their work, telling them they are stupid for liking these languages and are doing everything wrong as an engineer. The fact that such BS is disallowed in official Rust spaces is really telling of how idiotic and ridiculous it is: https://news.ycombinator.com/item?id=14755394 https://news.ycombinator.com/item?id=14755394

RcouF1uZ4gsC 9y ago

Basically exception safety is a solved problem in Modern C++. If you use RAIIike it was meant to be used, exception safety is not that big a deal.

tomjakubowski 9y ago
True, I guess, for "business logic"-y classes. Not true at all for data structures, particularly those that are templates.
- AnimalMuppet 9y ago
  How is it not true for data structures? Even templated ones?
akavel 9y ago
For serious exception safety, you have to be able to prove that all invariants all the code of your class relies on are kept between every 2 subsequent lines of your code in that class. Because exception can occur everywhere. And actually, I oversimplified, because often you must also know what happens in each and every operator you use, including implicit casting operators, and also in your destructors and constructors, including implicit ones. Each of those may or may not throw, and each of those may have some internal state, or modify your state in unexpected ways during an exception. RAII gives you primitives which you trust are written with exception safety w.r.t. their inner invariants. But you build some code on it, which has its own invariants. Do you prove them between every 2 lines of your code every time you change a line in your code? After I read enough about exception safety, I realized how hard it is to keep watertightly.

bandook_raja 9y ago

do you mind me providing a bit personal suggestion? When you've began resorting to play of words like 'barbed fences, trip-wire mines...' instead of providing concrete proof/examples in your post, you've already lost your argument. > Writing C++ code longer than a few lines without UB is humanly impossible. Do you want me to provide one for you? Because that will definitely change your definition of 'humanly impossible' tasks and might also bring you back from realms of using comically bad phrases..

akavel 9y ago
Ok, please let me ask you a question: have you read all the fragments of The ISO C++ Standard regarding undefined behavior? I have not, but I've read enough fragments/quotes to raise hair on my back and show me how many assumptions I had and assumed safe were subtly wrong. If you have not read all the fragments, you by definition don't know enough about UB to protect against it! Sorry.

blub 9y ago

I struggle to imagine how you could be more wrong. C offers minimal if any possibilities for writing safe code, while C++ offers many. Anybody who has the faintest clue about both languages should know that.

pcwalton 9y ago
I actually feel that C++ memory management is less safe than that of C, because smart pointers provide the same opportunity for use-after-free while being much more opaque about when the destruction occurs. The rules about when destructors of temporaries are called in the evaluation of expressions are subtle.
- blub 9y ago
  I'd be happy to discuss an example, because right now the idea that smart pointers are opaque about destruction is unfortunately too abstract for me to give a helpful reply to.
  - pcwalton 9y ago
    Consider situations like this: https://stackoverflow.com/questions/17362673/temporary-lifetime-extension https://stackoverflow.com/questions/17362673/temporary-lifet... It's undefined behavior, despite not calling free anywhere. Replace with std::string and it could be use after free. In C, UAF wouldn't happen that silently for heap memory.
    - blub 9y ago
      A similar example was posted by matthieu_m on Reddit a while back, but that's still not worse than C, even if it's an unfortunate gap in compiler diagnostics. From my POV compilers should warn that this code is potentially dangerous. My rule is: never return a reference or pointer from a function to something whose lifetime you don't have control of.
      - 9y ago

FRex 9y ago

To help protect you from these unsafe programs in obsolete languages I compiled a small list of software in C or C++ that you need to delete ASAP to ensure your safety: 1. Windows OS. 2. Windows kernel (mobile too). 3. Linux kernel (android too). 4. Bash, zsh, csh, fish, etc. 5. C#, Java, Ruby, Python, etc. 6. Parts of Rust backend, namely LLVM :(. 7. Apache, nginx, etc. 8. Filesystems. 9. Most drivers. 10. Router software. 11. Linux graphical environments (most/all are C or C++ and use GTK+ or Qt). 12. Any other kernels/OSes (any BSD, Haiku, iOS, etc.). Be sure to not use rm, bash, zsh, windows explorer right click + delete, etc. to delete these as that'd be relying on definitely broken software written in obsolete languages too! On a more serious note: IF you knew C++ at all you'd really know better than to say things like these and I have no idea where did you get the information about UB, overwriting random memory or using exceptions (Qt is famous for using none at all for a good reason) being common in C++. And what people use is the sane subset. When was the last time you've seen outside of some obscure specific place any of: virtual or non public inheritance, pointers to members, switching [] operator arguments for C arrays, placement new, manually calling destructors, using templates or macros to do compile time programming, etc? Considering your ignorance of the fact you use tons of rock solid C++ software daily I'd think you don't know what most or all of these even are. Rust fanboys like you who speak of C and C++ programmers like of idiots who write unsafe programs that endanger people is exactly why I'm not using Rust (yet?). If a community seems that toxic at a distance I'm not even going to try to come closer. It's even worse than Java or C# fanboys who seem to forget what their VMs are in because they are at least fanboying over HUGE enterprise proven languages. Rust on the other hand does have a few big projects (but Servo is a toy and few lines around hundreds of thousands of C++ in Firefox doesn't make it a Rust project) and looks more promising than D ever did but fanboys are acting like it's the next C++, Java, Julia and C# combined and grasping at straws "one package in choco is in Rust!", "easy to call C code!", ...

akavel 9y ago
[edit: ah, potentially my best argument regarding UB, that I thought of in another reply in this thread: so, please tell me now, have you read all the fragments of The ISO C++ Standard regarding UB? Because if not, you by definition don't know when you may be committing UB! :) And what I can tell you, is that I have not read all of them, but I have read enough of them to raise hair on my back and make me absolutely doubt all C++ code I've ever written, or would possibly ever write in future.] Please note I didn't say a word about Rust here :) That's your overinterpretation. First of all, I never actually used Rust; from what I've seen, I feel it has some potential and good ideas; but OTOH, I also get the feeling that one is forced to use 'unsafe' blocks from time to time anyway, so there's still some area for self-inflicted danger. Even standard library has some errors found from time to time and reaching the news. Also the compiler is new so not very much battle proven yet. Also I'm somewhat uneasy about the fact, that Rust seems to be quite a big language already, and still growing in complexity. Not sure what's the solution. But C++, as it is now, in my opinion is most certainly not one. I was employed in a big corporation and working on a moderately big C++ codebase. It totally had UB, overwriting random memory, exceptions, etc. It was common knowledge in the operations that the app crashes randomly lots of times a day and has to be restarted automatically, to the point of this being considered non-issue. Virtual inheritance was avoided; don't recall non-public. Pointers to members, suppose yes. Templates - oh, tons of them, and growing. The company actually has super smart C++ programmers (and I mean it!), submitting proposals to the C++ committee and having them accepted. Now, note the Brian Kernighan's quote about debugging clever code. I once debugged a somewhat more -often-than-normal crash. It ended up proving to be a data race. It was a fun experience, though at times totally depressing. UBs were so common during this debugging that I simply ignored them, or I'd go insane. But when I look at how easy it is to detect and debug races in Go, and how still I have to be careful to avoid races there, and still make them from time to time, I know there are tons of them sleeping undetected in any multithreaded C++ code. And we had valgrind etc (though it was rarely used, as it slowed the app to a crawl). Now, all the perfect "modern" or "subset" C++ you claim is so flawless (for whatever actual definition of "modern" you'd try to choose) is never fully enforceable, because it would be too strict or "not performant". Plain ugly non-modern C++ will spill, I don't believe you'll avoid it in any corporate environment. Maybe in an idealized open-source side project, in theory. As to rm, bash, zsh, Windows Explorer's right click, etc - I'm sure they are broken! Those are the so called "bugs" you hear about so often. I didn't once say I won't use those tools. I only wish they weren't so buggy and unreliable... On the other hand, worth to note that there's always a random cosmic ray from time to time, or a bug in processor's microcode. So even Rust or Idris may not protect you at all time, I suppose plain old asserts may be more reliable as a last line of defence. And back to your first point: again, "you have to delete ASAP" is a strawman from you here. But anyway, Windows totally has tons of security bugs, see all the NSA exploits, recent ransomware, Pwn2Own, etc. Though they seem to have gradually learned since the Win95 and XP days and stuff is slowly improving. Linux, absolutely has bugs and security holes! Linus is famously not treating security holes as serious bugs, isn't he. Filesystems are buggy as hell! SQL database engines have to go to great lengths to try guaranteeing atomicity and reliability of writes over existing filesystems. Drivers, woohoo, those are especially famous for being buggy and of low quality standards, on whatever OS you like. But I never said to not use them. But you can't stop me from wishing and hoping we have them safer and more reliable some day. And maybe hopefully helping to do that too. Stuff like OpenRISC, seL4, GenodeOS (C++! that part makes me uneasy actually, unfortunately), Nix (again C++), maybe even QubesOS, give me some glimmer of hope for a more reliable future.