Rust, Zig, and the Futility of “Replacing” C | Hacker News Reader

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

gavinhoward.com

24 pointsgavinhoward122 comments

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.

The funniest part is that he compares it to bc.

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.

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.

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.

> how much more careful should the Cryptography authors have been, since they were writing crypto?

Did you consider that they are being careful by rewriting it in Rust?

> And if they were not going to be careful, they should have used Rust from the beginning and not made (implicit) promises to users.

Maybe Rust wasn't quite there at that point.

> Did you consider that they are being careful by rewriting it in Rust?

So they are only starting to be careful after several years? I addressed that point in the post.

> Maybe Rust wasn't quite there at that point.

It wasn't. But that's the point. Rust wasn't there, it's not there now. It needs to be as portable as C to be "there".

> So they are only starting to be careful after several years? I addressed that point in the post.

No since you’ll get to the “battle tested” point much fastener.

> No since you’ll get to the “battle tested” point much fastener.

I'm not sure what you mean here.

Are you saying that a bc will get to a battle-tested state faster than crypto?

If you are, I disagree whole-heartedly. Crypto is bigint math with a few extras. bc has bigint math, a lexer, a parser, and an interpreter. Of those, the parser and interpreter are far more complicated than the bigint math.

And bc's bigint math is not actually just bigint; it's bigdecimal.

As a Gentoo user and an enthusiastic non-x86 user, when I was just reading the opening, I expected to hear an argument about the necessity of supporting uncommon architectures as a standard library. Gentoo supports a broad range of systems, every time an underlying library switches to a less supported environment creates a headache for Gentoo developers and users, "vintage architecture needs some love" would be an interesting article (not saying it's practical, but interesting). Unfortunately, the author's main argument is a denial of C's memory safety problems. I was disappointed.

Author here.

If you read deeper into the post, I do, in fact, talk about how supporting those less well-known architectures is important.

Edit: Also, those arguments were made plenty by others, so I didn't feel a need to rehash them much.

(note: the original comment has been rewritten)

> If you read deeper into the post

I did skim the entire post, but the discussion on supporting alternative computer architectures was significantly shorter than the issue of memory safety, or Rust or Zig as languages.

> Also, those arguments were made plenty by others, so I didn't feel a need to rehash them much.

Fair enough.

BTW, I agree with you that generating portable C is actually an interesting solution. Recently, there are a few successful projects like HACL* (Microsoft) [0], Fiat-Crypto (MIT CSAIL) [1] that are based on this idea - they use a high-level framework to synthesize human-unreadable but formally verified C code, effectively using C as a form of portable assembly. Both have been deployed in real-world systems like OpenSSH, Chromium and the Linux kernel with great success.

[0] https://github.com/project-everest/hacl-star

[1] https://github.com/mit-plv/fiat-crypto

Thank you for your kind words and the links!

>Asinine victim-blaming

The fact the post is flagged now somehow makes me feel that Rust community can't stand anything else then praise and worship.

It retreads the same old, tired argument that Rust developers have been disproving it for so long, i.e. "Just write good C code" or in this case "Just battle test it"

So this means it should be flagged?

Not at all, thing is, are you sure it was a Rust fanboy?

You think it was an Apple or Arch fanboy?

No, I think it was a random dude on Internet without any way to prove who did it.

Sure it is possible, someone that is not attached to Rust just decided to hide some criticism, but IMO this chance is almost Zero. At least we agree that flagging should be used only for out of scope articles or truly terrible ones like "I wrote an incomplete, undocumented,unsupported, unremarkable, buggy piece of code in Rust"

Perhaps the flagger simply put this post in the "truly terrible" category- it retreads old and tired arguments without ever introducing any new depth or nuance.

Yes, the possibility is not zero, it would be great if flagging would always ask for a reason (similar with reporting on reddit ,where you have to specify the rule that is broken and everyone could see what was flagged and why)

Though don't you think that your criteria would affect all the "X subpar re-implemented in Rust" submissions there are same thing all the time only X changes.

Sure? I didn't say anything about other submissions. I honestly don't know which ones you have in mind anyway, so anything I could say would just be a guess. :)

