4 ms·

I see some rust, c, c++ arguments in these comments. It’s getting tired. This is the second time this morning that I’ve stumbled across that particular flame w

by e-dant 5y ago

I see some rust, c, c++ arguments in these comments. It’s getting tired. This is the second time this morning that I’ve stumbled across that particular flame war. I understand that security and memory safety are important and necessary arguments to have. Unfortunately, it’s a larger problem than which language you use. And, even if it were, it’s not like most (or any?) of the comments in this thread are even remotely correct. On behalf of (hopefully) plenty of programmers, Let’s take a step back. Stop bugging me.

bitwize 5y ago
The log4j fiasco showed that just because you're memory safe doesn't mean you're out of the woods, security-wise. But... memory safety is still a necessary condition for a good security posture if you're building something that runs executable code. And while memory safety is theoretically possible in C, in practice it is an utterly intractable problem for human programmers to solve. The abandonment of C as a viable language, and the replacement of C code, is a critical project for the software development community. It's not the only thing that needs to be done, but it's a great and necessary first step, just like abandoning internal combustion engines is for the climate, If you are writing new, production code in C, you are a fool. If you do not have a long-term plan in place to replace the C code you have that it isn't on some God-forsaken unreflashable ROM, you are irresponsible.
- e-dant 5y ago
  I agree with everything you raise here. C is a dinosaur that should be left to museums. But I’m really, really tired of people comparing c interchangeably with c++ — and, more than anything else, if you have a good idea please just make a pull request on someone’s git repo. And just in case anyone is unclear about this, if you ship code with unbounded memory leaks you’re going to hell
  - sirwhinesalot 5y ago
    More than anything C should have had "slices" (aka fat pointers) added to the language. They wouldn't solve issues like use after free but they would enable sane ways of working with strings and buffers like every other language in existence. Instead we got VLAs (now deprecated) and _Generic. Neat but who cares? The C standards committee doesn't really know what to do with the language it seems.
    - e-dant 5y ago
      The purpose of C was to be an optimizable low-level language. If programmers wanted those things, the sense was always one of “ok, do it yourself and use it as a library.” There are definite pros and cons to that particular standards methodology. It is, without any question, the most distributable language. The ABI is and will likely always be intact. Nobody has ever argued that C is anything other than that. It’s about as dead simple as it can be. There are other languages for other purposes. Rust and C++ are, in all cases I’m aware of, equivalent in performance to their “ideal” C program alternatives. Nobody has ever argued until just recently that C is or ever has been anything other than what it is or that there is some kind of battle going on between Rust and “c/c++.” Nothing could be more untrue. C and C++ are different things. Though, with a clear lack of understanding you can write a “c” program in c++. The same is true with rust — everything can still be mutable and you can still have undefined behavior very easily (perhaps most easily with IO). Plenty of other languages exist, too, with other ways of solving these problems. Haskell is a wonderful language which I hope someday to develop with if there was only some way of making it easier to work with file systems without a PHD. This particular flame war between rust, c, and c++ is so contrived and tired and misleading.
      - sirwhinesalot 5y ago
        Eh that's rather revisionist, C was a high-level language for the 70s. It isn't nowadays because there are languages that are so much higher level that it is low level in comparison. It's not much different from Fortran in that regard. Rather than the purpose of C being an optimizable low-level language, it's more accurate to say that is the niche it carved out for itself. There's plenty of crap in C that doesn't help with either optimization or a good ABI.
        fivea 5y ago
        > Eh that's rather revisionist, C was a high-level language for the 70s. No, not really. C was always, right from the start, a kin to portable assembly. You'd be hard pressed to come up with a language from the 70s which was at the same level or lower than C. Neigher Fortran nor COBOL nor ALGOL nor Lisp nor BASIC were lower level than C. Precisely which language, other than assembly, leads you to believe that C ever was considered a high-level language? I don't understand what leads anyone to argue otherwise.
  - mrich 5y ago
    > comparing c interchangeably with c++ For the sake of the arguments made with regards to using Rust instead, they are exactly the same and comparable - both do not have memory safety, suffer from races and lots of undefined behavior. That was the whole argument. Sure, you can use only parts of C++ and use RAII to make much of that go away. But then again you can do the same in C. And nobody can enforce that everyone adheres to it.

