12 ms·

Rust, Zig, and the Futility of “Replacing” C

24 points by ghoward 6y ago

burnthrow 6y ago
I'm amazed by the hostility of these comments, including personal attacks, and by this post being flagged. The author isn't some nobody who just finished a boot camp, but a very skilled C hacker. He makes a good argument for the importance of portability, a topic that seldom comes up in the C/Rust discussions I've read.
- pjmlp 6y ago
  Back when I started coding, C was only portable across the very expensive UNIX workstations and unavailable anywhere else. At most you got to use dialects like Small-C and BDS C on other platforms.
  - burnthrow 6y ago
    Yes but we're talking about today. And C's smallness/simplicity means that bootstrapping on new architectures is straightforward. Meanwhile Rust needs 64bit, etc. just to build. Rust's early embrace of compile-time complexity (ZCA) means this will always be a fundamental problem for the language. In fact it's getting worse over time.
    - pjmlp 6y ago
      I already did this dance a couple of times, so coming from C++, Java and C#, I am quite confident that Rust folks will overcome this issue.
adamnemecek 6y ago
The author also wrote a blog post about how much he hates wearing anti-covid masks https://gavinhoward.com/2021/02/boycotting-petty-tyrant-businesses/ https://gavinhoward.com/2021/02/boycotting-petty-tyrant-busi.... Somehow I’m not surprised. Also bc might not be quite the yardstick when it comes to software that needs to be secure.
- oblio 6y ago
  Oh, and I see he posted the link himself. Gavin, the behavior you describe in your mask blog post is that of a inconsiderate jerk. What good is a mask in your pocket?!?
  - marzullo 6y ago
    It's still mind boggling to me that enforcing public safety procedures can be interpreted as any sort of tyranny. He purposefully goes out of his way to not wear a mask, but still takes the time to keep one in his pocket to just see how far he can go breaking the rules.
    - Gibbon1 6y ago
      I have trouble taking seriously claims that public health orders are tyranny when I can remember when the US had conscription.
    - ghoward 6y ago
      Gavin here. Mask mandates from governors are not, in fact, rules. Executive orders are not laws. See https://gavinhoward.com/2020/10/executive-agencies-cannot-make-laws/ https://gavinhoward.com/2020/10/executive-agencies-cannot-ma... . If a business decides to enforce their rule, well, then we both know that it would be best that I do as little business with them as possible.
  - deleted 6y ago
    [deleted]
  - ghoward 6y ago
    Gavin here. See https://news.ycombinator.com/item?id=26293979 https://news.ycombinator.com/item?id=26293979 .
    - oblio 6y ago
      You're like that person in the Adult Swim sketch about Google being a guy, where the person asking "Google" about something gets a million results showing A) and just 1 result showing B), and they decide to take B). First of all, if you're really arguing that masks affect mental health more than they save lives (https://gavinhoward.com/2020/08/in-science-all-factors-matter/ https://gavinhoward.com/2020/08/in-science-all-factors-matte...), I don't even know what to say. I'd really want to see the science behind this, but I suspect there isn't any real science. Common sense and knowledge of professions where people use a mask for long periods of time should be enough to debunk this. Also, this is truly abhorrent: > Of course, 161,392 people have died. (Oh whoops! It turns out that only 6% of those people died from COVID-19 alone, so it’s really 9,700 deaths) If my car breaks don't work, I ostensibly die because I'll be crushed when my car falls of a cliff, but the real cause of my death is the fact that the car breaks didn't work. For the other article, gee, I wonder if the folks behind it have an agenda to push: "Townhall: <<Conservative>> News, Cartoons, Top Stories". Anyway, do realize that this is a global phenomenon, people aren't out to get your "freedoms" and countries which are far freer than the US have realized that Covid is a real pandemic and treat it using real science, not pseudo-sience peddled by crackpots or even worse, people with a hidden agenda (usually one about making $$$). I know I won't change your mind, but please break out of your bubble. Find international sources, use Google Translate to see what they say, compare, contrast, think critically. Also, read up on your history and check out what they did to fight the 1919 flu, for example. Or SARS. Or what they're doing all over East Asia, mostly successfully. Oh, by the way, your argument makes you look even worse than you think it does. It's all about ME ME ME! "There's a tiny chance that masks hurt me" and "there's a tiny chance that masks don't help others as much as people say", so basically, "f** everyone else in that case, I don't want to be inconvenienced".
tptacek 6y ago
This is just a longer version of every angry comment on the Github Issue thread it's referring to, differing only in that this person doesn't seem to be a maintainer of any project intersecting with `cryptography`. If you're interested in this debate, such as it is, just read the Github thread.
- deleted 6y ago
  [deleted]
hlieberman 6y ago
Asinine victim-blaming. "If you were good at C, it wouldn't have memory safety problems." OpenSSH, a program written by one of the most security conscious groups of developers out there (OpenBSD), used widely by pretty much every technology company out there including all of the top 8 companies in the world, has had multiple memory safety problems over its lifetime, /none/ of which would have happened in Rust, Zig, or any of their ilk. Yes, portability in LLVM-based languages is a problem for sure. Even an LLVM/GCC monoculture isn't particularly great. But saying "nah, you're just doing it wrong"? No.
- adamnemecek 6y ago
  The funniest part is that he compares it to bc.
  - ghoward 6y ago
    Author here. Cryptography is not far off of bc. It is deterministic and should be easily testable. My bc is battle-hardened because I did my due diligence. The authors of the Cryptography library are writing _crypto_, which requires such due diligence. Did they? What I should add to the post is that if they were not planning on doing that due diligence from the start, they should have written it in Rust from the beginning and not made promises to users that they couldn't keep.
    - adamnemecek 6y ago
      Most programs have those properties. Cryptography is very far off from bc because no one is actually trying to exploit bc. It’s open source software. There are no promises.
      - ghoward 6y ago
        In the post, I try to make the case that there were, in fact, promises. Obviously, I didn't make that case well. However, if I was very careful with bc, despite the fact that no one was going to exploit it (which would not be the case if there was a vector for it, such as someone using bc in a script that runs as root), how much more careful should the Cryptography authors have been, since they were writing crypto? And if they were not going to be careful, they should have used Rust from the beginning and not made (implicit) promises to users. Edit: typo.
kbd 6y ago
> Right now, as far as I know, there is no official language spec for Zig, like there is for Go. This means that this new compiler may not match what the official compiler does. They’re actively working on a spec for Zig btw. Here’s Andrew talking about it, first thing as part of the roadmap video: https://youtu.be/pacsngNYXI0 https://youtu.be/pacsngNYXI0
- ghoward 6y ago
  Author here. Thank you for this. I will update the post with this information.
rdpintqogeogsaa 6y ago
I understand why people are angry and that portability is a worthwhile goal in many scenarios. I also understand that Rust is far from the ubiquity that C has achieved. I also understand that people feel betrayed by a library they depended on drastically altering its dependency structure. On the other hand, there's a group of developers with limited resources and perceived moral high ground in terms of security that fits right in with the trends that I've observed in the cryptography community. Both sides have valid arguments. Which sides of this split you fall on depends on your personal values and immediate needs. Ultimately, the whole debate is fruitless bickering because you cannot reconcile differences in values. This doesn't just apply to the Python "cryptography" library, but also other places where a switch to Rust was enforced by upstream. The alternative is to define "closer" portability (iOS, Android, Windows, macOS, desktop/server Linux) and "wider" portability (BSDs, illumos, QNX, custom embedded OSes, architectures that aren't x86_64 and ARM). Then make it clear from the get-go which one of these you're aiming for.
- CyberRabbi 6y ago
  There is a happy middle ground[1]. Someone could build a Rust->C compiler and then packages meant for releases could be bundled with pre-compiled C sources. [1] of course the question of who is responsible for building such a compiler potentially becomes a new value-based conflict.
  - brabel 6y ago
    The author correctly, IMO, points out that this is not possible currently because there's no Rust Specification, so the exact behaviour of such a compiler cannot even be described. I was surprised by how informal the Rust language semantics are when I was trying to find out how the `?` operator works, exactly. There's no official description anywhere except for an RFC which was created before the feature was introduced, but from which the feature has diverged significantly since it was added to the language! The Rust Book, normally assumed to be the "true" description of the language, is quite incomplete in places as it's not a formal specification. For example, the section about `?` does not mention that different error types will be auto-converted if there's a `From` implementation between them. This is quite important information missing from the documentation. Just from reading that page, you would be writing really verbose type conversions yourself, everywhere. But the Rust Book does mention this elsewhere[2] (if you're careful enough reading the first link, you can see that it says `?` is "more or less" equivalent to `try!`, and reading the docs for `try!` you could actually find out what it does, and hope they didn't change anything when implementing `?` - but that's a quite a lot of assumptions). You just need to read the whole book, or at least be lucky enough to look at all the right places, to make sure you understand how a language feature works, precisely. [1] https://doc.rust-lang.org/edition-guide/rust-2018/error-handling-and-panics/the-question-mark-operator-for-easier-error-handling.html https://doc.rust-lang.org/edition-guide/rust-2018/error-hand... [2] https://doc.rust-lang.org/book/ch09-02-recoverable-errors-with-result.html#a-shortcut-for-propagating-errors-the--operator https://doc.rust-lang.org/book/ch09-02-recoverable-errors-wi...
kstenerud 6y ago
> First, their argument for Rust (and against C) because of memory safety implies that they have not done due diligence in finding and fixing such bugs. No, it implies that finding such bugs is exponentially harder in C than it is in other languages. Eventually you reach so far up the diminishing returns curve that you simply are able to accomplish more in one language with your time on Earth than you can in another. This is a numbers game, and C loses out to safer competitors when it comes to bugs. The due diligence that these developers are doing is a meta-analysis that has gone over your head. > And with my bc, I did my due diligence with memory safety. I fuzzed my bc and eliminated all of the bugs. That's a pretty absolute claim. And one I doubt. I'll save my trust for people humble enough to understand the limitations of technologies and themselves.
- jvanderbot 6y ago
  > all of the bugs Probably meant all of the reported bugs, given the context.
  - kstenerud 6y ago
    Which makes it all the worse, because he's using that as "proof" that he has done more due diligence than these other devs, and suggesting that they could achieve just-as-good-or-better results by emulating him (which is provably false given the nature of C vs rust when it comes to bugs). For a calculator it may be no huge deal to have such a cavalier attitude. But for cryptography, bugs are considerably more important as the threat model isn't even in the same league.
    - ghoward 6y ago
      Author here. The fact that I _could have had_ a cavalier attitude towards C memory safety, but didn't, shows (I believe) just how much the Cryptography authors fell short because _they were writing crypto_. If anything, they should have surpassed the amount of due diligence that I did on bc, but they didn't.
      - 6y ago
CyberRabbi 6y ago
The authors of Rust and Zig fail to understand why C is ubiquitous: “worse is better.” You can’t replace C with a better C because that is counter to why C is ubiquitous in the first place. To be fair most engineers (including many brilliant ones) fail at grasping the intuition of providing simple but not 100% adequate solutions. The difficulty of the last 20% will drive most potential users/implementers away, and reduces the virality.
- asplake 6y ago
  What makes you so sure that they don’t understand? And how are we ever to make progress if everyone’s problems have to addressed from the beginning?
  - CyberRabbi 6y ago
    I think you’re missing my point. There is a non-linear relationship between the ubiquitousness of a language and its quality. That is to say, more quality does not always result in more ubiquitousness. That does not mean progress is not possible, just that it’s not necessarily viral. If the zig and rust creators understand that then they should stop measuring their success as a percentage of the size of their user base to the size of C’s user base because their goals are arguably counter to having a user base as large as C’s.
    - bogeholm 6y ago
      > If the zig and rust creators understand that then they should stop measuring their success as a percentage of the size of their user base to the size of C’s user base ... Please provide a source for these alleged success criteria.
- Thiez 6y ago
  It seems like "worse is better" only applies selectively when C has the advantage. For instance, Rust has no formal spec, but surely that is fine according to the "worse is better" philosophy, because the current situation serves most, but not 100% of users. Rust doesn't support ancient architectures that aren't being manufactured anymore, but Rust supports most common architectures. Surely that is fine according to the "worse is better" philosophy? It seems many who favor C over Rust don't actually believe in "worse is better". A language must be equal or better than C in all possible aspects before it can be greeted with reluctant distrust instead of hostility. "Worse is better" can be used to defend C, but never a new language.
Ceezy 6y ago
Portability would for sure be a great asset for Rust. But it's a new language compared to C. I also agree that having a clear spec is a must. But the author got lost, none of these languages have a clear sweet spot yet that would help them to define a clear spec.
smitty1e 6y ago
My understanding is that Rust's chief innovation is the borrow checker. If this famous device is that outstanding, one wonders at what point some version of that funtionality arrives for C or C++.
- vlovich123 6y ago
  Likely not because a feature like that kind of has to be implemented as part of the core language. Maybe someone could retrofit a “safe” version of c/c++, but there’s nothing on the horizon that indicates that would be possible (they are hampered by back compat issues).
  - smitty1e 6y ago
    I mean, MyPy does have some core PEP support, but remains optional for Python. If something as core as type checking can be an optional feature, I'd be surprised if a heftier brain than mine can't get most of the way to a C++ borrow checker optionally. Doesn't C++ famously fetish complexity? Wasn't pi once calculated at compile-timel with a C++ template? Where is my Obfuscated C entry that looks like an ASCII Robotron game and borrow-checks, say, the Linux kernel?
  - pjmlp 6y ago
    That is partially the reason why all big OS and CPU vendors are investing into hardware memory tagging.
  - metreo 6y ago
    project verona is _one_ attempt at doing this, ebpf is another
- pjmlp 6y ago
  Bring the borrow checker to the masses, Cyclone, ATS, Carp did it first. Microsoft and Google have already been collaborating in lifetime analysis on Clang Tidy and VC++ static analyser, it just isn't 100% there. CppCon 2019: Gábor Horváth, Matthias Gehre “Lifetime analysis for everyone”" https://www.youtube.com/watch?v=d67kfSnhbpA https://www.youtube.com/watch?v=d67kfSnhbpA Lifetime Profile Update in Visual Studio 2019 Preview 2 https://devblogs.microsoft.com/cppblog/lifetime-profile-update-in-visual-studio-2019-preview-2/ https://devblogs.microsoft.com/cppblog/lifetime-profile-upda... GCC 11 will also support a lightweight version of it for C, https://developers.redhat.com/blog/2021/01/28/static-analysis-updates-in-gcc-11/ https://developers.redhat.com/blog/2021/01/28/static-analysi...
pjmlp 6y ago
As I mentioned on the reddit thread, Apple believes so much in C's safety, that they have a custom safe C dialect for iBoot. https://support.apple.com/guide/security/memory-safe-iboot-implementation-sec30d8d9ec1/web https://support.apple.com/guide/security/memory-safe-iboot-i... We won't get rid of C that easily, given the amount of systems that depend on it and won't be rewritten, which is exactly why besides Apple, also Google, Oracle, ARM, Microsoft are leading efforts to turn modern computers into C machines, with hardware memory tagging to fix at hardware level what WG14 won't fix.
- ghoward 6y ago
  Author here. Can you give me a link to the Reddit thread?
  - pjmlp 6y ago
    Sure, https://old.reddit.com/r/rust/comments/luawx6/rust_zig_and_the_futility_of_replacing_c/ https://old.reddit.com/r/rust/comments/luawx6/rust_zig_and_t...
ghoward 6y ago
Author here. I had added several links to the post regarding replies to what I said about Zig. I have also clarified a few arguments. And because there seems to be some disbelief at my claim of absolutely not bugs in my bc, I am going to throw down the gauntlet like I did in https://news.ycombinator.com/item?id=26293920 https://news.ycombinator.com/item?id=26293920. I encourage everyone who thinks I am wrong to _prove_ me wrong. Find a memory safety bug in my bc. Should be easy since C is so unsafe, right?

24 points by ghoward 6y ago

I'm amazed by the hostility of these comments, including personal attacks, and by this post being flagged. The author isn't some nobody who just finished a boot camp, but a very skilled C hacker. He makes a good argument for the importance of portability, a topic that seldom comes up in the C/Rust discussions I've read.

pjmlp 6y ago
Back when I started coding, C was only portable across the very expensive UNIX workstations and unavailable anywhere else. At most you got to use dialects like Small-C and BDS C on other platforms.
- burnthrow 6y ago
  Yes but we're talking about today. And C's smallness/simplicity means that bootstrapping on new architectures is straightforward. Meanwhile Rust needs 64bit, etc. just to build. Rust's early embrace of compile-time complexity (ZCA) means this will always be a fundamental problem for the language. In fact it's getting worse over time.
  - pjmlp 6y ago
    I already did this dance a couple of times, so coming from C++, Java and C#, I am quite confident that Rust folks will overcome this issue.

adamnemecek 6y ago

The author also wrote a blog post about how much he hates wearing anti-covid masks https://gavinhoward.com/2021/02/boycotting-petty-tyrant-businesses/ https://gavinhoward.com/2021/02/boycotting-petty-tyrant-busi.... Somehow I’m not surprised. Also bc might not be quite the yardstick when it comes to software that needs to be secure.

oblio 6y ago
Oh, and I see he posted the link himself. Gavin, the behavior you describe in your mask blog post is that of a inconsiderate jerk. What good is a mask in your pocket?!?
- marzullo 6y ago
  It's still mind boggling to me that enforcing public safety procedures can be interpreted as any sort of tyranny. He purposefully goes out of his way to not wear a mask, but still takes the time to keep one in his pocket to just see how far he can go breaking the rules.
  - Gibbon1 6y ago
    I have trouble taking seriously claims that public health orders are tyranny when I can remember when the US had conscription.
  - ghoward 6y ago
    Gavin here. Mask mandates from governors are not, in fact, rules. Executive orders are not laws. See https://gavinhoward.com/2020/10/executive-agencies-cannot-make-laws/ https://gavinhoward.com/2020/10/executive-agencies-cannot-ma... . If a business decides to enforce their rule, well, then we both know that it would be best that I do as little business with them as possible.
- deleted 6y ago
  [deleted]
- ghoward 6y ago
  Gavin here. See https://news.ycombinator.com/item?id=26293979 https://news.ycombinator.com/item?id=26293979 .
  - oblio 6y ago
    You're like that person in the Adult Swim sketch about Google being a guy, where the person asking "Google" about something gets a million results showing A) and just 1 result showing B), and they decide to take B). First of all, if you're really arguing that masks affect mental health more than they save lives (https://gavinhoward.com/2020/08/in-science-all-factors-matter/ https://gavinhoward.com/2020/08/in-science-all-factors-matte...), I don't even know what to say. I'd really want to see the science behind this, but I suspect there isn't any real science. Common sense and knowledge of professions where people use a mask for long periods of time should be enough to debunk this. Also, this is truly abhorrent: > Of course, 161,392 people have died. (Oh whoops! It turns out that only 6% of those people died from COVID-19 alone, so it’s really 9,700 deaths) If my car breaks don't work, I ostensibly die because I'll be crushed when my car falls of a cliff, but the real cause of my death is the fact that the car breaks didn't work. For the other article, gee, I wonder if the folks behind it have an agenda to push: "Townhall: <<Conservative>> News, Cartoons, Top Stories". Anyway, do realize that this is a global phenomenon, people aren't out to get your "freedoms" and countries which are far freer than the US have realized that Covid is a real pandemic and treat it using real science, not pseudo-sience peddled by crackpots or even worse, people with a hidden agenda (usually one about making $$$). I know I won't change your mind, but please break out of your bubble. Find international sources, use Google Translate to see what they say, compare, contrast, think critically. Also, read up on your history and check out what they did to fight the 1919 flu, for example. Or SARS. Or what they're doing all over East Asia, mostly successfully. Oh, by the way, your argument makes you look even worse than you think it does. It's all about ME ME ME! "There's a tiny chance that masks hurt me" and "there's a tiny chance that masks don't help others as much as people say", so basically, "f** everyone else in that case, I don't want to be inconvenienced".

tptacek 6y ago

This is just a longer version of every angry comment on the Github Issue thread it's referring to, differing only in that this person doesn't seem to be a maintainer of any project intersecting with `cryptography`. If you're interested in this debate, such as it is, just read the Github thread.

deleted 6y ago
[deleted]

hlieberman 6y ago

Asinine victim-blaming. "If you were good at C, it wouldn't have memory safety problems." OpenSSH, a program written by one of the most security conscious groups of developers out there (OpenBSD), used widely by pretty much every technology company out there including all of the top 8 companies in the world, has had multiple memory safety problems over its lifetime, /none/ of which would have happened in Rust, Zig, or any of their ilk. Yes, portability in LLVM-based languages is a problem for sure. Even an LLVM/GCC monoculture isn't particularly great. But saying "nah, you're just doing it wrong"? No.

adamnemecek 6y ago
The funniest part is that he compares it to bc.
- ghoward 6y ago
  Author here. Cryptography is not far off of bc. It is deterministic and should be easily testable. My bc is battle-hardened because I did my due diligence. The authors of the Cryptography library are writing _crypto_, which requires such due diligence. Did they? What I should add to the post is that if they were not planning on doing that due diligence from the start, they should have written it in Rust from the beginning and not made promises to users that they couldn't keep.
  - adamnemecek 6y ago
    Most programs have those properties. Cryptography is very far off from bc because no one is actually trying to exploit bc. It’s open source software. There are no promises.
    - ghoward 6y ago
      In the post, I try to make the case that there were, in fact, promises. Obviously, I didn't make that case well. However, if I was very careful with bc, despite the fact that no one was going to exploit it (which would not be the case if there was a vector for it, such as someone using bc in a script that runs as root), how much more careful should the Cryptography authors have been, since they were writing crypto? And if they were not going to be careful, they should have used Rust from the beginning and not made (implicit) promises to users. Edit: typo.

kbd 6y ago

> Right now, as far as I know, there is no official language spec for Zig, like there is for Go. This means that this new compiler may not match what the official compiler does. They’re actively working on a spec for Zig btw. Here’s Andrew talking about it, first thing as part of the roadmap video: https://youtu.be/pacsngNYXI0 https://youtu.be/pacsngNYXI0

ghoward 6y ago
Author here. Thank you for this. I will update the post with this information.

rdpintqogeogsaa 6y ago

I understand why people are angry and that portability is a worthwhile goal in many scenarios. I also understand that Rust is far from the ubiquity that C has achieved. I also understand that people feel betrayed by a library they depended on drastically altering its dependency structure. On the other hand, there's a group of developers with limited resources and perceived moral high ground in terms of security that fits right in with the trends that I've observed in the cryptography community. Both sides have valid arguments. Which sides of this split you fall on depends on your personal values and immediate needs. Ultimately, the whole debate is fruitless bickering because you cannot reconcile differences in values. This doesn't just apply to the Python "cryptography" library, but also other places where a switch to Rust was enforced by upstream. The alternative is to define "closer" portability (iOS, Android, Windows, macOS, desktop/server Linux) and "wider" portability (BSDs, illumos, QNX, custom embedded OSes, architectures that aren't x86_64 and ARM). Then make it clear from the get-go which one of these you're aiming for.

CyberRabbi 6y ago
There is a happy middle ground[1]. Someone could build a Rust->C compiler and then packages meant for releases could be bundled with pre-compiled C sources. [1] of course the question of who is responsible for building such a compiler potentially becomes a new value-based conflict.
- brabel 6y ago
  The author correctly, IMO, points out that this is not possible currently because there's no Rust Specification, so the exact behaviour of such a compiler cannot even be described. I was surprised by how informal the Rust language semantics are when I was trying to find out how the `?` operator works, exactly. There's no official description anywhere except for an RFC which was created before the feature was introduced, but from which the feature has diverged significantly since it was added to the language! The Rust Book, normally assumed to be the "true" description of the language, is quite incomplete in places as it's not a formal specification. For example, the section about `?` does not mention that different error types will be auto-converted if there's a `From` implementation between them. This is quite important information missing from the documentation. Just from reading that page, you would be writing really verbose type conversions yourself, everywhere. But the Rust Book does mention this elsewhere[2] (if you're careful enough reading the first link, you can see that it says `?` is "more or less" equivalent to `try!`, and reading the docs for `try!` you could actually find out what it does, and hope they didn't change anything when implementing `?` - but that's a quite a lot of assumptions). You just need to read the whole book, or at least be lucky enough to look at all the right places, to make sure you understand how a language feature works, precisely. [1] https://doc.rust-lang.org/edition-guide/rust-2018/error-handling-and-panics/the-question-mark-operator-for-easier-error-handling.html https://doc.rust-lang.org/edition-guide/rust-2018/error-hand... [2] https://doc.rust-lang.org/book/ch09-02-recoverable-errors-with-result.html#a-shortcut-for-propagating-errors-the--operator https://doc.rust-lang.org/book/ch09-02-recoverable-errors-wi...

kstenerud 6y ago

> First, their argument for Rust (and against C) because of memory safety implies that they have not done due diligence in finding and fixing such bugs. No, it implies that finding such bugs is exponentially harder in C than it is in other languages. Eventually you reach so far up the diminishing returns curve that you simply are able to accomplish more in one language with your time on Earth than you can in another. This is a numbers game, and C loses out to safer competitors when it comes to bugs. The due diligence that these developers are doing is a meta-analysis that has gone over your head. > And with my bc, I did my due diligence with memory safety. I fuzzed my bc and eliminated all of the bugs. That's a pretty absolute claim. And one I doubt. I'll save my trust for people humble enough to understand the limitations of technologies and themselves.

jvanderbot 6y ago
> all of the bugs Probably meant all of the reported bugs, given the context.
- kstenerud 6y ago
  Which makes it all the worse, because he's using that as "proof" that he has done more due diligence than these other devs, and suggesting that they could achieve just-as-good-or-better results by emulating him (which is provably false given the nature of C vs rust when it comes to bugs). For a calculator it may be no huge deal to have such a cavalier attitude. But for cryptography, bugs are considerably more important as the threat model isn't even in the same league.
  - ghoward 6y ago
    Author here. The fact that I _could have had_ a cavalier attitude towards C memory safety, but didn't, shows (I believe) just how much the Cryptography authors fell short because _they were writing crypto_. If anything, they should have surpassed the amount of due diligence that I did on bc, but they didn't.
    - 6y ago

CyberRabbi 6y ago

The authors of Rust and Zig fail to understand why C is ubiquitous: “worse is better.” You can’t replace C with a better C because that is counter to why C is ubiquitous in the first place. To be fair most engineers (including many brilliant ones) fail at grasping the intuition of providing simple but not 100% adequate solutions. The difficulty of the last 20% will drive most potential users/implementers away, and reduces the virality.

asplake 6y ago
What makes you so sure that they don’t understand? And how are we ever to make progress if everyone’s problems have to addressed from the beginning?
- CyberRabbi 6y ago
  I think you’re missing my point. There is a non-linear relationship between the ubiquitousness of a language and its quality. That is to say, more quality does not always result in more ubiquitousness. That does not mean progress is not possible, just that it’s not necessarily viral. If the zig and rust creators understand that then they should stop measuring their success as a percentage of the size of their user base to the size of C’s user base because their goals are arguably counter to having a user base as large as C’s.
  - bogeholm 6y ago
    > If the zig and rust creators understand that then they should stop measuring their success as a percentage of the size of their user base to the size of C’s user base ... Please provide a source for these alleged success criteria.
Thiez 6y ago
It seems like "worse is better" only applies selectively when C has the advantage. For instance, Rust has no formal spec, but surely that is fine according to the "worse is better" philosophy, because the current situation serves most, but not 100% of users. Rust doesn't support ancient architectures that aren't being manufactured anymore, but Rust supports most common architectures. Surely that is fine according to the "worse is better" philosophy? It seems many who favor C over Rust don't actually believe in "worse is better". A language must be equal or better than C in all possible aspects before it can be greeted with reluctant distrust instead of hostility. "Worse is better" can be used to defend C, but never a new language.

Ceezy 6y ago

Portability would for sure be a great asset for Rust. But it's a new language compared to C. I also agree that having a clear spec is a must. But the author got lost, none of these languages have a clear sweet spot yet that would help them to define a clear spec.

smitty1e 6y ago

My understanding is that Rust's chief innovation is the borrow checker. If this famous device is that outstanding, one wonders at what point some version of that funtionality arrives for C or C++.

vlovich123 6y ago
Likely not because a feature like that kind of has to be implemented as part of the core language. Maybe someone could retrofit a “safe” version of c/c++, but there’s nothing on the horizon that indicates that would be possible (they are hampered by back compat issues).
- smitty1e 6y ago
  I mean, MyPy does have some core PEP support, but remains optional for Python. If something as core as type checking can be an optional feature, I'd be surprised if a heftier brain than mine can't get most of the way to a C++ borrow checker optionally. Doesn't C++ famously fetish complexity? Wasn't pi once calculated at compile-timel with a C++ template? Where is my Obfuscated C entry that looks like an ASCII Robotron game and borrow-checks, say, the Linux kernel?
- pjmlp 6y ago
  That is partially the reason why all big OS and CPU vendors are investing into hardware memory tagging.
- metreo 6y ago
  project verona is _one_ attempt at doing this, ebpf is another
pjmlp 6y ago
Bring the borrow checker to the masses, Cyclone, ATS, Carp did it first. Microsoft and Google have already been collaborating in lifetime analysis on Clang Tidy and VC++ static analyser, it just isn't 100% there. CppCon 2019: Gábor Horváth, Matthias Gehre “Lifetime analysis for everyone”" https://www.youtube.com/watch?v=d67kfSnhbpA https://www.youtube.com/watch?v=d67kfSnhbpA Lifetime Profile Update in Visual Studio 2019 Preview 2 https://devblogs.microsoft.com/cppblog/lifetime-profile-update-in-visual-studio-2019-preview-2/ https://devblogs.microsoft.com/cppblog/lifetime-profile-upda... GCC 11 will also support a lightweight version of it for C, https://developers.redhat.com/blog/2021/01/28/static-analysis-updates-in-gcc-11/ https://developers.redhat.com/blog/2021/01/28/static-analysi...

pjmlp 6y ago

As I mentioned on the reddit thread, Apple believes so much in C's safety, that they have a custom safe C dialect for iBoot. https://support.apple.com/guide/security/memory-safe-iboot-implementation-sec30d8d9ec1/web https://support.apple.com/guide/security/memory-safe-iboot-i... We won't get rid of C that easily, given the amount of systems that depend on it and won't be rewritten, which is exactly why besides Apple, also Google, Oracle, ARM, Microsoft are leading efforts to turn modern computers into C machines, with hardware memory tagging to fix at hardware level what WG14 won't fix.

ghoward 6y ago
Author here. Can you give me a link to the Reddit thread?
- pjmlp 6y ago
  Sure, https://old.reddit.com/r/rust/comments/luawx6/rust_zig_and_the_futility_of_replacing_c/ https://old.reddit.com/r/rust/comments/luawx6/rust_zig_and_t...

ghoward 6y ago

Author here. I had added several links to the post regarding replies to what I said about Zig. I have also clarified a few arguments. And because there seems to be some disbelief at my claim of absolutely not bugs in my bc, I am going to throw down the gauntlet like I did in https://news.ycombinator.com/item?id=26293920 https://news.ycombinator.com/item?id=26293920. I encourage everyone who thinks I am wrong to _prove_ me wrong. Find a memory safety bug in my bc. Should be easy since C is so unsafe, right?