Nope, that is the typical conspiracy theory of hanging people on trees without proofs.

Author here.

My argument is actually that Rust cannot replace C because it's not portable enough.

I would love for Rust to be portable enough.

Gavin, I don’t know you but let me just take this opportunity to say that I think you’re an incredible person and a smart talented hacker. The idea that software maintainers do indeed have some responsibility to their users rings true and consistent with reality.

Thank you. I'm glad to know there are others that feel the same way. :)

My pleasure. Don’t let these Rust justice warriors discourage you.

I'm not a Rust user.

I flagged it because it's poorly written flamebait that doesn't add anything to the comments on the GitHub thread.

Author here.

What they did wrong was making promises to users and then breaking those promises.

I also tried to make the case that they either did not do their due diligence, which they should have done because they used C in the first place, or they did and should not have given up that battle-tested code.

I even mentioned that they were victims of the Rust language not keeping its promises. So I disagree that I am blaming the victim here.

Also, if they did not want to do the due diligence required by using C, they should have written Cryptography in Rust from the beginning and not made promises to users that they couldn't keep.

Rust was not a viable option when pyca/cryptography was first released. You should be more familiar with projects before you invent strange promises you feel they've made to you.

I made the argument knowing that, actually. And in my opinion, the promises are almost always implicit.

No, after re-reading your piece, I don't think you did.

Then I guess I made the argument poorly and still need practice writing for an audience.

A good start would have been acknowledging that flaw in your premise, anywhere in the piece.

It's an unsalvageable argument regardless; you have invented a promise nobody made to you, compelling strangers to manage a project in which you have no involvement to conduct their work in accordance with your wishes.

I don't know why I can't reply to your reply, so I'll post it here.

My argument is that Rust _still_ isn't ready for the Cryptography library because it's not portable enough.

And I am not a direct user of the Cryptography library. I am an indirect user on x86_64, so I am unaffected. They have kept their implicit promise to me.

The only people that can be pissed off by promises are paying customers.

So those paying to Cryptography developers, are the ones to be pissed off, IF their platforms aren't being considered.

Does that include the customers of https://fishinabarrel.github.io/, the company owned by one of the Cryptography developers?

Yes, assuming they are paying for it and are not able to use it on the use cases they are paying for.

Then again, they clearly mention on that page:

" Please put us out of business.

Stop writing C/C++.

Probably you should also sandbox your software. "

Then there is qmail. Totally written in C. No bugs, no security flaws.

But the author is way brighter than I am. I spent my youth programming real-time interrupt rich medical diagnostic software in low-level assembly language, which is harder to get right than C. We had very few bugs. I would be reluctant to do this in C, probably less so in Rust (which I have yet to master)

I appreciate what the Rust community is trying to accomplish, and suspect it will happen.

However, there is an sense of overselling this idea of memory safety. Keep in mind that SolarWinds and Equifax are not memory safety issues. Also, someone wrote a Rust version of heartbleed, so it would be good to keep a perspective.

And it isn't like I haven't been in the position to be rabid promoter of programming demagoguery. First was the unnecessarily limited gammar of Fortran II. I discovered XP/L and promoted that beyond reason. Then there was the GOTO demagogery which I was one of the loudest. And along with that Structured Programming, then Object Oriented Programming.

So as you promote Rust, don't sell the idea that it will prevent every security nightmare out there--it will massively help with some very important ones. Additional work beyond programming language is necessary to improve security.

When companies like Microsoft and Google publish security reports they state 70% of security exploits were caused by memory corruption bugs, they don't say 100%.

Naturally memory safe systems programming languages still suffer from the remaining 30% root causes for security exploits.

It isn't perfect, but much better, and we aren't still there because bean counters haven't been paying attention how much money it costs to fix those bugs, and the lack of liability.

Agreed.

But there are exploits and there are breaches. Exploits are bad and Rust will help, but in the rest of industry and government and military, exploits are not the whole story with respect to what causes breaches.

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

> all of the bugs

Probably meant all of the reported bugs, given the context.

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.

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.

It's easy to look back in hindsight and take potshots based on everything someone did wrong. There's not a project out there where you couldn't do this.

