9 ms·

There's something fundamentally wrong with still using unsafe languages for system software. C should have been buried decades ago, it's a toy language for sma

There's something fundamentally wrong with still using unsafe languages for system software. C should have been buried decades ago, it's a toy language for small pieces of code on isolated systems (and yes, I've written larger programs in C myself, 20 years ago). Nowdays, C should not even be considered safe for implementing interpreters and runtime systems for other languages. There are plenty of reasonably portable choices available (and no, don't use Java / anything JVM based). It can't be terribly hard to reimplement "strings" and similar software in a modern language without such deficiencies (i.e. plenty of ways to shoot oneself in the foot and overwrite the stack etc.).

meowface 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. 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.
kabdib 12y ago
Sure. I re-wrote strings a few years ago in C#, worked great. That was at Microsoft, and sadly the code can't be made public. I've done most of my OS-level hacking in C and a limited subset of C++. I think it works well down there, where resources can't be "magic" and it's really important to know what's going on (and you often have to tell the optimizer "hands off"). At higher levels, it's lunacy to be using C. I sure wouldn't write a compiler in one, for instance.
- kgabis 12y ago
  Compile times are important though and using low level language such as C can make a big difference.
  - bdamm 12y ago
    I'll happily lose 5% compile performance in exchange for a safe compiler. Unfortunately, writing a compiler in a safe language isn't enough to make it a safe compiler.
  - lomnakkus 12y ago
    Are you claiming that C is fast to compile? If compile speed mattered that much we'd all still be using Turbo Pascal/Borland Delphi, or perhaps more recently Go.
    - kgabis 12y ago
      No, what I meant is that a compiler written in C is likely to be faster than a compler written in other language, which is a good reason to write a compiler in C.
      - lomnakkus 12y ago
        Nah. What you usually want from a compiler is maintainability and correctness. There's also a grand tradition for dogfooding by writing the compiler for language X in language X. If you don't, then how do you know you're actually making progress?
tjohns 12y ago
Out of curiosity, what's the problem JVM-based languages as a safe choice? (I'm legitimately curious here.) It's certainly not the right solution for everything, but there are plenty of cases where I'd think it could be an excellent choice. Most of Android (except the kernel) is written in Java, as an example.
- kyllo 12y ago
  The most popular implementation of the JVM itself is written in C++. But more importantly, Java has experienced a multitude of serious security bugs over the years.
  - _delirium 12y ago
    I'm not a huge JVM fan, but the majority of the Java vulnerabilities are related to a very different threat model that many languages don't even purport to guard against: safely running code that you know may be directly written by an adversary. The Java SecurityManager is supposed to allow that by sandboxing code with limited permissions, but has had a number of bugs, some of which can be exploited to let malicious apps break out of the sandbox. That's bad for cases where you are actually relying on running potentially malicious code, like applets in browsers. But not too relevant to the case where you'd be considering whether to choose Java, C, or C++ for a desktop or server app. In that case, treating the app itself as potentially malicious is not a common threat model: people don't normally run C/C++ apps in a sandbox. Although I suppose with the rise of Docker that might start becoming plausible for certain apps, relying on some OS facilities rather than a VM to do the sandboxing.
    - snuxoll 12y ago
      There's already been multiple security vulnerabilities in Docker, and likely there will continue to be more in the future. Virtualization and sanboxing is hard!
  - pjmlp 12y ago
    >The most popular implementation of the JVM itself is written in C++. The amount of C++code decreases with each release. For example, the version 8 of the OpenJDK had quite a few code rewritten in Java, thanks to the work introduced with invokedynamic. There are plans to eventually replace Hotspot with Graal and SubstrateVM, in some future version of the OpenJDK, thus reducing even more the C++ surface. This is why project Sumatra is using Graal and now jRuby is also playing with it.
