7 ms·

I think that you express a fallacy. You're saying that nobody can provide thoughtful criticism unless they take up the task themselves. So the next time you cri

by muraiki 10y ago

I think that you express a fallacy. You're saying that nobody can provide thoughtful criticism unless they take up the task themselves. So the next time you criticize politics, are you going to run for office? The next time you criticize a meal, are you going to become a chef? The next time you criticize a car, are you going to become an engineer? Yes, it's one thing to make thoughtless and uninformed criticism. But providing thoughtful and useful criticism does not necessarily require actively creating something from scratch. Otherwise, we would all only be starting new projects and never collaborating!

jacquesm 10y ago
No, he's spot on. The one thing that keeps happening over-and-over again is that people who have never put together a system of any complexity will yell from the sidelines how others should build their stuff. This goes for operating systems, application software and advanced rocketry alike. The reason we have so much C code powering the world is that (1) there wasn't anything better when that code was written, (2) time has weeded out most of the bad bugs to the point that the old codebase will be substantially more stable than anything new no matter what language you would write it in. If someone is willing to throw a few hundred million or so at re-building an operating system from the ground up that is 100% safe and reliable and that does not have more bugs than what is available right now then they are free to do so. They're also free to donate their own time and to try to enlist their buddies. But they're not free to yell at others how those others should do their jobs. Show don't tell.
- adwn 10y ago
  > (2) time has weeded out most of the bad bugs to the point that the old codebase will be substantially more stable than anything new no matter what language you would write it in. This seems to assume that the codebase is stable and in maintainance mode. However, the reality for the vast majority of open-source projects is that they're either being actively developed, adding new code and new bugs, or they're abandoned.
- fauigerzigerk 10y ago
  >The reason we have so much C code powering the world is that (1) there wasn't anything better when that code was written... Right, but the criticism he received for his first post was not primarily about choosing the wrong language or about refusing to rewrite in a different language now. It was primarily about downplaying the role of C in the security issues that were found. The rest of the debate, at least as I read it, was not so much criticism as it was a generic debate about the pros and cons of various programming languages like we're having one every other day on here and on reddit. Choosing C back then was clearly justified for a project like curl given all the constraints and considerations. And for a rewrite to be a net positive in terms of security probably takes years, not to mention the huge effort that someone would have to put into it.
- alkonaut 10y ago
  > If someone is willing to throw a few hundred million or so at re-building an operating system from the ground up that is 100% safe and reliable and that does not have more bugs than what is available right now then they are free to do so. But at the same time - we are spending those billions. We keep throwing billions at Apple by buying their new phones, yet they release lists of security issues which this time were basically all: - malicious crafted image -> remote code execution - maliciously crafted font -> remote code execution - maliciously crafted audio -> remote code execution I'm not sure if I have to be able to write a font parser and rendering subsystem in a memory safe language myself to be allowed to complain that Apple is using my money for something other than doing just that. To me it's completely mind blowing that someone uses a C library to parse complex third party binary data from the internet.
  - mirekrusin 10y ago
    If c lib is mind-blowing, what about kernel and it's extensions? For now c is the only thing we have that can be used so widely. Some day we may be able to use rust or something else, but that's future, not present.
    - steveklabnik 10y ago
      Rust can speak C's ABI, so you can write kernel extensions in Rust. There's some legwork involved, but it's quite possible.
      - mirekrusin 10y ago
        Interesting. So you're saying that Rust, at the moment, in theory, can be used in any place where C is required? Ie. writing kext on macOS, loadable kernel module on Linux or things like extension for SQLite are all possible? In that case I wonder if there are any theoretical blockers for things like (using no_std and) mapping internally used C structures (let's say BSD kernel's rbtree) into typed, first-class Rust citizens - to avoid std overhead and reuse what's already available? In other words - is there anything there in C macros that can't effectively be expressed in Rust for example?