I took a quick look over the thread, and TBH I find the authors' reasons and explanations compelling, logical, and respectful (their FAQ, the fact that they polled the users almost a year ago, the fact that they announced their intentions in advance, and how to deal with the impending changes). I suggest you re-think your approach; this won't reflect well.

Your arguments are fair.

However, can you tell me more what you mean about rethinking my approach? I am not sure what approach you are referring to.

I mean escalating a minor dust-up into a blog post about their wrongs, and then further pushing it in a worldwide forum (HN).

I don't mean to be rude, but as a disinterested third party, the optics of all of this and your handling of a disagreement reflect badly upon you. At some point in the future after you've cooled off, you'll probably delete the post (but better sooner than later!)

I actually don't see what you said as being rude, just honest, and I appreciate that.

I actually let myself cool down before I wrote the post. I was going to write the post right after I saw the GitHub issue, but I sat on it for awhile, thinking through my thoughts.

It's unfortunate that such a dust-up (which wasn't minor, by the way; it got published in LWN, see https://lwn.net/Articles/845535/) was a perfect way to make arguments against Rust that I have wanted to make.

And I wanted to make them because if Rust can be as portable as C, I would LOVE that!

Author here.

If you doubt my claims about my bc, I suggest you break it and post it here. Embarrass me.

Yes, I am throwing down the gauntlet because I am that confident in my work. Prove me wrong with actual data.

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.

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.

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-hand...

[2] https://doc.rust-lang.org/book/ch09-02-recoverable-errors-wi...

Were you looking for this?

https://doc.rust-lang.org/stable/reference/expressions/opera...

I mentioned that there are other places in the Book where this information is mentioned, but it's funny how the `?` is described in at least 3 places (your link plus my two other links), but the section you would expect most information about it, called "The ? operator for easier error handling" which is fully dedicated to explaining the operator, does not mention that fact.

My point, above all, is not tied to this specific example, by the way, hope you understand how an informal tutorial about the language does not replace a strict specification - and pointing out that such information is available somewhere if I look hard enough does not disprove anything.

> pointing out that such information is available somewhere if I look hard enough does not disprove anything.

I didn't look very hard, I went to the language reference and searched for "?" in the Tokens section.

Of course it’s currently possible, even in the lack of a formal Rust specification. One particularly obvious implementation is a C backend for LLVM.

Compiling to C, althought a common approach used by many that want to save the effort to implement a full backend, always has the issue that it might not be possible to express 1:1 the desired source language semantics in C, and some subtle bugs depending on which C compiler is used.

Can you give some examples of language semantics that cannot be expressed in C?

One I can think of is doing coroutine / stack swapping stuff. Though even that is not insurmountable if your sequential code is rendered into C in a “CPS” style.

Another related one is exotic manipulations of the instruction pointer beyond what goto/switch provide. This can be solved too, but inefficiently (put all jump-to-able lines of code in a big switch statement). GCC provides computed goto but that is not standard.

In either case, it’s worth pointing out that Rust does not do these types of things and it would be relatively straightforward for a machine to create a 100% semantically equivalent C program from a rust program.

Naively, I imagine it's hard to implement (efficient) overflow semantics for integers in C, without any UB. Rust provides operators for [wrapping overflow](https://doc.rust-lang.org/nightly/std/primitive.isize.html#m...), [saturating overflow](https://doc.rust-lang.org/nightly/std/primitive.isize.html#m...), etc. You can't use UB because then the C compiler can miscompile your code.

Semantics of loops might also be tricky. In fact rust struggles with LLVM's optimizer already on some infinite loops because C++ and rust diverge in semantics there.

That’s actually trivial using unsigned arithmetic and two’s complement representation for signed integers, its also equally efficient[1]. Unsigned arithmetic is fully defined in c, including checking for overflow.

[1] gcc for example generates optimal code when doing checked addition: https://godbolt.org/z/9jnesx

But that's my point; how can you be sure the compiler will emit the right code instead of assuming that the addition does not overflow and then proceed on pruning the test, since overflow on signed integers is not defined?

You implement it by using unsigned arithmetic, then checking that the sign bit flipped. See https://git.yzena.com/Yzena/Yc/src/branch/master/include/yc/... .

