Do any proposed, or implemented languages fit in the same (enormous) niche as C, with the intention of being an alternative, while maintaining all the applicability to OS, high performance, embedded and other roles?
Share
Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
Do any proposed, or implemented languages fit in the same (enormous) niche as C, with the intention of being an alternative, while maintaining all the applicability to OS, high performance, embedded and other roles?
OSs were historically implemented in assembler. Later on development shifted to C, which initially was a sort of macro assembler.
Now most OSs are written mostly in C because it is pretty much only language which maintains some sort of assembler backward compatibility (e.g. one can map one to one lion share of the assembler found in the hardware specs into C). And libc is the primary interface – often is the only interface – between kernel and user-space. And yet the interface covers not everything: some things in kernel has to be accessed directly as no standard interface is (yet) provisioned. E.g. one has to use a C struct to pass parameters/retrieve results to/from ioctl.
That means that the use of C in application development is in greater part pushed by the simple fact that if you use C you get automatically access to all the features of kernel (OS) which is also written in C.
Only language which can somehow compete with C is the language which is based/compatible with C. The sole alternative known to me is the C++. In older times there were also relatively popular translators like p2c (Pascal to C): developer programs in one language, but the source code is automatically translated into C for compilation. But the translators were rather buggy and without knowledge of C often programs couldn’t be debugged. So if you have to know some C anyway, why bother with the translators.
I personally (and many other developers I’m sure) using various languages often stumbled upon the problem that the OS has a feature, but the language used doesn’t provide any facility to access it. That I think is the major deterrent factor for other language development. Even if you have bright a idea for a new language (which is likely to be incompatible with C, otherwise idea wouldn’t be that bright) you end up with the burden to reimplement interface to the pretty much whole OS (and various must-have application libraries).
As long as (1) C remain the sole language for system programming and (2) OS interfaces are still evolving, all non-C-compatible languages on the other side of fence, application development, would be at greater disadvantage.
P.S. Actually that is one of the molds I hope LLVM/clang might break. clang is implemented as a reusable library theoretically allowing to mix languages. E.g. main source file can be in one language (and parsed by one front-end), but the
#includes could be in C (and parsed by the clang).