After All These Years, the World Is Still Powered by C Programming(tekhinnovation.blogspot.com)
tekhinnovation.blogspot.com
After All These Years, the World Is Still Powered by C Programming
http://tekhinnovation.blogspot.com/2017/03/after-all-these-years-world-is-still.html?m=1
14 comments
And C++ is used in so many places on top of that. Every web browser is written in C++. Most GUI systems are written in C++ (or Objective C). All gaming engines are written in C++, etc.
It's also my understanding that the LLVM, GNU, and Microsoft C compilers are technically (1) all written in C++. It's also my experience that larger embedded projects also tend to be C++. So maybe your microwave is written in C, but your car's control systems are probably C++, at least in the new parts.
(1) So the gcc codebase is almost entirely C but it is compiled as C++. Someone else might be able to explain exactly what features of C++ made this an attractive option . My intuition tells me it has to do with better compiler diagnostics, perhaps involving type checking. I'm on mobile or I would research and provide more authoritative sources.
(1) So the gcc codebase is almost entirely C but it is compiled as C++. Someone else might be able to explain exactly what features of C++ made this an attractive option . My intuition tells me it has to do with better compiler diagnostics, perhaps involving type checking. I'm on mobile or I would research and provide more authoritative sources.
Taylor's slides list the reasons to commit to writing GCC in C++:
C++ is well-known and popular.
It's nearly a superset of C90, which GCC was then written in.
The C subset of C++ is as efficient as C.
C++ "supports cleaner code in several significant cases." It never requires "uglier" code.
C++ makes it harder to break interface boundaries, which leads to cleaner interfaces.
https://lwn.net/Articles/542457/
C++ is well-known and popular.
It's nearly a superset of C90, which GCC was then written in.
The C subset of C++ is as efficient as C.
C++ "supports cleaner code in several significant cases." It never requires "uglier" code.
C++ makes it harder to break interface boundaries, which leads to cleaner interfaces.
https://lwn.net/Articles/542457/
> It never requires "uglier" code.
Again, I mostly agree with everything you wrote, but this is overstating things a little. Because exception safety can be a little more complicated than it first appears, you do end up having to do a bit more work in C++ in certain cases.
One example of this is writing an external ABI in C++. Depending on how nice you want to be to the consumer of your ABI, you might need to add a try...catch(...) to every public function to make sure exceptions don't escape the C++ code. There are also tricky subtleties around writing, say, a swap function in the face of constructors that might throw.
Again, I mostly agree with everything you wrote, but this is overstating things a little. Because exception safety can be a little more complicated than it first appears, you do end up having to do a bit more work in C++ in certain cases.
One example of this is writing an external ABI in C++. Depending on how nice you want to be to the consumer of your ABI, you might need to add a try...catch(...) to every public function to make sure exceptions don't escape the C++ code. There are also tricky subtleties around writing, say, a swap function in the face of constructors that might throw.
You can write exception free code since C++11. All you must do is to add noexcept operator at the end of your function that you don't want to throw an exception and that would do.
Also, in the article it states that cars are using C. If I'm not mistaken, Bjarne himself in a couple of videos he has mentioned certain companies, like BMW and Mercedes, are using C++ for their cars and of course these two companies are not the only ones.
The good thing is that C++ committee did pay attention to what people and companies have suggested and or complained for years and fixed it with the release of C++11.
I really love using C myself, but I wish C had the safety C++ has by default.
Also, in the article it states that cars are using C. If I'm not mistaken, Bjarne himself in a couple of videos he has mentioned certain companies, like BMW and Mercedes, are using C++ for their cars and of course these two companies are not the only ones.
The good thing is that C++ committee did pay attention to what people and companies have suggested and or complained for years and fixed it with the release of C++11.
I really love using C myself, but I wish C had the safety C++ has by default.
>One example of this is writing an external ABI in C++. Depending on how nice you want to be to the consumer of your ABI, you might need to add a try...catch(...) to every public function to make sure exceptions don't escape the C++ code.
That's not "required" if you write the C++ code yourself though, as you can just refrain from using (throwing) exceptions in the first place.
That's what the parent means.
That's not "required" if you write the C++ code yourself though, as you can just refrain from using (throwing) exceptions in the first place.
That's what the parent means.
One can use a compiler switch to disable exceptions in every popular C++ compiler.
>The C subset of C++ is as efficient as C.
this.
this.
The comparison to C++ with respect to exceptions is a bit misrepresented. In platforms where size/perf matters they are turned off at the compiler level(along with RTTI). This was always the first thing we did in gamedev right after turning on W4.
Overall decent article though.
Overall decent article though.
Immediately thought of this https://pastebin.com/UAQaWuWG and the accompanying discussion https://news.ycombinator.com/item?id=12312623
Isn't a big part of its allure that it is "close to the metal"? When learning assembly language programming in the '80s, I would write a bit of C, and compile to assembly. It was very easy to mentally map from the one to the other.
This is harder today due to optimizations, but if you also understand those, you can do it.
That I get. I doubt this would work today. Even a simple program would generate reams of "boilerplate" and a reasonably complex program would probably leverage branch look-ahead and other optimizations.
Still, the thing is, I really don't buy into any arguments in favor of starting a new project, in C, today. The problem is that C suffers from some really serious disadvantages as a systems programming language, and it has no significant advantages over C++ or Rust, apart from subjective ideas like "it's simpler" or circumstantial issues like "my team doesn't know C++".
Firstly, apart from a simple call stack, C has no automatic resource management. There are no automatic destructors. Thus it is too easy to forget to free some memory or unlock a mutex or decrement a ref count or whatever, especially when many code paths are possible after a resource has been allocated. The other options are to use the "goto cleanup" or "goto err" idiom, which is still way more error prone than automatic destructors.
And secondly, despite being touted as so "efficient", C offers no way to write code that is both generic and free of runtime overhead, apart from preprocessor macros (which are filled with their own issues), or automatic code generation scripts. Both C++ and Rust have metaprogramming facilities which provide the ability to write generic code without sacrificing performance or maintainability.
I mean, with C++, the automatic deterministic allocation/destruction alone is worth using it over C. And all of the downsides (larger binaries, etc.) can be overcome without much effort. I concede that the extra language complexity of C++ over C could be a disadvantage, but in my mind that doesn't outweigh the benefits.
Firstly, apart from a simple call stack, C has no automatic resource management. There are no automatic destructors. Thus it is too easy to forget to free some memory or unlock a mutex or decrement a ref count or whatever, especially when many code paths are possible after a resource has been allocated. The other options are to use the "goto cleanup" or "goto err" idiom, which is still way more error prone than automatic destructors.
And secondly, despite being touted as so "efficient", C offers no way to write code that is both generic and free of runtime overhead, apart from preprocessor macros (which are filled with their own issues), or automatic code generation scripts. Both C++ and Rust have metaprogramming facilities which provide the ability to write generic code without sacrificing performance or maintainability.
I mean, with C++, the automatic deterministic allocation/destruction alone is worth using it over C. And all of the downsides (larger binaries, etc.) can be overcome without much effort. I concede that the extra language complexity of C++ over C could be a disadvantage, but in my mind that doesn't outweigh the benefits.
I mostly agree, but C compiles in terms of a binary interface, which makes it unique in it's ability to provide language agnostic libraries.
You can do that in C++, but by wrapping your C++ in C, more or less. Rust might provide a compelling alternative here eventually, but it's still a young language.
You can do that in C++, but by wrapping your C++ in C, more or less. Rust might provide a compelling alternative here eventually, but it's still a young language.
Providing no stable ABI and not being easy to bind to in general is really a major pain point of C++ for library/framework code. In contrast everyone and their dog is able to call into C in practice which is, I assume, a not to be underestimated reason why it is still so popular, even for code not leveraging its low level nature. Rust is really interesting here as they have chosen to make it more than an afterthought to provide compatibility.
> I concede that the extra language complexity of C++ over C could be a disadvantage, but in my mind that doesn't outweigh the benefits.
It's a problem, C++ is so insanely complex, full of magic which is hard to grasp and provides more ways to shoot yourself in the foot than to do it right (modern C++ seems better in some regards but still…). C is often chosen because people want sth. reasonable simple so I think a language fitting in between, being richer than C but still fairly comprehensible would be nice.
> I concede that the extra language complexity of C++ over C could be a disadvantage, but in my mind that doesn't outweigh the benefits.
It's a problem, C++ is so insanely complex, full of magic which is hard to grasp and provides more ways to shoot yourself in the foot than to do it right (modern C++ seems better in some regards but still…). C is often chosen because people want sth. reasonable simple so I think a language fitting in between, being richer than C but still fairly comprehensible would be nice.
The size of a C++ binary file that has been constructed with a modern, up to date compiler can produce the same size as that of C.
I have tested this a year ago with both clang and GCC, and the optimized, stripped down binaries were identical in size.
I have tested this a year ago with both clang and GCC, and the optimized, stripped down binaries were identical in size.
Hello,
I wrote an article about the other side of the coin, the problems I have with a world powered by C.
https://www.linkedin.com/pulse/c-must-retire-sinan-akpolat?p...
I don't want to compare C to another language. I just think that C is old.
I wrote an article about the other side of the coin, the problems I have with a world powered by C.
https://www.linkedin.com/pulse/c-must-retire-sinan-akpolat?p...
I don't want to compare C to another language. I just think that C is old.
cowardlydragon, your comment is marked [dead], so most won't see it. That's unfortunate because it's pretty good.
[deleted]
C and C++ are in use but it has become easier than ever to bridge in higher-level languages. It is also hard to code sanely on a large project without a higher-level language.
Not every line of a program must be ultra-fast, and maintainability is still huge. If you are not offloading the less-critical parts of your project to languages that are easier to program in than C++, you are doing it wrong.
Not every line of a program must be ultra-fast, and maintainability is still huge. If you are not offloading the less-critical parts of your project to languages that are easier to program in than C++, you are doing it wrong.
It would have been a nice article but there's just too much ridiculous hype in it.
I'm not saying C is a shitty language or anything, but the reality is that the only reason why C is still around is the long history it has and the dominant position it used to have.
I'm not saying C is a shitty language or anything, but the reality is that the only reason why C is still around is the long history it has and the dominant position it used to have.
Not really. With the exception of rust, you can't match the speed of C short of writing assembly. When you start a project you must decide what is important to you, and if speed is the number one issue, topically you use C. Many, many new projects start with C, mainly because so many of the fast libraries are written in C.
If you've already worked out the algorithm, it will be difficult to improve upon C unless you write in assembly language.
However, if you haven't, you'll be able to write and debug it a lot faster by writing it in Java, Python, Lisp, or some other high level language instead. Most, and larger, performance improvements are obtained through discovering better algorithms, and you'll find it easier, and have more time, if you write it in a high level language, because you won't have to worry about manual memory management, array overflows, and all the other problems you often run into when programming in C. So after development time constraints are taken into account, many programs in higher level languages will often run faster than equivalent C programs.
The things that matter most are development and maintenance time, and response times, not overall run time. Compared to high level languages, C increases the first two and has little effect upon the third. Decades ago, people were happily using computers thousands of times slower.
However, if you haven't, you'll be able to write and debug it a lot faster by writing it in Java, Python, Lisp, or some other high level language instead. Most, and larger, performance improvements are obtained through discovering better algorithms, and you'll find it easier, and have more time, if you write it in a high level language, because you won't have to worry about manual memory management, array overflows, and all the other problems you often run into when programming in C. So after development time constraints are taken into account, many programs in higher level languages will often run faster than equivalent C programs.
The things that matter most are development and maintenance time, and response times, not overall run time. Compared to high level languages, C increases the first two and has little effect upon the third. Decades ago, people were happily using computers thousands of times slower.
Fortran, Ada, D? I guess D is out because of the garbage collector, and I've not heard of Fortran being used as a systems language, but it's certainly performant with C.
However, OSes have been written in Lisp, and it has been used for embedded programming, so it's possible to make a language with more abstractions available similarly performant.
However, OSes have been written in Lisp, and it has been used for embedded programming, so it's possible to make a language with more abstractions available similarly performant.
> However, OSes have been written in Lisp, and it has been used for embedded programming, so it's possible to make a language with more abstractions available similarly performant.
The right abstractions even increase the possibilities for optimization a lot, not hinder it. The fact that C is fast and often faster than others is simply due to its decades lasting popularity and the work which was put into compilers over the time.
The right abstractions even increase the possibilities for optimization a lot, not hinder it. The fact that C is fast and often faster than others is simply due to its decades lasting popularity and the work which was put into compilers over the time.
>However, OSes have been written in Lisp, and it has been used for embedded programming, so it's possible to make a language with more abstractions available similarly performant.
You can use anything for writing an OS or an embedded program, if you expand the scope of what people consider an OS or an embedded program.
While OSes have been written in Lisp, no mainstream OS people actually use has. Experimental research OSes don't really count. People have written such things in all kinds of languages, even Java.
And while you can use whatever language for "embedded" programming, actual in-the-trenches embedded programming is done mostly in C, in chips and specs where those other languages wouldn't really fit or be performant enough.
You can use anything for writing an OS or an embedded program, if you expand the scope of what people consider an OS or an embedded program.
While OSes have been written in Lisp, no mainstream OS people actually use has. Experimental research OSes don't really count. People have written such things in all kinds of languages, even Java.
And while you can use whatever language for "embedded" programming, actual in-the-trenches embedded programming is done mostly in C, in chips and specs where those other languages wouldn't really fit or be performant enough.
> if you expand the scope of what people consider an OS
You mean expand it beyond "currently mainstream OS with a big installed base" rather than in any technical sense.
> While OSes have been written in Lisp, no mainstream OS people actually use has. Experimental research OSes don't really count. People have written such things in all kinds of languages, even Java.
Lisp machines were shipping production hardware.
Who has shipped hardware programmed in nothing but Java? Java code taking interrupts, programming DMA controllers, managing memory, etc.
You mean expand it beyond "currently mainstream OS with a big installed base" rather than in any technical sense.
> While OSes have been written in Lisp, no mainstream OS people actually use has. Experimental research OSes don't really count. People have written such things in all kinds of languages, even Java.
Lisp machines were shipping production hardware.
Who has shipped hardware programmed in nothing but Java? Java code taking interrupts, programming DMA controllers, managing memory, etc.
>You mean expand it beyond "currently mainstream OS with a big installed base" rather than in any technical sense.
Well, the technical sense ("to boot some hardware and coordinate some processes") is too low a barrier.
It's all the other stuff, managing memory efficiently, making the most of software, being fast to make it worthy to run it, making the battery last, etc, being a good server, etc, that make an OS an OS and not a research vehicle/toy/expensive niche workstation (like the LISP machines).
Well, the technical sense ("to boot some hardware and coordinate some processes") is too low a barrier.
It's all the other stuff, managing memory efficiently, making the most of software, being fast to make it worthy to run it, making the battery last, etc, being a good server, etc, that make an OS an OS and not a research vehicle/toy/expensive niche workstation (like the LISP machines).
> to boot some hardware and coordinate some processes is too low a barrier.
No it obviously isn't. If it boots and coordinates processes, it's an OS.
> expensive niche workstation
In the Lisp machine era, anything that actually had a "real OS" was an expensive workstation (or mini, mainframe, etc).
Affordable consumer machines had software most examples of which didn't control processes, yet was still called some kind of OS: MS-DOS, Mac OS, and the like.
No it obviously isn't. If it boots and coordinates processes, it's an OS.
> expensive niche workstation
In the Lisp machine era, anything that actually had a "real OS" was an expensive workstation (or mini, mainframe, etc).
Affordable consumer machines had software most examples of which didn't control processes, yet was still called some kind of OS: MS-DOS, Mac OS, and the like.
[deleted]
Symbolics Lisp Machines were widely used in graphics and animation. TV stations and animation studios were using them.
Real power end users.
Animations created with the Symbolics Lisp Machine:
https://youtube.com/watch?v=hXVBY2mGMN0
Animations created with the Symbolics Lisp Machine:
https://youtube.com/watch?v=hXVBY2mGMN0
Those are fair points, but I was mostly focusing on languages that are still widely used. Fortan seems to be used the most of the three, and I rarely see it outside of niche scientific applications.
You can write D without using the garbage collector, or more pragmatically disable it or have threads doing work that are not registered with the GC. Some standard library functions require the GC, but a diminishing number, and you are no worse off than writing pure C. Just stick @nogc on the relevant code and it won't compile if you use the GC by mistake. Also, D generates less garbage than some other languages when written idiomatically, as you pass structs on the stack.
That's an awfully big "only" there... Basically you're saying that C is still winning because of the historically unmatched ecosystem of tooling and libraries and platforms and technologies and research areas, and the attendant uncounted millions of developer minds who are expert in all of that.
Well, yeah.
It's not enough for rust (I'm assuming this is all about rust, but you can insert your own favorite and the argument still holds) to be a better language to have done all this stuff in. It needs to be the technology in which it was actually done. Get crackin', basically.
Well, yeah.
It's not enough for rust (I'm assuming this is all about rust, but you can insert your own favorite and the argument still holds) to be a better language to have done all this stuff in. It needs to be the technology in which it was actually done. Get crackin', basically.
>the reality is that the only reason why C is still around is the long history it has and the dominant position it used to have.
Those are not idle historical reasons.
They actively translate in important benefits that other languages lack.
Like multiple vendor support, fast compilers, great tooling, editor/IDE support, numerous libs, easy cross platform portability, good documentation, lots of available work, and lots of other things besides.
Even if Rust is a safer/better C/C++, for example, it still lacks most of this things. It's a single vendor language, tied to LLVM (with whatever this implies for the platforms it supports), it has lacking tooling and support, etc.
Those are not idle historical reasons.
They actively translate in important benefits that other languages lack.
Like multiple vendor support, fast compilers, great tooling, editor/IDE support, numerous libs, easy cross platform portability, good documentation, lots of available work, and lots of other things besides.
Even if Rust is a safer/better C/C++, for example, it still lacks most of this things. It's a single vendor language, tied to LLVM (with whatever this implies for the platforms it supports), it has lacking tooling and support, etc.
Good!
It's really awesome
It's really awesome