7 ms·

> Rust is great, but not great enough to justify a redo of a program that has been extended and maintained for decades (like vim or photoshop). I agree with th

by stymaar 10y ago

> Rust is great, but not great enough to justify a redo of a program that has been extended and maintained for decades (like vim or photoshop). I agree with that, and most people do even in the Rust community. I don't expect people to rewrite their software in Rust, but if people could stop writing new C code[1], the world would become a better place in the next decades … > Whenever C gets brought up, people are like, "pointers... memory... dangerous!" In 20+ years of C, I've never had a (self-inflicted) problem in that area. In 20+ years of C, you never faced a single segfault ?! I'm sorry but I don't trust you. You're basically pretending being the One True God of programming. [1]: even in a full C project, it's straightforward to write you new code in Rust in separate files, thanks to Rust really good interop with C. Example: https://bawk.space/2016/10/06/c-to-rust.html https://bawk.space/2016/10/06/c-to-rust.html

jstewartmobile 10y ago
My claim is that the particular class of bugs relating to memory/overflows have not been an issue in my career, while bugs arising from API and language ambiguities have caused considerable headaches.
- emmelaich 10y ago
  The problems caused by language ambiguities and pointer arithmetic and addressing is exactly what makes C difficult. So, I don't disbelieve you but I've known 20 year C experts have their WTF moments when shown code that would seem to work but doesn't. But I agree that C difficulty is sometimes exaggerated - partly it's expectations. ps. by ambiguity do you mean undefined behaviour?
  - thegeekpirate 10y ago
    > So, I don't disbelieve you but I've known 20 year C experts have their WTF moments when shown code that would seem to work but doesn't. If after 20 years they don't know the C spec well enough to know if a piece of code should work or not, I simply wouldn't consider them very good programmers.
    - emmelaich 10y ago
      Hrrm. If Jon Bentley can have a bug in his Programming Pearl book then so can anyone. https://research.googleblog.com/2006/06/extra-extra-read-all-about-it-nearly.html https://research.googleblog.com/2006/06/extra-extra-read-all...
      - thegeekpirate 10y ago
        I never said they wouldn't create bugs, but not fully understanding a line of code (outside of needing to conceptualize external dependencies) is certainly frightening after 20 years of working in C.
        ktRolster 10y ago
        What it shows is that sort of code never shows up in practical C. There's stuff in Java (and Javascript for that matter) I don't understand, and I've been programming in those for about as long as anybody.
        thegeekpirate 10y ago
        Absolutely.
ArkyBeagle 10y ago
It's just not that difficult to avoid segfaults, signed integer overflow, all the usual Mr. Hyde aspects of C. There's nothing godlike about it - it's just practice. He's been using C for 20+ years. So that's probably 10+ years of very little or no Bad UB Voodoo.
- kbenson 10y ago
  > He's been using C for 20+ years. So that's probably 10+ years of very little or no Bad UB Voodoo. The implication being that it takes nearly 10 years of C programming experience to get to the point where there's very little or no bad UB voodoo? I guess as long as we only let 10-year veterans of C write programs in it, we're fine then. We can solve how to deal with the fact nobody else if getting experience in C anymore because they aren't allowed to write in C later...
  - ArkyBeagle 10y ago
    I meant very probably. Surely it takes less than that.
    - kbenson 10y ago
      Sure, but 10 years is a large enough time that "less than that" can be half, it it's still rather long. There's something to be said for languages that change the effects of poor choices from security problems and inefficiencies to mostly just inefficiencies. Nobody is born knowing how to program, so all programmers have to go through a phase where they don't have the knowledge or experience to make the correct choice in every situation. Every language will have some percentage of its user base subject to this more or less. Another way to think of it is herd immunity. The more we can gently guide and gently admonish these nascent programmers for doing things that are probably a bad idea, the more we can protect everyone else, the public and other programmers alike, from most their bad choices until they've learned when it's appropriate to break those rules.

by stymaar 10y ago

jstewartmobile 10y ago

My claim is that the particular class of bugs relating to memory/overflows have not been an issue in my career, while bugs arising from API and language ambiguities have caused considerable headaches.

emmelaich 10y ago
The problems caused by language ambiguities and pointer arithmetic and addressing is exactly what makes C difficult. So, I don't disbelieve you but I've known 20 year C experts have their WTF moments when shown code that would seem to work but doesn't. But I agree that C difficulty is sometimes exaggerated - partly it's expectations. ps. by ambiguity do you mean undefined behaviour?
- thegeekpirate 10y ago
  > So, I don't disbelieve you but I've known 20 year C experts have their WTF moments when shown code that would seem to work but doesn't. If after 20 years they don't know the C spec well enough to know if a piece of code should work or not, I simply wouldn't consider them very good programmers.
  - emmelaich 10y ago
    Hrrm. If Jon Bentley can have a bug in his Programming Pearl book then so can anyone. https://research.googleblog.com/2006/06/extra-extra-read-all-about-it-nearly.html https://research.googleblog.com/2006/06/extra-extra-read-all...
    - thegeekpirate 10y ago
      I never said they wouldn't create bugs, but not fully understanding a line of code (outside of needing to conceptualize external dependencies) is certainly frightening after 20 years of working in C.
      - ktRolster 10y ago
        What it shows is that sort of code never shows up in practical C. There's stuff in Java (and Javascript for that matter) I don't understand, and I've been programming in those for about as long as anybody.
        thegeekpirate 10y ago
        Absolutely.

ArkyBeagle 10y ago

It's just not that difficult to avoid segfaults, signed integer overflow, all the usual Mr. Hyde aspects of C. There's nothing godlike about it - it's just practice. He's been using C for 20+ years. So that's probably 10+ years of very little or no Bad UB Voodoo.

kbenson 10y ago
> He's been using C for 20+ years. So that's probably 10+ years of very little or no Bad UB Voodoo. The implication being that it takes nearly 10 years of C programming experience to get to the point where there's very little or no bad UB voodoo? I guess as long as we only let 10-year veterans of C write programs in it, we're fine then. We can solve how to deal with the fact nobody else if getting experience in C anymore because they aren't allowed to write in C later...
- ArkyBeagle 10y ago
  I meant very probably. Surely it takes less than that.
  - kbenson 10y ago
    Sure, but 10 years is a large enough time that "less than that" can be half, it it's still rather long. There's something to be said for languages that change the effects of poor choices from security problems and inefficiencies to mostly just inefficiencies. Nobody is born knowing how to program, so all programmers have to go through a phase where they don't have the knowledge or experience to make the correct choice in every situation. Every language will have some percentage of its user base subject to this more or less. Another way to think of it is herd immunity. The more we can gently guide and gently admonish these nascent programmers for doing things that are probably a bad idea, the more we can protect everyone else, the public and other programmers alike, from most their bad choices until they've learned when it's appropriate to break those rules.