userbinator 12y ago
The problem is that "safer" languages just encourages programmers that don't really think carefully about what they're doing because of the "the language is safe, it'll protect me from everything" effect. "Simple" bugs get hidden, programmers are encouraged to create more complex systems as a result, and the bugs thus created become even more subtle and difficult to find. Is it really so bloody hard to ensure that e.g. the fields of the executable header, if they're offsets, are actually valid values? I've written tools that work with PEs, many of them reading the entire file into a buffer first, and "make sure you're inside the file" was one of the points I always kept in mind. I say we need to fix how programmers think, not the language, because the same mindset that leads to bugs like these in "unsafe" languages will also lead to (maybe less severe, maybe more severe but also more subtle) bugs in "safe" languages too.
- enneff 12y ago
  > The problem is that "safer" languages just encourages programmers that don't really think carefully about what they're doing because of the "the language is safe, it'll protect me from everything" effect. "Simple" bugs get hidden, programmers are encouraged to create more complex systems as a result, and the bugs thus created become even more subtle and difficult to find. Citation needed. The plethora of over overcomplicated C code is a strong argument against this claim.
  - userbinator 12y ago
    The plethora of over overcomplicated C code is a strong argument against this claim. There certainly is plenty of overly complicated C code, but I doubt there is more of it than there is the amount of overly complicated code written in some of the other popular "safe" languages: Java and JavaScript.
    - enneff 12y ago
      These unsubstantiated claims are pointless.
- cgag 12y ago
pjmlp 12y ago
> (and no, don't use Java / anything JVM based). Why not? There are meta-circular implementations of Java, with native code generation on their toolchains. Even OpenJDK is going to get a AOT compiler as discussed on JVM Language Summit 2014.
tomjen3 12y ago
Counterpoint: All the rails security exploits, python pickling and sql injection issues. It is common to blame C for being unsafe but the real issue seems to be trusting user input, without sanitising it first. You could use a typed language to enforce sanitising by having a special type for user input (whether read from a file or received from the system) and have the converters sanitise it.
bhaak 12y ago
What are your arguments against Java? If you are disregarding Java when you are looking for portable options, then you are IMHO limiting yourself quite a bit and could be missing out on a good solution to your problem.
- lazyjones 12y ago
  For software like "strings"? Startup times and memory footprint/performance due to JIT compilation / the JVM, as well as the notorious complexity and bugginess of the runtime. Just consider the frequent updates and incompatibilities you'd get with it - for example, we had plenty of Java-based remote management GUIs which wouldn't run on newer Java runtime versions. Maybe with the (limiting) static compilation options available for Java it'd make more sense.

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

kabdib 12y ago

Sure. I re-wrote strings a few years ago in C#, worked great. That was at Microsoft, and sadly the code can't be made public. I've done most of my OS-level hacking in C and a limited subset of C++. I think it works well down there, where resources can't be "magic" and it's really important to know what's going on (and you often have to tell the optimizer "hands off"). At higher levels, it's lunacy to be using C. I sure wouldn't write a compiler in one, for instance.

kgabis 12y ago
Compile times are important though and using low level language such as C can make a big difference.
- bdamm 12y ago
  I'll happily lose 5% compile performance in exchange for a safe compiler. Unfortunately, writing a compiler in a safe language isn't enough to make it a safe compiler.
- lomnakkus 12y ago
  Are you claiming that C is fast to compile? If compile speed mattered that much we'd all still be using Turbo Pascal/Borland Delphi, or perhaps more recently Go.
  - kgabis 12y ago
    No, what I meant is that a compiler written in C is likely to be faster than a compler written in other language, which is a good reason to write a compiler in C.
    - lomnakkus 12y ago
      Nah. What you usually want from a compiler is maintainability and correctness. There's also a grand tradition for dogfooding by writing the compiler for language X in language X. If you don't, then how do you know you're actually making progress?

tjohns 12y ago

Out of curiosity, what's the problem JVM-based languages as a safe choice? (I'm legitimately curious here.) It's certainly not the right solution for everything, but there are plenty of cases where I'd think it could be an excellent choice. Most of Android (except the kernel) is written in Java, as an example.

