4 ms·
Google Chrome is based on WebKit, which was based on KHTML, which has been around since 1998. Moreover, Chrome depends on system and external libraries that pro
by simonster 13y ago
Google Chrome is based on WebKit, which was based on KHTML, which has been around since 1998. Moreover, Chrome depends on system and external libraries that provide C/C++ headers. Any viable alternative would need to work with C/C++ headers without needing large amounts of glue code, which isn't necessarily easy.
People still use C not because all of their code is so performance-sensitive that they can't deal with the overhead of bounds checks and garbage collection, but because there still aren't reasonably high-performance alternatives can easily integrate with existing codebases. Go and Rust are two promising contenders in this regard, but the former has only recently achieved C-level performance, and the latter is still not ready for production use. With that said, Mozilla is writing a browser in Rust (Servo), which shows their aspirations.
- kmm 13y agoWebKit might be C/C++, that doesn't mean the browser itself needs to be that way. So is Anki, for example, a Python program that works with the QT toolkit, which is C++. But point taken. I'm not saying we should use C, I'm anxious to a future where other languages can be used for serious applications. I was just trying to show C cannot possibly be that bad, as is it is still, together with C++, choice number one for every desktop application (and is Objective-C counts, it also dominates the mobile market).
- betterunix 13y agoMy point in all this has been that language popularity is nearly orthogonal to technical pros/cons. Languages become popular for non-technical reasons. The popularity of C, C++, Objective-C, and related languages has almost nothing to do with the technical features of those languages, and almost everything to do with the marketing of popular OSes: Unix, Windows, and iOS. If an OS written in ML had become dominant in the 80s or 90s, it is nearly certain that ML would be a popular language. The inertia created by this large ecosystem cannot be denied; it is part of the reason you keep seeing new software being written in C/C++. C absolutely is that bad. It is poorly defined. It forces programmers to explicitly write out things that can and should be done automatically. There is no standard error-handling system, just conventions involving return values and global error flags; there is no error-recovery system at all. Something as seemingly simple as computing the average of two signed integers winds up being non-trivial. C++ is even worse, as not only does it inherit most of the problems with C, but it introduces an entirely new list of pointless problems. Debugging code written in these languages is needlessly difficult -- you are spending as much time on high-level problems (i.e. design problems) as you are on tracing pointers and figuring out where some uninitialized value became a problem. It is not unreasonable to estimate that the dominance of C and C++ carry the cost of billions of dollars spent dealing with the headaches caused by these languages' problems. It is hard to come up with a list of technical advantages to counter the above. C has few features, and those features are not very powerful. All that C really has going for it is that you can be "close to the machine," though it should be clear that other languages let you do this too (since other languages have been used to implement entire OSes). C++ has a few technical features that may be advantageous -- but they all compose poorly with each other, and their value is weighed down by all the baggage C++ carried from C (and indeed, most of the really bizarre bugs you can make in C++ stem from this baggage). The non-technical reasons for C being popular vastly outweigh the technical deficiency of the language. The reason C/C++ is "choice number one" for desktop software is almost entirely a result of those non-technical reasons.