It's a bit more subtle than that, but that is completely devoid of Undefined, Unspecified, and Implementation-Defined Behavior.

The people that are angry about it should feel free to take the last source code that worked for them and fork it and maintain it.

> 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

Author here.

Thank you for this. I will update the post with this information.

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.

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

Author here.

Can you give me a link to the Reddit thread?

Sure,

https://old.reddit.com/r/rust/comments/luawx6/rust_zig_and_t...

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.

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.

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?

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++.

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).

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?

That is partially the reason why all big OS and CPU vendors are investing into hardware memory tagging.

project verona is _one_ attempt at doing this, ebpf is another

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

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-analysi...

???

Rust freely declares itself to be inspired by Cyclone et al, but its capabilities are quite different from Cyclone's region analysis (and Carp actually came after Rust).

The C++ static analysis, on the other hand, is quite limited in comparison even to Cyclone. It's not sound and doesn't even aim to be- in other words, "just" another static analysis that will not catch everything. ("Just" in quotes because of course more of this is great- my point is merely that it's not the same functionality coming to C++.)

Read the comment I was replying to, before jumping into Rust advocacy mode.

> My understanding is that Rust's chief innovation is the borrow checker.

Carp was a mistake, I wanted to refer to Linear Lisp.

Also in the context of worse is better, C and C++ solutions just need to be good enough.

Learn this and advocate properly.

What makes you think I'm "advocating" anything? My goal is for people to understand the state of things.

C and C++ have had static analyzers to catch "some version" of these problems for a long time now, so presumably anyone asking about borrow checker functionality would be interested in whether that functionality matches Rust's (i.e. is sound).

It reads like it.

We should not forget that even if those static analysers aren't sound, they allow to keep using 50 years of eco-system.

Which is why companies like Microsoft, despite all security talk, in the end add support for recent ISO C versions, and have "secure" platforms like Azure Sphere with a C only SDK.

I don't disagree:

> ("Just" in quotes because of course more of this is great- my point is merely that it's not the same functionality coming to C++.)

We agree then, it is better than not trying to improve anything I guess.

The author also wrote a blog post about how much he hates wearing anti-covid masks 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.

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?!?

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.

I have trouble taking seriously claims that public health orders are tyranny when I can remember when the US had conscription.

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

Gavin here.

See https://news.ycombinator.com/item?id=26293979 .

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-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".

I think you misunderstand my arguments. I think the ubiquity of masks hurts everybody.

Because you can't see faces???

Who knows? The point is that we don't know all of the ways that masks affect us.

Look, bub, you're on HN, now on /r/im14andthisisdeep.

> Who knows? The point is that we don't know all of the ways that masks affect us.

I don't know all the ways that the rice I ate yesterday affects me. I'm not going to stop eating rice because of this.

Your argument is completely null.

When there's no clear proof of something having a strong negative effect, the rational thing is to assume it doesn't have a strong negative effect.

When something clearly has a strong positive effect, the rational thing is to assume it has a strong positive effect.

And when we decide to do something, we balance positives with negatives. There is nothing in this world that only has positive aspects (the opposite is also true, nothing truly has only negative aspects). We never do something because it's "perfect", we do things that are "good" (more positives than negatives). We live because of water and oxygen but water can drown us and oxygen can burn us.

Your logic is: "a lot of very respectable people (as well as common sense) say that this thing has a positive effect, but I don't know if it has any negative effect, so I just won't do it at all".

That's no logic, it sounds more like spite.

I don't say this lightly, even on the internet, but you act like a horrible person. Please reflect on your behavior and for your sake, I hope you change.

Anyway, goodbye!

Rice has been with humans since basically the beginning. Masks, not so much. My argument is that we don't know if there are actually more positives than negatives with masks.

Oh, and by the way, there's arsenic in rice. https://www.fda.gov/food/cfsan-risk-safety-assessments/arsen...

What does his position on masks have to do with the arguments he is making here?

> What does his position on masks have to do with the arguments he is making here?

The Internet doesn't have a shortage of rants. If you're wrong about other areas then why should I care about your opinions on technology?

Because he might have more expertise and experience in technology than medicine. We should evaluate arguments on their merits alone, ad hominem is destructive to effective discussion.

> We should evaluate arguments on their merits alone, ad hominem is destructive to effective discussion.

That doesn't consider the opportunity cost; time that I spend on this argument can't be spent on another better argument.

There are more arguments then I could read in a lifetime so I focus my attention on people who are otherwise sensible.

> so I focus my attention on people who are otherwise sensible.

Participation in a discussion usually implies an interest and a willingness to spend your time considering various arguments. If you only limit your exposure to arguments made by people who agree with you in other domains then I have to conclude your interest in this space is not very high.

> Participation is a discussion usually implies an interest and a willingness to spend your time considering various arguments.

My only posts in this thread have been to explain why I flagged the post and why I feel it's valid to dismiss the author based on his other views.

The author's position on masks is that he's too precious to comply with local laws, that businesses complying with said laws should be boycotted, and that executive orders aren't actually laws so he isn't bound by them. The first two beliefs are merely antisocial; it's the last claim that causes me to place him in the crank category.

> If you only limit your exposure to arguments made by people who agree with you in other domains then I have to assume your interest in this space is not very high.

My political beliefs are sufficiently bizarre that at best few people agree with them; if anything, he and I probably have some beliefs in common.

I consider dismissing arguments outright based on ad hominem and guilt by association without consideration of their substance deeply anti social and otherwise harmful to human collaboration, peace, and progress.

For why I used bc, see https://news.ycombinator.com/item?id=26293876 .

For masks, see https://gavinhoward.com/2020/08/masks-and-carbon-dioxide/ and https://gavinhoward.com/2020/08/in-science-all-factors-matte... . In essence, those who claim that masks work might be right, but they also ignore other factors that, if considered, might show that masks are worse for us overall.

Your models don’t agree with experimental data.

They don't agree with _some_ experimental data, but yes.

Show me experimental data that they agree with.

He seems to have many, ah, "controversial" opinions: https://campaign.gavinhoward.com/platform/

On religion and LGBTQ issues: > A strong, free nation can only be made up of religious and virtuous individuals, strong nuclear families with a cisgender father and a cisgender mother, and a lively and effective civil society, all protected under the wise framework of the Constitution as it was intended by our Founding Fathers. > To have a virtuous people, America must return to its religious roots. > Strong, nuclear families consisting of a cisgender father and a cisgender mother are the “fundamental units of society." All governments under the Constitution should protect and encourage them and discourage all other kinds of families made through voluntary actions.

On the right to vote and welfare: > they who have actually paid for the services of government, and thus, should have a say in how it runs. Those who haven’t, and get themselves addicted to welfare, should not, for they do not pay the price of living in society. > In addition, all government welfare is waste.

You can look at the sidebar for more fun tags, to see his opinions about Black Lives Matter (evil), "censorship" (Facebook and Squarespace taking down his favorite conspiracy pages), and many tags about his Mormon faith, which as an atheist, is probably not my place to criticize.

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.

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.

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.

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.

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.

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?

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.

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

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.

I think you’re missing what the essence of “worse is better” means. It’s about the complexity of provided solutions, not generic “badness” or undone work. This is explained well in the original “worse is better” paper (lisp vs C).

Even if rust lacks a formal spec and ports to multiple platforms, it is unarguably more complex than C and is an example of “MIT” engineering. Both Rust and Zig pursue the “right thing” whereas C pursued the simplest workable thing, thus increasing its virality.

Until Zig fixes use-after-free, it isn't pursuing the "right thing".

Apple, Google, Microsoft, ARM, Oracle are taming C with hardware memory tagging.

Apple and Microsoft on top of that, have their safe C dialects.

Red-Hat, Google and Microsoft are adding lifetime analysers to their C and C++ compilers.

I think they understand why C is ubiquitous, and why something has to be done to fix it.

Rust/Zig may have reasonable success in large companies such as those you mention. Lisp also finds strong usage in specific domains and industries.

Their complexity will limit their success in the long tail of use cases where C is well established and “good enough.”

Reply on news.ycombinator.com