3 ms·

To be fair, the value of the features you cite are very dependent on the size of the team and the type of work being done. If you're throwing tons of engineers

To be fair, the value of the features you cite are very dependent on the size of the team and the type of work being done. If you're throwing tons of engineers, tests, and money at something--think aircraft or whatever--you're not relying on the language to be smarter than the programmer. And as for operating systems being written in C and failing, writing a general purpose, hardware agnostic operating system isn't exactly easy. This is not to say that C should be the systems language of choice, or even that C is easier or more stable to write operating systems; just that stuff will be buggy regardless. And I think your main complaint is stuff like OpenSSL and its vulnerabilities... I don't think I would blame the language there. I would blame age / inherited bugs / lack of testing (amazingly that's the case, but we don't live in a world that's too concerned with the common good). I agree with you for many, many use cases for a programmer these days... but only if you just contextualize all these assertions.

nickpsecurity 10y ago
"And as for operating systems being written in C and failing, writing a general purpose, hardware agnostic operating system isn't exactly easy." Wirth and Jurg did it in a year or two on custom hardware using Modula-2. They and thdir students repeatedly did it with Oberon variants. They were all safer and more reliable than earliest UNIX distro. Partly due go strong typing, interface checks, and GC's in later versions. Similarly OS's written with Modula-3 (Spin), Haskell (House), Java (JX), and Rust (Redox) moved fast since the languages reduced number of problems they had. Spin could even dynamically link M3 code into running kernel with type system preventing many crashes or vulnerabilities. Made for great acceleration of networking apps, etc.
- simondedalus 10y ago
  I know that the response I'm about to give makes a statement that is not falsifiable and very much has the form of "I can cart this out and think I'm right no matter WHAT you respond," but I still feel compelled to say... ...the point I'm making is absolutely not that building an OS is equally hard in all languages, and equally likely to be buggy. My point is that creating a general purpose OS that only gets its rigorous testing from getting put into production before the majority of its target hardware has even yet been developed... that's going to be buggy in all languages. Designing and running an OS on a known system with a few applications in mind can't really refute what I'm saying. I mean, I could of course be wrong. But I can't imagine a convincing counter-example that doesn't have for its evidence "largescale adoption on disparate systems." (there could be an in-principle reason that I'm wrong that I just don't understand, but this is the risk we take in having opinions)

nickpsecurity 10y ago

"And as for operating systems being written in C and failing, writing a general purpose, hardware agnostic operating system isn't exactly easy." Wirth and Jurg did it in a year or two on custom hardware using Modula-2. They and thdir students repeatedly did it with Oberon variants. They were all safer and more reliable than earliest UNIX distro. Partly due go strong typing, interface checks, and GC's in later versions. Similarly OS's written with Modula-3 (Spin), Haskell (House), Java (JX), and Rust (Redox) moved fast since the languages reduced number of problems they had. Spin could even dynamically link M3 code into running kernel with type system preventing many crashes or vulnerabilities. Made for great acceleration of networking apps, etc.

simondedalus 10y ago
I know that the response I'm about to give makes a statement that is not falsifiable and very much has the form of "I can cart this out and think I'm right no matter WHAT you respond," but I still feel compelled to say... ...the point I'm making is absolutely not that building an OS is equally hard in all languages, and equally likely to be buggy. My point is that creating a general purpose OS that only gets its rigorous testing from getting put into production before the majority of its target hardware has even yet been developed... that's going to be buggy in all languages. Designing and running an OS on a known system with a few applications in mind can't really refute what I'm saying. I mean, I could of course be wrong. But I can't imagine a convincing counter-example that doesn't have for its evidence "largescale adoption on disparate systems." (there could be an in-principle reason that I'm wrong that I just don't understand, but this is the risk we take in having opinions)