by e-dant 5y ago

bitwize 5y ago

The log4j fiasco showed that just because you're memory safe doesn't mean you're out of the woods, security-wise. But... memory safety is still a necessary condition for a good security posture if you're building something that runs executable code. And while memory safety is theoretically possible in C, in practice it is an utterly intractable problem for human programmers to solve. The abandonment of C as a viable language, and the replacement of C code, is a critical project for the software development community. It's not the only thing that needs to be done, but it's a great and necessary first step, just like abandoning internal combustion engines is for the climate, If you are writing new, production code in C, you are a fool. If you do not have a long-term plan in place to replace the C code you have that it isn't on some God-forsaken unreflashable ROM, you are irresponsible.

e-dant 5y ago
I agree with everything you raise here. C is a dinosaur that should be left to museums. But I’m really, really tired of people comparing c interchangeably with c++ — and, more than anything else, if you have a good idea please just make a pull request on someone’s git repo. And just in case anyone is unclear about this, if you ship code with unbounded memory leaks you’re going to hell
- sirwhinesalot 5y ago
  More than anything C should have had "slices" (aka fat pointers) added to the language. They wouldn't solve issues like use after free but they would enable sane ways of working with strings and buffers like every other language in existence. Instead we got VLAs (now deprecated) and _Generic. Neat but who cares? The C standards committee doesn't really know what to do with the language it seems.
  - e-dant 5y ago
    The purpose of C was to be an optimizable low-level language. If programmers wanted those things, the sense was always one of “ok, do it yourself and use it as a library.” There are definite pros and cons to that particular standards methodology. It is, without any question, the most distributable language. The ABI is and will likely always be intact. Nobody has ever argued that C is anything other than that. It’s about as dead simple as it can be. There are other languages for other purposes. Rust and C++ are, in all cases I’m aware of, equivalent in performance to their “ideal” C program alternatives. Nobody has ever argued until just recently that C is or ever has been anything other than what it is or that there is some kind of battle going on between Rust and “c/c++.” Nothing could be more untrue. C and C++ are different things. Though, with a clear lack of understanding you can write a “c” program in c++. The same is true with rust — everything can still be mutable and you can still have undefined behavior very easily (perhaps most easily with IO). Plenty of other languages exist, too, with other ways of solving these problems. Haskell is a wonderful language which I hope someday to develop with if there was only some way of making it easier to work with file systems without a PHD. This particular flame war between rust, c, and c++ is so contrived and tired and misleading.
    - sirwhinesalot 5y ago
      Eh that's rather revisionist, C was a high-level language for the 70s. It isn't nowadays because there are languages that are so much higher level that it is low level in comparison. It's not much different from Fortran in that regard. Rather than the purpose of C being an optimizable low-level language, it's more accurate to say that is the niche it carved out for itself. There's plenty of crap in C that doesn't help with either optimization or a good ABI.
      - fivea 5y ago
        > Eh that's rather revisionist, C was a high-level language for the 70s. No, not really. C was always, right from the start, a kin to portable assembly. You'd be hard pressed to come up with a language from the 70s which was at the same level or lower than C. Neigher Fortran nor COBOL nor ALGOL nor Lisp nor BASIC were lower level than C. Precisely which language, other than assembly, leads you to believe that C ever was considered a high-level language? I don't understand what leads anyone to argue otherwise.
- mrich 5y ago
  > comparing c interchangeably with c++ For the sake of the arguments made with regards to using Rust instead, they are exactly the same and comparable - both do not have memory safety, suffer from races and lots of undefined behavior. That was the whole argument. Sure, you can use only parts of C++ and use RAII to make much of that go away. But then again you can do the same in C. And nobody can enforce that everyone adheres to it.