- acqq 10y ago
  Exactly, show don't tell. And when I point to the fact that the Rust codebase itself has a lot of "unsafe" places I get the explanation "yes, but it's an old code and we haven't had the time to rewrite it to use the newer features that would allow more safe code." Think about it: the people who design Rust don't have the time to rewrite their own Rust code to be safe. When there's no time to rewrite the code of Rust to be demonstrably safe, why should any other project have more time than that, where the programmers know Rust much less or not at all? Maintaining the successful project is hard and takes a lot of time, even without switching to something new. Second point: look at the Benchmark game, a fast Rust code example also typically has an "unsafe" code. So it's still not even demonstrated that "you can have it both fast and safe" holds for these examples. Fast as in "as fast as C" and "safe" as in "provably safer than C." Finally, I believe that the language should simply implement a language-level no-cost check for integer overflow, as the machine languages already have, and not complain that there aren't some special mechanisms in CPUs to do it differently. It's your language's failure if you can't use what already exists. The CPUs already can do it, the high level languages don't provide the high-level access to it. Which doesn't matter for C which is "unsafe" by definition (and where it's natural to call some asm when needed) but it should for Rust which goal is to produce a more provably "safe" code. Writing unsafe Rust instead of unsafe C is not giving you any real advantage for the existing projects, as long as the state is as it is. Also, look how Rust uses TLS. Is safely rewriting a crypto library which is useful in real project still a too big task to be taken? I like the perspectives of what Rust could bring. But I'd like to see a real life case of its success too.
  - staticassertion 10y ago
    > Writing unsafe Rust instead of unsafe C is not giving you any real advantage for the existing projects, as long as the state is as it is. Your argument hinges pretty heavily on this. It's incorrect. The reality is that unsafe code in rust is not like unsafe code in C. First, it's bounded to a module. Second, you can grep for it (huge). Third, you still have less UB in unsafe rust than in C. I've never written code in rust that required unsafe, after many thousands of lines. > Is safely rewriting a crypto library which is useful in real project still a too big task to be taken? https://github.com/ctz/rustls https://github.com/ctz/rustls ????????????? > But I'd like to see a real life case of its success too. Ripgrep is a nice one to point to. There's redox too. Tons of rust code out there.
- _ph_ 10y ago
  I have put together systems of considerable complexity (>100k lines), and am working professional programmer for almost 2 decades. Most of my work does not involve C, but various "safe" languages. There were better alternatives already available at the beginning of the 70s, and certainly when most of the software was written that we are using today. Just to name a few I am familiar of with: - Pascal being as old as C, and later on - Modula 2, Oberon, the Oberon System was completely implemented in Oberon - Eiffel and of course, today: - Rust - Go So, even back then, there were more safe alternatives to C around. C gained more popularity, and consequently the tooling gave it some edge, but there would have been alternatives. Of course, when you have a nice debugged C program, that is something worth keeping. And as a consequence, for mostly historic reasons, a lot of our current infrastructure is built on top of C - but that alone does not mean that C was the perfect or even the right tool to build all of this upon.
- deleted 10y ago
  [deleted]
- sidlls 10y ago
  I wouldn't put it as strongly--I think valid criticism can come from someone who hasn't "put something together"--but at the same time I think a lot of the criticism in this area isn't all that valid. Some of it is, but mostly it seems to me just people parroting "c is unsafe" as though that is itself the end of the discussion.
Ygg2 10y ago
God help anyone criticizing Google. You make your own multi billion corporation.
- mannykannot 10y ago
  If a person was claiming it should be much bigger and more successful than it is, and that claim is primarily opinion-based, one might take into consideration that person's achievements when evaluating their claim.
chongli 10y ago
It's one thing to criticize somebody over a missing feature or a bug. It doesn't take an engineer to author a valid complaint when a car door handle falls off. It's another thing entirely to criticize an entire methodology or to try to dictate exactly how something should be done.
- viraptor 10y ago
  I don't think this generalises that well. We're learning some general truths that should be known to many people with enough time. You can certainly criticise whole architecture and methodology based on those ideas. For some ideas it took a long time before they became something obvious - we may be at a time when the scales are slowly tipping. For example imagine telling someone in 2000 that they should be running an automated continuous integration pipeline rather than purely manual testing. Now it's a norm. Then, we were still discussing whether Extreme Programming was a waste of time. But we also didn't have the tools to support the CI properly. Memory safe compiled languages seem to me like the same thing. We had things like Cyclone, OOC, and other experiments which barely anyone knew. Now we have Rust which is still hard to use, but it's gaining ground. In a decade, I hope to be pointing out to this post when someone complains that you can't criticize an entire methodology. "Remember when people said the same thing about enforced memory safety?" Curl will not be rewritten of course. But I'm happy people push this idea. The next curl will not be written in C.
- josteink 10y ago
  > It doesn't take an engineer to author a valid complaint when a car door handle falls off. It's another thing entirely to criticize an entire methodology or to try to dictate exactly how something should be done. But if a car manufacturer consistently uses a production methodology which causes door handles to keep falling off, again and again, even after they've been re-glued on for the Nth time... Then I think it's fair game to say that you think there's something wrong with the methodology. People suggesting alternate approaches without putting in the actual work involved may very well be "backseat drivers of the Internet"-type commenters, but that doesn't mean they're not on to something.
  - 10y ago
mikulas_florek 10y ago
If I say: "There are all these bugs in curl, you should rewrite it in rust and it will be better (but I've never done anything similar, nor there is any scienetific proof for what I am saying)" then it's not thoughtful criticism, but pure personal opinion. There is a very low value in that. On the other hand if there is a project like curl rewritten from C to Rust and its author says: "We have switched from C to Rust in a year and after two years we have less new bugs", there is at least some value.
mannykannot 10y ago
No, it is not a fallacy - when it comes to matters of opinion on the feasibility of difficult tasks, experience has some relevance. Your objection follows a common pattern - if we took every nuanced situation and turned it into a universal black-and-white dichotomy, we would end up with half the arguments on the internet.
spoiler 10y ago
It's not what I tried to say, but I see your point. I merely pointed out that the people who're saying saying "Why not rewrite curl in X" probably didn't stop to think how challenging it would be. > The next time you criticize a meal, are you going to become a chef? Well, they're not criticising the meal here, they're criticising the kitchen it was prepared in. :P But joking aside, they don't need to rebuild all of curl in <language of choice>, just get it started, and if enough people think it's a worthwhile project, they will contribute. > But providing thoughtful and useful criticism does not necessarily require actively creating something from scratch. I agree. However, a lot of these comments are along the lines of "C is unsafe. Go rewrite curl in Rust!"[1] without realising how much effort and time that would take (and I'd not be surprised if some portion of this group never worked on a project in either language). I personally don't find those types of comments very useful. > Otherwise, we would all only be starting new projects and never collaborating! This is what the people I'm referring to are essentially asking. Going hybrid would probably introduce subtle bugs, and increase complexity and maintainability down the line. [1]: I love Rust, and a few of my recent pet projects are being written in Rust (one of which is being ported from C). So, I'm not trying to bash Rust. I'd even encourage anyone to use Rust over C, if they were to start a new project.
Brockenstein 10y ago
It's not that anyone who has an opinion or criticism has to be an expert or be in the trenches. But in the same token not every tom, dick and harry has valuable opinion or criticism that puts them on par with people doing the work or legitimate experts. There's certainly a fine line to walk between ignoring people or wasting your time trying to filter out a cacophony of opinion and belief from anyone willing to utter it.
EpicEng 10y ago
I think the parent is correct, and the situation is more nuanced than your argument would suggest. Politics: Are you critiquing the distribution of funds to the school your child attends? You probably have some insight there. Are you instead expressing a strong opinion on a complex subject that you likely don't have an iota of experience with? Well, then you should realize that you're probably not in a position to have such a strong opinion. Meal: You're the user, so you have experience here. All you're commenting on is how it tastes to you, so that's perfectly valid, no need to become a chef. Car: Again, you're the user. Are you critiquing a UX problem? Well, then you're in a perfect position to do so. If you're remarking about e.g. the torque to weight ratio then you should probably understand some of the engineering that goes into creating a vehicle. Your argument is the fallacious one here. You're making an all or nothing comparison and life rarely works that way. If you're going to make a statement like "you should rewrite curl in X language" then yes, you should know what the hell you're talking about because you're making an engineering level statement.
- muraiki 10y ago
  I wasn't making the argument that curl should be rewritten in Rust. It's too late to edit my comment to clarify it, so please see my response here: https://news.ycombinator.com/item?id=13996154 https://news.ycombinator.com/item?id=13996154