kyllo 12y ago
The most popular implementation of the JVM itself is written in C++. But more importantly, Java has experienced a multitude of serious security bugs over the years.
- _delirium 12y ago
  I'm not a huge JVM fan, but the majority of the Java vulnerabilities are related to a very different threat model that many languages don't even purport to guard against: safely running code that you know may be directly written by an adversary. The Java SecurityManager is supposed to allow that by sandboxing code with limited permissions, but has had a number of bugs, some of which can be exploited to let malicious apps break out of the sandbox. That's bad for cases where you are actually relying on running potentially malicious code, like applets in browsers. But not too relevant to the case where you'd be considering whether to choose Java, C, or C++ for a desktop or server app. In that case, treating the app itself as potentially malicious is not a common threat model: people don't normally run C/C++ apps in a sandbox. Although I suppose with the rise of Docker that might start becoming plausible for certain apps, relying on some OS facilities rather than a VM to do the sandboxing.
  - snuxoll 12y ago
    There's already been multiple security vulnerabilities in Docker, and likely there will continue to be more in the future. Virtualization and sanboxing is hard!
- pjmlp 12y ago
  >The most popular implementation of the JVM itself is written in C++. The amount of C++code decreases with each release. For example, the version 8 of the OpenJDK had quite a few code rewritten in Java, thanks to the work introduced with invokedynamic. There are plans to eventually replace Hotspot with Graal and SubstrateVM, in some future version of the OpenJDK, thus reducing even more the C++ surface. This is why project Sumatra is using Graal and now jRuby is also playing with it.

userbinator 12y ago

The problem is that "safer" languages just encourages programmers that don't really think carefully about what they're doing because of the "the language is safe, it'll protect me from everything" effect. "Simple" bugs get hidden, programmers are encouraged to create more complex systems as a result, and the bugs thus created become even more subtle and difficult to find. Is it really so bloody hard to ensure that e.g. the fields of the executable header, if they're offsets, are actually valid values? I've written tools that work with PEs, many of them reading the entire file into a buffer first, and "make sure you're inside the file" was one of the points I always kept in mind. I say we need to fix how programmers think, not the language, because the same mindset that leads to bugs like these in "unsafe" languages will also lead to (maybe less severe, maybe more severe but also more subtle) bugs in "safe" languages too.

enneff 12y ago
> The problem is that "safer" languages just encourages programmers that don't really think carefully about what they're doing because of the "the language is safe, it'll protect me from everything" effect. "Simple" bugs get hidden, programmers are encouraged to create more complex systems as a result, and the bugs thus created become even more subtle and difficult to find. Citation needed. The plethora of over overcomplicated C code is a strong argument against this claim.
- userbinator 12y ago
  The plethora of over overcomplicated C code is a strong argument against this claim. There certainly is plenty of overly complicated C code, but I doubt there is more of it than there is the amount of overly complicated code written in some of the other popular "safe" languages: Java and JavaScript.
  - enneff 12y ago
    These unsubstantiated claims are pointless.
cgag 12y ago

pjmlp 12y ago

> (and no, don't use Java / anything JVM based). Why not? There are meta-circular implementations of Java, with native code generation on their toolchains. Even OpenJDK is going to get a AOT compiler as discussed on JVM Language Summit 2014.

tomjen3 12y ago

Counterpoint: All the rails security exploits, python pickling and sql injection issues. It is common to blame C for being unsafe but the real issue seems to be trusting user input, without sanitising it first. You could use a typed language to enforce sanitising by having a special type for user input (whether read from a file or received from the system) and have the converters sanitise it.

bhaak 12y ago

What are your arguments against Java? If you are disregarding Java when you are looking for portable options, then you are IMHO limiting yourself quite a bit and could be missing out on a good solution to your problem.

lazyjones 12y ago
For software like "strings"? Startup times and memory footprint/performance due to JIT compilation / the JVM, as well as the notorious complexity and bugginess of the runtime. Just consider the frequent updates and incompatibilities you'd get with it - for example, we had plenty of Java-based remote management GUIs which wouldn't run on newer Java runtime versions. Maybe with the (limiting) static compilation options available for Java it'd make more sense.