14 ms·

The problem is, until now there has not been a very good systems programming language that allowed you to stay lean on memory without introducing any performanc

The problem is, until now there has not been a very good systems programming language that allowed you to stay lean on memory without introducing any performance overhead. Rust is certainly a contender, thankfully. So, there is a perfectly good reason C is still prevalent to this day, even if there are many security implications in doing so.

chime 12y ago
I wonder how big of a project would it be to port all of GNU/Linux to Rust. Here's a start: https://news.ycombinator.com/item?id=7882211 https://news.ycombinator.com/item?id=7882211 https://github.com/uutils/coreutils/tree/master/src https://github.com/uutils/coreutils/tree/master/src
- hsivonen 12y ago
  I hope fundamental pieces of GNU/Linux system can start migrating to Rust without the FSF objecting to rutsc using LLVM.
  - rhelmer 12y ago
    I wonder if there'd be less friction to porting a BSD - FreeBSD already uses clang to build the kernel+userland, for instance.
- pmoriarty 12y ago
  I'd rather see it ported to Scheme.
  - easytiger 12y ago
    And then see it fall into disrepair and disuse because it becomes unmaintainable. LISP is 50 years old. If it was going to become useful for high performance software in large scale distributed teams of development, it would have happened already.
    - qu1j0t3 12y ago
      Wow, what an extraordinarily ignorant and obtuse remark. Way to go HN!
      - easytiger 12y ago
        Please kindly explain where it falls down specifically. Very happy to be wrong should I be missing sometihng.
        tarpherder 12y ago
        No no, you are mistaken. His reply is a special one. See, it not only refers to your reply, but it refers to itself as well! It's amazingly efficient, no need to respond to it any further!