deleted 10y ago
[deleted]
muraiki 10y ago
Replying to myself, since I can no longer edit what I posted: I'm not advocating the developers of curl rewriting it in Rust! I think that a lot of the debate here is around a few different points, and that we're generally talking past one another. My primary concern was that the initial response seemed to disregard the vulnerabilities that can occur due to unsafe memory management. To the extent that I read people say arguments along the line of "you can only make that criticism if you write a curl replacement yourself", I felt that that was unfair.

by muraiki 10y ago

jacquesm 10y ago

No, he's spot on. The one thing that keeps happening over-and-over again is that people who have never put together a system of any complexity will yell from the sidelines how others should build their stuff. This goes for operating systems, application software and advanced rocketry alike. The reason we have so much C code powering the world is that (1) there wasn't anything better when that code was written, (2) time has weeded out most of the bad bugs to the point that the old codebase will be substantially more stable than anything new no matter what language you would write it in. If someone is willing to throw a few hundred million or so at re-building an operating system from the ground up that is 100% safe and reliable and that does not have more bugs than what is available right now then they are free to do so. They're also free to donate their own time and to try to enlist their buddies. But they're not free to yell at others how those others should do their jobs. Show don't tell.

adwn 10y ago
> (2) time has weeded out most of the bad bugs to the point that the old codebase will be substantially more stable than anything new no matter what language you would write it in. This seems to assume that the codebase is stable and in maintainance mode. However, the reality for the vast majority of open-source projects is that they're either being actively developed, adding new code and new bugs, or they're abandoned.
fauigerzigerk 10y ago
>The reason we have so much C code powering the world is that (1) there wasn't anything better when that code was written... Right, but the criticism he received for his first post was not primarily about choosing the wrong language or about refusing to rewrite in a different language now. It was primarily about downplaying the role of C in the security issues that were found. The rest of the debate, at least as I read it, was not so much criticism as it was a generic debate about the pros and cons of various programming languages like we're having one every other day on here and on reddit. Choosing C back then was clearly justified for a project like curl given all the constraints and considerations. And for a rewrite to be a net positive in terms of security probably takes years, not to mention the huge effort that someone would have to put into it.
alkonaut 10y ago
> If someone is willing to throw a few hundred million or so at re-building an operating system from the ground up that is 100% safe and reliable and that does not have more bugs than what is available right now then they are free to do so. But at the same time - we are spending those billions. We keep throwing billions at Apple by buying their new phones, yet they release lists of security issues which this time were basically all: - malicious crafted image -> remote code execution - maliciously crafted font -> remote code execution - maliciously crafted audio -> remote code execution I'm not sure if I have to be able to write a font parser and rendering subsystem in a memory safe language myself to be allowed to complain that Apple is using my money for something other than doing just that. To me it's completely mind blowing that someone uses a C library to parse complex third party binary data from the internet.
- mirekrusin 10y ago
  If c lib is mind-blowing, what about kernel and it's extensions? For now c is the only thing we have that can be used so widely. Some day we may be able to use rust or something else, but that's future, not present.
  - steveklabnik 10y ago
    Rust can speak C's ABI, so you can write kernel extensions in Rust. There's some legwork involved, but it's quite possible.
    - mirekrusin 10y ago
      Interesting. So you're saying that Rust, at the moment, in theory, can be used in any place where C is required? Ie. writing kext on macOS, loadable kernel module on Linux or things like extension for SQLite are all possible? In that case I wonder if there are any theoretical blockers for things like (using no_std and) mapping internally used C structures (let's say BSD kernel's rbtree) into typed, first-class Rust citizens - to avoid std overhead and reuse what's already available? In other words - is there anything there in C macros that can't effectively be expressed in Rust for example?
