>Because we should move away from languages that are designed for security exploits.
Are you seriously claiming that C was designed for security exploits?
>Lets not forget how many security exploits we have to thank C for exactly this mis-feature.
No actually we have to thank sloppy and/or naive programmers. The C language is clear in that it doesn't hold your hand.
>The Native Oberon and Blue Bottle operating systems were even used for several years as desktop systems at ETHZ.
You can write an operating system in lots of languages besides C (and it has been done aswell), yet all the operating systems/kernels in wide use these days are all mainly written in C or a combination of C/C++.
That you can write an operating system in language X is nothing new, the performance you get with language X however is. We've seem numerous 'safe language' operating system attempts which have died due to inactivity or as in Singularity's case been passed off to academia because MIcrosoft realised it had no commercial relevance.
>The only area where I concede it is hard to replace C is in embedded space, specially if we consider many developers are still using Assembly.
I disagree, in everything where performance and/or footprint is paramount there will be a need for languages such as C, as always there is room for competition but Go certainly isn't a candidate in my opinion. I haven't really looked into Rust yet, D on the other hand seems to have gained zero traction and is from what I gather primarily positioning itself against C++.
>> Lets not forget how many security exploits we have to thank C for exactly this mis-feature.
> No actually we have to thank sloppy and/or naive programmers. The C language is clear in that it doesn't hold your hand.
While it is true that security exploits come from sloppy, naive, hasty developers, we should also remember that even the programmers of projects such as OpenBSD are not immune to C's pitfalls. This is why I think that it's so interesting when languages try to achieve what C does, while also making it more likely that a programmer who's tired or distracted can't actually get incorrect code to compile. Besides the usual D, Go and Rust that are mentioned, I should say that the language Clay is another very interesting project and it's a shame that it does not get the amount of publicity these other alternatives get.
> You can write an operating system in lots of languages besides C (and it has been done aswell), yet all the operating systems/kernels in wide use these days are all mainly written in C or a combination of C/C++.
I don't know that it's really because of some functionality proper to C; I feel it's more of a familiarity issue. People have been implementing operating systems in C since the early 70's, there is a lot of documentation on the subject and C is widely known.
>I don't know that it's really because of some functionality proper to C
Performance which translates to low latency is of great importance in a operating system/kernel.
This extremely low latency is the result of optimizing at a very minute level, C allows this to be done while retaining a high level of portability and maintainability as opposed to assembly.
The extent to which this optimization is done is further highlighted by how the Linux kernel (and I assume other aswell) uses compiler extensions to further control the final generated code in order to maximize performance and minimize footprint. As such these compiler extensions allow for even further low level control which are outside that which the standard C language provides.
Kernel's and similar operating system components operate in a very low level problem domain, and C is a high level language which has shown itself particularly suitable in this context.
So I think that the wide use of C in low level and/or performance critical code such as that of kernels is based upon 'practicality' rather than 'familiarity'.
Even so, expert C programmers successfully writes all sorts of code.
Git for example doesn't strike me as a project with a larger amount of exploits or bugs than other similar software. And while lots of people have different views on it's 'ease-of-use', everyone seems to agree that Git is 'damn fast'.
> Are you seriously claiming that C was designed for security exploits?
As proven by Ken Thompson himself, with his compiler trick.
Joking aside, C requires expert programmers, which sadly seldom exist in the real world.
The only way to minimize the security exploits made possible by lack of bounds checking, arrays decaying into pointers, null terminated string without null characters, use after free(), sizeof operator incorrectly applied, ... Is to use languages that disalow these operations by default, only allowing them via a system/unsafe mechanism explicitly enabled by the developer.
C can be a good tool in the hands of experts that never do mistakes and are the Jedi masters of perfect coding. Sadly most companies tend to have average developers, not Jedi masters.
As such, C with its motto 'speed before security', makes almost impossible to write bug free code in the hands of such developers.
C requires a level of unassisted perfection that we spent forty years demonstrating nobody can attain. Every programmer is sloppy and naive in comparison. Tools that fail in human hands, shouldn't be.
>C requires a level of unassisted perfection that we spent forty years demonstrating nobody can attain.
So there is no exploit-free C code out there? It is just impossible to write C code without buffer overflow bugs?
>Tools that fail in human hands, shouldn't be.
If so why don't we throw out all programming languages? You can create buggy code with far-reaching implications in any sufficiently complex programming language, buffer overruns are but one type of bug.
And relating back to 'tools', we have lots of great tools at our disposal these days which can be automated to help identify possible vulnerabilities in our code. There really isn't a 'either you use a safe language or your code will by definition contain exploits' situation which some people try to paint.
It is genuinely difficult to find C code of any real complexity that hasn't had some kind of security flaw that would have been unlikely in a higher-level language. Even qmail managed to cough up an LP64 integer overflow. It took a long time for it to turn up. Generally, C code without at least one documented flaw makes me more worried than code with a known, fixed flaw.
Are you seriously claiming that C was designed for security exploits?
>Lets not forget how many security exploits we have to thank C for exactly this mis-feature.
No actually we have to thank sloppy and/or naive programmers. The C language is clear in that it doesn't hold your hand.
>The Native Oberon and Blue Bottle operating systems were even used for several years as desktop systems at ETHZ.
You can write an operating system in lots of languages besides C (and it has been done aswell), yet all the operating systems/kernels in wide use these days are all mainly written in C or a combination of C/C++.
That you can write an operating system in language X is nothing new, the performance you get with language X however is. We've seem numerous 'safe language' operating system attempts which have died due to inactivity or as in Singularity's case been passed off to academia because MIcrosoft realised it had no commercial relevance.
>The only area where I concede it is hard to replace C is in embedded space, specially if we consider many developers are still using Assembly.
I disagree, in everything where performance and/or footprint is paramount there will be a need for languages such as C, as always there is room for competition but Go certainly isn't a candidate in my opinion. I haven't really looked into Rust yet, D on the other hand seems to have gained zero traction and is from what I gather primarily positioning itself against C++.