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?
+6
A:
The obvious one is C++.
Does everything you describe, but extends C quite a bit with other features (Object Oriented, etc.).
Edan Maor
2010-07-27 09:22:28
C++ can't be used in most niches where currently used C.
vitaly.v.ch
2010-07-27 09:46:28
@vitaly: Whilst that's true, you've suggested Ada and Objective-C, which are an even worse fit that C++ !!!
Sean
2010-07-27 09:58:21
Michael Foukarakis
2010-07-27 10:08:18
2Sean: Ada can be used instead C practically in all situations, But c++ only sometimes. For example I ALWAYS can call any Ada code from C, but I can call C++ only if they match some rules.
vitaly.v.ch
2010-07-27 10:18:07
@vitaly.v.ch: C++ contains a sublanguage which is C with little differences (http://en.wikipedia.org/wiki/Compatibility_of_C_and_C%2B%2B). Most clean C source can be compiled with a C++ compiler and produces the same code. As a matter of fact, for most niches where C still plays a role, you'll find a C++ compiler as well (embedded, micro-controller)
Luther Blissett
2010-07-27 10:27:08
2Luther Blissett: C++ compiler does not generate same code as C compiler. For example code generated by C++ compiler cant be linked by system linker and MUST be linked via C++ linker.
vitaly.v.ch
2010-07-27 10:55:08
@vitaly.v.ch - I'm not sure what you mean. I worked for several years on embedded systems using C++. Granter, we didn't use things like the Standard Library, but you can use a lot of Object Oriented goodness on an embedded system. I don't have statistics but I guess it's not *that* uncommon, either.
Edan Maor
2010-07-27 11:05:07
@vitaly: Can you give an example where it can't be used? This would be most interesting. I'm only aware of linker and ABI differences, but if a subset is exposed to the linker, I understand that full C compatibility is maintained.
Matt Joiner
2010-07-27 14:03:50
+3
A:
Another interesting system programming language from Google: Go
Marimuthu Madasamy
2010-07-27 09:31:13
+1
A:
You could consider D. From the homepage:
D is a systems programming language. Its focus is on combining the power and high performance of C and C++ with the programmer productivity of modern languages like Ruby and Python. Special attention is given to the needs of quality assurance, documentation, management, portability and reliability.
The D language is statically typed and compiles directly to machine code. It's multiparadigm, supporting many programming styles: imperative, object oriented, and metaprogramming. It's a member of the C syntax family, and its appearance is very similar to that of C++.
Francesco
2010-07-27 09:34:25
+3
A:
ADA is probably the most widely used language in this space apart from C.
It is designed above all to produce reliable bug free code, but, most ADA compilers produce well optimised effiecient machine code as well.
For a while this language was compulsary for Department of Defence projects and it is still widly used in avaionics, radar, navigation and weapons control systems.
James Anderson
2010-07-27 09:39:20
Are you sure that ADA is more widely used than C++ on embedded systems? (I assume that's the space you were referring to).
Edan Maor
2010-07-27 11:06:06
I actually used Ada in a university course years ago. I always assumed it was dragged from its coffin where it was buried in the 80s. Looking on TIOBE it's #28. Pretty dead, but more alive than Fortran.
Matt Joiner
2010-07-27 14:05:28
James is correct. You won't find any modern aircraft with control software written in C.
manneorama
2010-07-27 14:56:46
It was mandatory for a very short time only. In fact the selection process to be a mandatory language took over five years but it was only mandatory for about two and was quickly displaced by C then C++ on most systems, but its still out there.
James Anderson
2010-07-28 01:01:04
+7
A:
There are quite a number of languages that were explicitly designed to fit all of that niche:
- BitC
- Cyclone
- Forth
- Mesa
- CPL
- BCPL (simplified version of CPL, implementation language of MULTICS)
- B (Ken Thompsons first try at a systems programming language, based loosely on BCPL, precursor to C)
- Ada
- Go
- D
- C++
- Modula-2 (specifically designed for the Lilith personal computer as a successor to Pascal for systems programming, also used by IBM as the implementation language for the original OS/400)
- Oberon (specifically designed as a simpler successor to Modula-2)
- Component Pascal (object-oriented successor to Oberon, despite the name it is not a direct successor to Pascal)
- Modula-3 (despite the name not a successor to Modula-2 but an independent development)
- Sing# (the implementation language of Microsoft Research's Singularity Research OS)
- Limbo (language for the Inferno operating system (successor to Plan 9 (successor to Unix)))
- Ooc
- Erlang (maybe not for operating systems, but embedded realtime systems, especially in the telco industry (phone switches etc.), also lately (somewhat surprising to Erlang's inventors, actually) web servers, databsase systems, etc.)
Interestingly, there are also a number of languages that were not specifically designed to fill that niche, but that have been very successfully used in that niche:
- Smalltalk (several Smalltalk OSs, embedded systems, microcontrollers, realtime systems, most famous: the Tektronix TDS500 series of digital oscilloscopes)
- Lisp (several Lisp OSs, embedded systems, microcontrollers, some NASA spacecraft)
- Java (several Java OSs (JNode, NewOS), embedded systems, microcontrollers, smartcards)
- C# (several OSs (Cosmos, SharpOS), Mono is used in High-Performance Computing)
- Haskell (the House OS, the seL4 verified microkernel)
- Pascal (MacOS)
There's also a lot of languages that have not yet been used in that niche, but that certainly could be. (Mostly that is because those language communities themselves have been so indoctrinated by the "you can only write operating systems in C" bullshit that they actually believe their own language to be unusable.)
- Ruby
- Python
- ECMAScript (which is actually used for writing high-performance webservers lately)
[Note that for each one of the three categories I listed there are literally thousands more languages that fit in there.]
In fact, one sometimes gets the feeling that languages which are not specifically designed for, say, operating system programming are actually better for that kind of thing. Compare, for example, the level of innovation, the stability, number of security holes, performance in something like a Smalltalk OS from the 1970s and Windows or OSX from 2010.
Personally, I believe that this is based on some deep-seated myths in the systems programming community. They believe that systems programming in a language with, say, strong typing, type safety, memory safety, pointer safety, automatic storage management is impossible and that the only way to get performance or realtime guarantees is to forego powerful abstraction facilities. However, it turns out that when you try to design a programming language for humans instead of machines, then humans can actually understand the programs they wrote, find security holes, fix bugs and locate and fix performance bottlenecks much better in a 1 line monad comprehension than in a 100 line for loop.
For example SqueakNOS, which is a variant of the Squeak Smalltalk system that runs without an OS (in other words: it is the OS) has pretty much all of the features that you would expect from a modern OS (graphical user interface, ...) plus some that you don't (embedded scripting language that can modify every single piece of the OS at runtime) and weighs in at just 300k SLOC and boots in less than 5 seconds while e.g. Windows weighs in at 50 million SLOC.
Jörg W Mittag
2010-07-27 10:09:36
Michael Foukarakis
2010-07-27 10:14:24
@vitaly.v.ch: Could you be a *tiny* bit more specific? Which languages, precisely, are "most of them"? What does "replace C" mean? Which, precisely, are "most cases"? The OP specifically mentioned "OS, high performance, embedded" and I made sure that every single language I listed has been used in all three of those fields.
Jörg W Mittag
2010-07-27 10:40:33
Seconded, Jörg. Most of those languages very much *can* replace C in most cases. Ada in particular has been used to fill exactly the same niche as C for decades. B is no longer really used, but was the basis for C. Go is specifically designed to supplant C. As was D. By the way, Objective C is missing from the list. It's a strict superset of C (unlike C++) and the iPhone certainly counts as a resource constrained embedded device these days.
Nathon
2010-07-27 10:56:18
2Jörg W Mittag: I can freely use C in embedded systems with 1024 bytes of RAM or even with 0 bytes. Also for that systems I can use Ada, but no other one from your list.
vitaly.v.ch
2010-07-27 11:03:48
It's a long list. When I get time to read all the great links and languages listed, this might be a winner.
Matt Joiner
2010-07-27 14:08:51
Nice answer until i got to the last part - the comparisons of 1970s OS' and small, more educational projects, with todays molochs of operating systems isn't a fair one. Also performance matters a lot for most layers and especially that languages that are more dynamic just don't cut it.
Georg Fritzsche
2010-08-04 00:48:34
Wait... Python can be used to write an operating system? Like one that you can put on a disk, insert into an old computer, install and run?
jcao219
2010-08-06 16:38:54
+1
A:
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).
Dummy00001
2010-07-27 10:16:23
As long as a language implements an interface to the C ABI, there's no OS feature (in OSs written in C) that can't be accessed. See: Python.
Nathon
2010-07-27 10:59:12
You have a great point. Nathan I think he refers to the inconvenience of obtaining or creating C bindings for various languages. It's a HUGE deterrent, especially when you want to get nitty-gritty with OS features.
Matt Joiner
2010-07-27 14:10:56
@Nathon, @Matt: yes, that was my point. Python (and many other languages) has to invest extra time to access C APIs. E.g. in case of Python, one has still to do extra work (like making memory management compatible: reference counting, garbage collection, etc) to be able to access the APIs. http://docs.python.org/release/2.5.2/ext/intro.html
Dummy00001
2010-07-27 14:50:36