acqq 10y ago
Exactly, show don't tell. And when I point to the fact that the Rust codebase itself has a lot of "unsafe" places I get the explanation "yes, but it's an old code and we haven't had the time to rewrite it to use the newer features that would allow more safe code." Think about it: the people who design Rust don't have the time to rewrite their own Rust code to be safe. When there's no time to rewrite the code of Rust to be demonstrably safe, why should any other project have more time than that, where the programmers know Rust much less or not at all? Maintaining the successful project is hard and takes a lot of time, even without switching to something new. Second point: look at the Benchmark game, a fast Rust code example also typically has an "unsafe" code. So it's still not even demonstrated that "you can have it both fast and safe" holds for these examples. Fast as in "as fast as C" and "safe" as in "provably safer than C." Finally, I believe that the language should simply implement a language-level no-cost check for integer overflow, as the machine languages already have, and not complain that there aren't some special mechanisms in CPUs to do it differently. It's your language's failure if you can't use what already exists. The CPUs already can do it, the high level languages don't provide the high-level access to it. Which doesn't matter for C which is "unsafe" by definition (and where it's natural to call some asm when needed) but it should for Rust which goal is to produce a more provably "safe" code. Writing unsafe Rust instead of unsafe C is not giving you any real advantage for the existing projects, as long as the state is as it is. Also, look how Rust uses TLS. Is safely rewriting a crypto library which is useful in real project still a too big task to be taken? I like the perspectives of what Rust could bring. But I'd like to see a real life case of its success too.
- staticassertion 10y ago
  > Writing unsafe Rust instead of unsafe C is not giving you any real advantage for the existing projects, as long as the state is as it is. Your argument hinges pretty heavily on this. It's incorrect. The reality is that unsafe code in rust is not like unsafe code in C. First, it's bounded to a module. Second, you can grep for it (huge). Third, you still have less UB in unsafe rust than in C. I've never written code in rust that required unsafe, after many thousands of lines. > Is safely rewriting a crypto library which is useful in real project still a too big task to be taken? https://github.com/ctz/rustls https://github.com/ctz/rustls ????????????? > But I'd like to see a real life case of its success too. Ripgrep is a nice one to point to. There's redox too. Tons of rust code out there.
_ph_ 10y ago
I have put together systems of considerable complexity (>100k lines), and am working professional programmer for almost 2 decades. Most of my work does not involve C, but various "safe" languages. There were better alternatives already available at the beginning of the 70s, and certainly when most of the software was written that we are using today. Just to name a few I am familiar of with: - Pascal being as old as C, and later on - Modula 2, Oberon, the Oberon System was completely implemented in Oberon - Eiffel and of course, today: - Rust - Go So, even back then, there were more safe alternatives to C around. C gained more popularity, and consequently the tooling gave it some edge, but there would have been alternatives. Of course, when you have a nice debugged C program, that is something worth keeping. And as a consequence, for mostly historic reasons, a lot of our current infrastructure is built on top of C - but that alone does not mean that C was the perfect or even the right tool to build all of this upon.
deleted 10y ago
[deleted]
sidlls 10y ago
I wouldn't put it as strongly--I think valid criticism can come from someone who hasn't "put something together"--but at the same time I think a lot of the criticism in this area isn't all that valid. Some of it is, but mostly it seems to me just people parroting "c is unsafe" as though that is itself the end of the discussion.

Ygg2 10y ago

God help anyone criticizing Google. You make your own multi billion corporation.

mannykannot 10y ago
If a person was claiming it should be much bigger and more successful than it is, and that claim is primarily opinion-based, one might take into consideration that person's achievements when evaluating their claim.

chongli 10y ago

It's one thing to criticize somebody over a missing feature or a bug. It doesn't take an engineer to author a valid complaint when a car door handle falls off. It's another thing entirely to criticize an entire methodology or to try to dictate exactly how something should be done.

viraptor 10y ago
I don't think this generalises that well. We're learning some general truths that should be known to many people with enough time. You can certainly criticise whole architecture and methodology based on those ideas. For some ideas it took a long time before they became something obvious - we may be at a time when the scales are slowly tipping. For example imagine telling someone in 2000 that they should be running an automated continuous integration pipeline rather than purely manual testing. Now it's a norm. Then, we were still discussing whether Extreme Programming was a waste of time. But we also didn't have the tools to support the CI properly. Memory safe compiled languages seem to me like the same thing. We had things like Cyclone, OOC, and other experiments which barely anyone knew. Now we have Rust which is still hard to use, but it's gaining ground. In a decade, I hope to be pointing out to this post when someone complains that you can't criticize an entire methodology. "Remember when people said the same thing about enforced memory safety?" Curl will not be rewritten of course. But I'm happy people push this idea. The next curl will not be written in C.
josteink 10y ago
> It doesn't take an engineer to author a valid complaint when a car door handle falls off. It's another thing entirely to criticize an entire methodology or to try to dictate exactly how something should be done. But if a car manufacturer consistently uses a production methodology which causes door handles to keep falling off, again and again, even after they've been re-glued on for the Nth time... Then I think it's fair game to say that you think there's something wrong with the methodology. People suggesting alternate approaches without putting in the actual work involved may very well be "backseat drivers of the Internet"-type commenters, but that doesn't mean they're not on to something.
- 10y ago

mikulas_florek 10y ago

If I say: "There are all these bugs in curl, you should rewrite it in rust and it will be better (but I've never done anything similar, nor there is any scienetific proof for what I am saying)" then it's not thoughtful criticism, but pure personal opinion. There is a very low value in that. On the other hand if there is a project like curl rewritten from C to Rust and its author says: "We have switched from C to Rust in a year and after two years we have less new bugs", there is at least some value.

mannykannot 10y ago

No, it is not a fallacy - when it comes to matters of opinion on the feasibility of difficult tasks, experience has some relevance. Your objection follows a common pattern - if we took every nuanced situation and turned it into a universal black-and-white dichotomy, we would end up with half the arguments on the internet.

spoiler 10y ago

It's not what I tried to say, but I see your point. I merely pointed out that the people who're saying saying "Why not rewrite curl in X" probably didn't stop to think how challenging it would be. > The next time you criticize a meal, are you going to become a chef? Well, they're not criticising the meal here, they're criticising the kitchen it was prepared in. :P But joking aside, they don't need to rebuild all of curl in <language of choice>, just get it started, and if enough people think it's a worthwhile project, they will contribute. > But providing thoughtful and useful criticism does not necessarily require actively creating something from scratch. I agree. However, a lot of these comments are along the lines of "C is unsafe. Go rewrite curl in Rust!"[1] without realising how much effort and time that would take (and I'd not be surprised if some portion of this group never worked on a project in either language). I personally don't find those types of comments very useful. > Otherwise, we would all only be starting new projects and never collaborating! This is what the people I'm referring to are essentially asking. Going hybrid would probably introduce subtle bugs, and increase complexity and maintainability down the line. [1]: I love Rust, and a few of my recent pet projects are being written in Rust (one of which is being ported from C). So, I'm not trying to bash Rust. I'd even encourage anyone to use Rust over C, if they were to start a new project.