lazyjones 12y ago
> The problem is, until now there has not been a very good systems programming language that allowed you to stay lean on memory without introducing any performance overhead. Rust is certainly a contender, thankfully. We've only had Pascal and Modula-2 for what, 40-45 years? >perfectly good reason C is still prevalent to this day ... it's not that and it's not good. It's just that security implications were largely ignored, people were lazy and innovation and making sound decisions (rather than popular ones) has never been strong in the OSS/Linux community (apart from the kernel itself).
- akira2501 12y ago
  http://www.lysator.liu.se/c/bwk-on-pascal.html http://www.lysator.liu.se/c/bwk-on-pascal.html It's a hobby horse by this point, but it makes it clear that the Pascal of 30 years ago is not the Pascal of today. The same can be said of C. These languages have evolved to be where they are today, mostly because hardware has evolved to be where it is today. Castigating past decisions as laziness really seems to be ignorant of this process, what it involved, and why it was necessary to make the decisions that we have up until now. Engineering, on the whole, is the art of compromise.
  - pjmlp 12y ago
    > April 2, 1981 USCD Pascal was created in 1978, Mesa in the mid-70s and Algol in 1968. Most of the complaints don't apply to them.
    - cbd1984 12y ago
      > UCSD Pascal bwk's point, then as now, was that once you deviated from Standard Pascal, you had to either bet on a specific horse in the non-standard Pascal race, or develop your own Pascal-like language with its own inherent defects, similar to but different from the defects of Standard Pascal and other Pascal-like languages. Your code would likely never interoperate with anyone else's Pascal variant. C, which had one de facto standard implementation and less genetic drift (because the standards, first K&R and then ANSI and ISO, were never as terrible as Standard Pascal's definition), didn't suffer from this nearly as much. Mesa didn't, either, but only because it was fairly obscure, and there sure were a lot of Foogols running around for a while, of which Pascal and its semi-clones formed only one family.
pjmlp 12y ago
You mean the myth that C was the first systems programming language, ignoring the fact that its designers just decided to ignore what was being done since the early 60's?
- cbd1984 12y ago
  OK, how about this: C was the first portable, non-assembly language used for writing OS kernels. Is that true? And I mean portable in practice, not just in theory, and portable beyond one family of computers.
  - pjmlp 12y ago
    No. OS were already being written in BCPL, Algol, Algol W, Algol 68, PL/I, PL/M and many other languages, battling for a place in the podium of systems programming languages. C was tied to UNIX, just as the others were tied to the OS of their vendor. C only became portable after UNIX was available in a few American universities outside AT&T, some students decided to create workstations based on UNIX, while others started to develop C compilers, so that they could continue their work on other systems.
    - meowface 12y ago
      Didn't BCPL and Algol heavily influence C though? What features of BCPL or Algol or other, older languages that were ignored could have made C better?
      - pjmlp 12y ago
        BCPL not much. It was barely an high level assembler. Now Algol, it had: - Bounds checked arrays - Reference parameters to functions/procedures - Real strings (not the first version in 1960 though) - Explicit conversions Quote from Tony Hoare's ACM award article[1]: "A consequence of this principle is that every occurrence of every subscript of every subscripted variable was on every occasion checked at run time against both the upper and the lower declared bounds of the array. Many years later we asked our customers whether they wished us to provide an option to switch off these checks in the interests of efficiency on production runs. Unanimously, they urged us not to--they already knew how frequently subscript errors occur on production runs where failure to detect them could be disastrous. I note with fear and horror that even in 1980 language designers and users have not learned this lesson. In any respectable branch of engineering, failure to observe such elementary precautions would have long been against the law." [1]http://www.labouseur.com/projects/codeReckon/papers/The-Emperors-Old-Clothes.pdf http://www.labouseur.com/projects/codeReckon/papers/The-Empe...
yohanatan 12y ago
I think you are overlooking OCaml & Haskell (which can both be used skillfully to approach performance of C).
- kryptiskt 12y ago
  Haskell is great, but GHC's runtime system is 50000 lines of C.
  - thirsteh 12y ago
    Which is relatively inconsequential as long as there's a clear boundary between things that can be manipulated by a user and the C code. It'd be better if it wasn't C at all, sure, but, from a security perspective I'd take a language with a C runtime over a language where code has to be carefully written in a memory-safe manner any day.
  - zanny 12y ago
    GCC is written in C/C++. I don't think any of the compilers are dogfooding their language because its supposed to be reusing infrastructure. I'd hope an LLVM compiler for a language would eventually be dogfooded, though.
    - yohanatan 12y ago
      http://en.wikipedia.org/wiki/Bootstrapping_(compilers) http://en.wikipedia.org/wiki/Bootstrapping_(compilers) This is pretty much the first thing that everyone writes in their new programming language.
  - zanny 12y ago
    GCC is written in C/C++. I don't think any of the compilers are dogfooding their language because its supposed to be reusing infrastructure. I'd hope an LLVM compiler for a language would eventually be dogfooded, though.
- meowface 12y ago
  Are there examples of either OCaml or Haskell being used for systems programming? I know that algorithmically they can achieve pretty close performance, but I don't think support is that great for low-level operations.
marcosdumay 12y ago
Whatever. One can always write unsafe code. No matter in what language. A really secure language is almost worthless because there's so much it can't do. No, the problem comes from the other end. Strings should not be able to compromise a system. It only needs to read a user supplied file, and write to stdout. There's no reason for it to be allowed to exec a piece of code.
- meowface 12y ago
  Multiple factors are to blame. I agree this is dumb behavior here by strings, but if the ELF parsing code were to be written in a language like Rust, it's far less likely it would have a bug of this nature.
  - thirsteh 12y ago
    Rust... or pretty much any other language than C. C is scary from a security perspective because it is both incredibly easy to write code that has subtle but very serious bugs leading to e.g. arbitrary code execution, and it is easy to exploit those vulnerabilities.
  - maccard 12y ago
    So what you're saying is that the bugs from a piece of software written 20 years ago (roughly) can be solved by writing the program in a language that hasn't had a stable release yet? Sure there are better alternatives now, but what widespread, well known, portable language was available in the mid 90's that this could have been written in?
- thirsteh 12y ago
  You seem to be arguing against yourself. If 'strings' were written in a safe language, compromising the system would be extremely unlikely. Or are you seriously arguing that languages that are safer than C aren't Turing complete? There are plenty of memory-safe languages in which you can do nearly everything you'd do in C, and much, much safer. There's no reason whatsoever a program like 'strings' couldn't be written in a memory-safe language.
zem 12y ago
ATS is a definite contender too, especially once the high entry barrier issues are worked on a bit.

chime 12y ago

I wonder how big of a project would it be to port all of GNU/Linux to Rust. Here's a start: https://news.ycombinator.com/item?id=7882211 https://news.ycombinator.com/item?id=7882211 https://github.com/uutils/coreutils/tree/master/src https://github.com/uutils/coreutils/tree/master/src

hsivonen 12y ago
I hope fundamental pieces of GNU/Linux system can start migrating to Rust without the FSF objecting to rutsc using LLVM.
- rhelmer 12y ago
  I wonder if there'd be less friction to porting a BSD - FreeBSD already uses clang to build the kernel+userland, for instance.
pmoriarty 12y ago
I'd rather see it ported to Scheme.
- easytiger 12y ago
  And then see it fall into disrepair and disuse because it becomes unmaintainable. LISP is 50 years old. If it was going to become useful for high performance software in large scale distributed teams of development, it would have happened already.
  - qu1j0t3 12y ago
    Wow, what an extraordinarily ignorant and obtuse remark. Way to go HN!
    - easytiger 12y ago
      Please kindly explain where it falls down specifically. Very happy to be wrong should I be missing sometihng.
      - tarpherder 12y ago
        No no, you are mistaken. His reply is a special one. See, it not only refers to your reply, but it refers to itself as well! It's amazingly efficient, no need to respond to it any further!

lazyjones 12y ago

> The problem is, until now there has not been a very good systems programming language that allowed you to stay lean on memory without introducing any performance overhead. Rust is certainly a contender, thankfully. We've only had Pascal and Modula-2 for what, 40-45 years? >perfectly good reason C is still prevalent to this day ... it's not that and it's not good. It's just that security implications were largely ignored, people were lazy and innovation and making sound decisions (rather than popular ones) has never been strong in the OSS/Linux community (apart from the kernel itself).

akira2501 12y ago
http://www.lysator.liu.se/c/bwk-on-pascal.html http://www.lysator.liu.se/c/bwk-on-pascal.html It's a hobby horse by this point, but it makes it clear that the Pascal of 30 years ago is not the Pascal of today. The same can be said of C. These languages have evolved to be where they are today, mostly because hardware has evolved to be where it is today. Castigating past decisions as laziness really seems to be ignorant of this process, what it involved, and why it was necessary to make the decisions that we have up until now. Engineering, on the whole, is the art of compromise.
- pjmlp 12y ago
  > April 2, 1981 USCD Pascal was created in 1978, Mesa in the mid-70s and Algol in 1968. Most of the complaints don't apply to them.
  - cbd1984 12y ago
    > UCSD Pascal bwk's point, then as now, was that once you deviated from Standard Pascal, you had to either bet on a specific horse in the non-standard Pascal race, or develop your own Pascal-like language with its own inherent defects, similar to but different from the defects of Standard Pascal and other Pascal-like languages. Your code would likely never interoperate with anyone else's Pascal variant. C, which had one de facto standard implementation and less genetic drift (because the standards, first K&R and then ANSI and ISO, were never as terrible as Standard Pascal's definition), didn't suffer from this nearly as much. Mesa didn't, either, but only because it was fairly obscure, and there sure were a lot of Foogols running around for a while, of which Pascal and its semi-clones formed only one family.

pjmlp 12y ago

You mean the myth that C was the first systems programming language, ignoring the fact that its designers just decided to ignore what was being done since the early 60's?

cbd1984 12y ago
OK, how about this: C was the first portable, non-assembly language used for writing OS kernels. Is that true? And I mean portable in practice, not just in theory, and portable beyond one family of computers.
- pjmlp 12y ago
  No. OS were already being written in BCPL, Algol, Algol W, Algol 68, PL/I, PL/M and many other languages, battling for a place in the podium of systems programming languages. C was tied to UNIX, just as the others were tied to the OS of their vendor. C only became portable after UNIX was available in a few American universities outside AT&T, some students decided to create workstations based on UNIX, while others started to develop C compilers, so that they could continue their work on other systems.
  - meowface 12y ago
    Didn't BCPL and Algol heavily influence C though? What features of BCPL or Algol or other, older languages that were ignored could have made C better?
    - pjmlp 12y ago
      BCPL not much. It was barely an high level assembler. Now Algol, it had: - Bounds checked arrays - Reference parameters to functions/procedures - Real strings (not the first version in 1960 though) - Explicit conversions Quote from Tony Hoare's ACM award article[1]: "A consequence of this principle is that every occurrence of every subscript of every subscripted variable was on every occasion checked at run time against both the upper and the lower declared bounds of the array. Many years later we asked our customers whether they wished us to provide an option to switch off these checks in the interests of efficiency on production runs. Unanimously, they urged us not to--they already knew how frequently subscript errors occur on production runs where failure to detect them could be disastrous. I note with fear and horror that even in 1980 language designers and users have not learned this lesson. In any respectable branch of engineering, failure to observe such elementary precautions would have long been against the law." [1]http://www.labouseur.com/projects/codeReckon/papers/The-Emperors-Old-Clothes.pdf http://www.labouseur.com/projects/codeReckon/papers/The-Empe...

yohanatan 12y ago

I think you are overlooking OCaml & Haskell (which can both be used skillfully to approach performance of C).

kryptiskt 12y ago
Haskell is great, but GHC's runtime system is 50000 lines of C.
- thirsteh 12y ago
  Which is relatively inconsequential as long as there's a clear boundary between things that can be manipulated by a user and the C code. It'd be better if it wasn't C at all, sure, but, from a security perspective I'd take a language with a C runtime over a language where code has to be carefully written in a memory-safe manner any day.
- zanny 12y ago
  GCC is written in C/C++. I don't think any of the compilers are dogfooding their language because its supposed to be reusing infrastructure. I'd hope an LLVM compiler for a language would eventually be dogfooded, though.
  - yohanatan 12y ago
    http://en.wikipedia.org/wiki/Bootstrapping_(compilers) http://en.wikipedia.org/wiki/Bootstrapping_(compilers) This is pretty much the first thing that everyone writes in their new programming language.
- zanny 12y ago
  GCC is written in C/C++. I don't think any of the compilers are dogfooding their language because its supposed to be reusing infrastructure. I'd hope an LLVM compiler for a language would eventually be dogfooded, though.
meowface 12y ago
Are there examples of either OCaml or Haskell being used for systems programming? I know that algorithmically they can achieve pretty close performance, but I don't think support is that great for low-level operations.

marcosdumay 12y ago

Whatever. One can always write unsafe code. No matter in what language. A really secure language is almost worthless because there's so much it can't do. No, the problem comes from the other end. Strings should not be able to compromise a system. It only needs to read a user supplied file, and write to stdout. There's no reason for it to be allowed to exec a piece of code.

meowface 12y ago
Multiple factors are to blame. I agree this is dumb behavior here by strings, but if the ELF parsing code were to be written in a language like Rust, it's far less likely it would have a bug of this nature.
- thirsteh 12y ago
  Rust... or pretty much any other language than C. C is scary from a security perspective because it is both incredibly easy to write code that has subtle but very serious bugs leading to e.g. arbitrary code execution, and it is easy to exploit those vulnerabilities.
- maccard 12y ago
  So what you're saying is that the bugs from a piece of software written 20 years ago (roughly) can be solved by writing the program in a language that hasn't had a stable release yet? Sure there are better alternatives now, but what widespread, well known, portable language was available in the mid 90's that this could have been written in?
thirsteh 12y ago
You seem to be arguing against yourself. If 'strings' were written in a safe language, compromising the system would be extremely unlikely. Or are you seriously arguing that languages that are safer than C aren't Turing complete? There are plenty of memory-safe languages in which you can do nearly everything you'd do in C, and much, much safer. There's no reason whatsoever a program like 'strings' couldn't be written in a memory-safe language.

zem 12y ago

ATS is a definite contender too, especially once the high entry barrier issues are worked on a bit.