Brockenstein 10y ago

It's not that anyone who has an opinion or criticism has to be an expert or be in the trenches. But in the same token not every tom, dick and harry has valuable opinion or criticism that puts them on par with people doing the work or legitimate experts. There's certainly a fine line to walk between ignoring people or wasting your time trying to filter out a cacophony of opinion and belief from anyone willing to utter it.

EpicEng 10y ago

I think the parent is correct, and the situation is more nuanced than your argument would suggest. Politics: Are you critiquing the distribution of funds to the school your child attends? You probably have some insight there. Are you instead expressing a strong opinion on a complex subject that you likely don't have an iota of experience with? Well, then you should realize that you're probably not in a position to have such a strong opinion. Meal: You're the user, so you have experience here. All you're commenting on is how it tastes to you, so that's perfectly valid, no need to become a chef. Car: Again, you're the user. Are you critiquing a UX problem? Well, then you're in a perfect position to do so. If you're remarking about e.g. the torque to weight ratio then you should probably understand some of the engineering that goes into creating a vehicle. Your argument is the fallacious one here. You're making an all or nothing comparison and life rarely works that way. If you're going to make a statement like "you should rewrite curl in X language" then yes, you should know what the hell you're talking about because you're making an engineering level statement.

muraiki 10y ago
I wasn't making the argument that curl should be rewritten in Rust. It's too late to edit my comment to clarify it, so please see my response here: https://news.ycombinator.com/item?id=13996154 https://news.ycombinator.com/item?id=13996154

deleted 10y ago

[deleted]

muraiki 10y ago

Replying to myself, since I can no longer edit what I posted: I'm not advocating the developers of curl rewriting it in Rust! I think that a lot of the debate here is around a few different points, and that we're generally talking past one another. My primary concern was that the initial response seemed to disregard the vulnerabilities that can occur due to unsafe memory management. To the extent that I read people say arguments along the line of "you can only make that criticism if you write a curl replacement yourself", I felt that that was unfair.