There are a number of reasons, which can be broadly classified as business reasons and technical reasons.

Lets start with the business reasons.

1. C# is an open, public standard (ECMA-334) but .Net is not. Note that .NET Framework which is not covered by the ECMA/ISO standard, includes Windows Forms, ADO.NET, and ASP.NET. Patents that Microsoft holds in these areas may deter non-Microsoft implementations of the full framework. Would you develop a product based on a platform your competitor controls, especially when the product you are developing challenges the same competitor's product?

2. Suppose you want to develop a new browser and you have a fairly decent operating budget. What people would you want to recruit? Clearly someone with browser development experience. You would try to get the best of the Mozilla/Firefox folk, maybe steal some from IE. Guess what these guys have been developing in. C++.

Now for the technical reasons.

1. There is no Java/C# counterpart for WebKit. At least not with the same maturity.

2. They want to leverage their V8 engine. Look into this, this is killer stuff.

3. The following is a list of all that they are potentially using (this is from Chromium so may not exactly acurate). Can you find mature, Java/C# counterparts for them?

   bsdiff, bspatch, bzip2, dtoa, hunspell, ICU, JSCRE, libjpeg, libpng, libxml, libxslt, LZMA SDK, modp_b64, Mozilla interface to Java Plugin APIs, npapi, nspr, nss, Pthreads for win32, sqlite, tlslite, V8 assembler, WebKit, WTL, zlib

4. No matter what people say sometimes the ability to operate close to the machine and have a fine grained control over memory matters. This is such a case.

5. Can you name one significant desktop application done in Java/C#. Eclipse. What else? Maybe this is possible but don't you want to play it safe? Develop in a language that has been really battle tested in this regard.

Google Chrome is based on the open-source Webkit rendering engine (also used by Safari), and that is written in C++.

Google has a list of approved languages (Javascript, Python, Java, C and C++ I believe). C# is not on that list, so it was never a candidate.

I can only guess that Java's bad reputation for user apps didn't help it. Eclipse famously had to write its own GUI classes to get an acceptable look, and as a user of Eclipse I have to say that performance still leaves a lot to be desired; especially when compared to similar programs (Komodo and Visual Studio).

Additionally, Chrome has a novel design that each tab runs in its own process (although plugins run in the main process, so crashing Acrobat or Flash brings down all PDFs or Flash animations). Operating systems have certain hooks to do this, and they are accessible from C. In a Java-fied Chrome, Google would have had to call those APIs through JNI, which seems like the long way 'round.

Because writing it in C# or Java would have added a huge dependency without giving them anything in return.

Chrome does a LOT of low-level hacking. Check out this article ^[1] for some details, but the idea is, they pulled a lot of very slick magic to make stuff like the sandbox work, and Java simply does not get them close enough to the OS. The drastic UI changes probably wouldn't work in Java, either.

C++ gives them access to all sorts of low-level and operating system APIs which Java abstracts. I suspect that there were several requirements just like the sandbox, that effectively made their decision between C and C++.

(I consider C# a non-option; it's the least portable of the three you suggested, and I doubt Google wants to rewrite their code for a mac/linux version.)

Because C++ is a fast and very popular language?

Since Chrome is based on WebKit which is programmed in C++ (and whose codebase actually pre-dates .NET) the question doesn't pose itself here.

However, the question is very interesting in general: would a language such as C# or Java be well-suited to develop a web browser? In fact, a lot of the code could be written quite naturally in .NET: the HTML parsing engine. Due to its memory usage patterns, this code would be much easier than comparable C++ code and could even perform similarly (the GC in .NET deals well with this kind of memory allocation patterns; C++ in itself doesn't).

However, there still remains the problem of how much the JIT could optimize such code in the real world. While performance surpassing C++ is theoretically possible, it's really rare. In my experience, Majka is right to cite a speed advantage of one order of magnitude for C++ (depending, of course, on the particular application). It would be very interesting to see how HTML parsing would fare. I've already mentioned that the memory access pattern here is in favour of .NET. Another point scored for .NET is the text encoding issue which is hard and inefficient in C++. (see Rico Mariani vs. Raymond Chen ^[1]).

As for the actual rendering of the pages on screen, I'm prepared to bet that C++ easily outperforms .NET considerably. The same, with some reservations, counts for the JavaScript interpreter. I believe that the simplicity of .NET is simply not enough to beat the adaptability of C++ in this regard.

Also, there are of course cross-platform issues to consider. Although I think that .NET runs quite natively on Unix platforms using Mono, this still partly disqualifies OS X and many other more exotic platforms where installing Mono isn't that trivial.

I can't speak authoritatively but I've got the impression that Java would perform even worse than .NET in some domains.

Performance.

Java or .NET runtime need to start up and the programs are interpreted by the runtime. This decreases performance.

Chrome was designed for speed from the start!

The high performance of chrome was not a side effect, it's one of the main focuses of chrome. Otherwise, what would it offer over other popular browsers? (and why would anyone switch to it from, say, firefox?)

UPDATE

Chrome is intended to serve as a platform for web applications; this is why performance is key!

And, if you think about it, having chrome itself run inside another platform (e.g. .NET) is not very effective.

Kronos is picking up on .NET as having a 'great performance profile'.

This is pipe-dreams. It has dreadful performance penalty in execution, cache invalidation, footprint, dependencies, memory management is overhyped and most apps still leak sufficiently enough not to run decently on anything but latest hardware.

The C++ FAQ he is picking on is a disgruntled guy who deals with hardware and has missed the boat. Just read the style he blogs in and all will be clear.

As for 'on par' performance, anything of any decent complexity outperforms C# by an order of magnitude. I work as a performance engineer for over 30 years now and you can take that for granted as all those VMs and JITers generate appauling cache invalidation and hugely suboptimal code. All for a gain of not dealing with memory, which is pretty sad.

As far as I understand it Google actually only permit their staff to program in either C++, Java or Python as a matter of policy.

I think the comments about performance are off the mark - yes Chrome is all about performance, however it is possible to write highly performant .NET applications, .NET is a JIT'd environment rather than interpreted, and tests have frequently demonstrated its performance capabilities. I am not sure about Java as I know little about it.

In terms of using Webkit, the functionality provided by .NET for unmanaged interoperability would make it possible to do so regardless, though it would involve some overhead.

There are, however, some legitimate reasons not to choose C# for the project:-

• Who's going to maintain it? - Google's core language competencies, tools, and infrastructure revolve around C++, Java and Python.
• Though C# has a great performance profile, there are sometimes issues with startup time (the CLR runtime kicking in). This can be mitigated somewhat, but still exists to one degree or another.
• The GC will incur a performance penalty, as will the VM. These introduce latencies which may not be acceptable given the focus on a performant browser.
• Portability - though Mono provides some portability for .NET applications, it may be easier for Google to port Chrome in native code due to its reliance on specific bare metal GUI APIs.
• Wanting/requiring access to bare metal - chrome interacts with the win32 API directly in order to achieve its UI; this would be made far more difficult in .NET.
• Wanting more convenient access to 3rd-party libraries - e.g. WebKit. 3rd-party libraries written in C/C++ are more easily accessible from unmanaged code with less interoperability issues. Since Chrome relies rather heavily on these it makes sense to write Chrome in the same language.
• There are real concerns about Microsoft enforcing patents relating to C# and the .net framework - though they have given assurances that they will not, it has yet to be determined whether they will stick to this.

Note: Removed inflammatory references to C++ - for the sake of staying on-topic!!

Further Note: 2 years older + wiser - removing the last reference to the C++ FQA + adding some more drawbacks :)

Google employs OS-like features in its browser. Like process isolation in its tabs, one tab won't crash other tabs, even the plugins are on separate process. If you'll develop something on that level, C++ could give you the most hooks on OS

Because C++ is much faster than either of those languages and they didn't want such a huge dependency. The browser is designed for users more than anything and a lot of people still don't know how to download Java. There is also the guess that they have more programmers who are more exceptional in C++ than in C# or Java. I personally would have wrote it in Clojure :p.

A browser is a style of application that needs to be slick, fast and easy to distribute.

Java's cross-platform capabilities give it limited support for slick GUIs and you also have a distribution issue with the Java virtual machine. Also, Java is generally a bad choice for fast-performing, native applications. How many of them are there out there?

C# WPF could have been a choice but the ordeal of managing and distributing the .NET runtime on every machine running Google Chrome would have been an instant showstopper. A good example of the installation overhead difference between a C# application and a C++ native application is the difference between something like Nokia's Come with Music ^[1] which downloads the entire .NET 3.0 runtime (~60MB on XP machines) and Spotify ^[2] which is 2.4MB all told.

The Browser market is difficult now that one of them comes bundled with Windows! So if you give the user a 60MB download of some framework that they haven't heard about and don't care about and it could be the difference between mass-adoption and failure.

Also, I gather that they had a certain amount of code reuse (in the rendering area) with their C++ option.

For almost the same reasons that surgeons use scalpels and not chainsaws.

1. speed
2. portability (yes, even over Java as the JVM introduces a dependency -- see #3)
3. fewer dependencies

Step back a second here. The C++ FAQ from that link shows you that the author would probably have a heart-attack reading the argument here.

He is going lower level than C++ into C, missing many features and getting lost in ranting. Just imagine what a perf hit for a tab and a button that goes to 12MB in managed would do to his thinking of C# and CLR (btw, it is nonsense to point out to a FAQ that would make CLR and C# look even more ridicolous in overhead than anything else on the planet apart from similar penalty Java VM).

If you just allocate 10,000, not uncommon, DOM nodes you would pay 2x overhead just in managed references overhead alone. So, put very, very simply, CLR doesn't scale or perform for anything but typical Rico Mariani trivial tests. Look at any decent size app and give it a good load and you'll see it scales just as poor as other historical mass-market solutions from MS/Sun. New solutions are no different apart from being more capable with threading and reworked Java with value types.

Do you own perf and sure go ahead if you think you can write a better browser, game, OS, IDE, VM, media editing app, audio and sequencing, image processing etc etc app.

VMs are known to deal extremely poor with large datasets. They grind to a halt basically. But for trivial samples, sure they are on par as it doesn't matter, doh!

VMs have been overhyped as they are easy to sell and train every Joe on the street and enflate his head that engineering is as simple as using a framework (largely due to MS blogging influence and leading to poorer and poorer software out there). But hey, you get useless candy and plenty of productivity to be proud about and be like everyone else.

That is why you pick a language for the task at hand. And you better know it 99% before you criticise it, or in right context. As we know, 99% of C# users know all other languages 100%, and make bloated software by default (they have no choice, MS and Sun make it for them).

My take is portability. I has to run on Windows, Linux and Mac. I guess they could, in theory, have used .NET or Java for that (eg via Mono for C#), but as someone else pointed out, a BIG selling point is the WebKit framework, which is (I think) C or C++, so no point in porting it to Java or .NET. Otherwise, they have to write a whole new rendering engine, and WebKit is very, very good.

For those saying it's performance: yes, and no. Managed languages (Java, C#) are nearly as quick as C++ in a lot of cases, especially if you use something like WPF for screen drawing. It's all JITed to machine code anyway.

That said, I guess there will be a lot of Objective-C in the Mac version, especially in the UI management code, so the language may depend on platform. Hell, I just want it for my mac. :)

Leveraging Existing Software

Chrome leverages the open source WebKet rendering engine, which is written in C++.

Speed

Speed is a primary design goal of Chrome. C# and Java can be made to be very fast, but at the margins that Chrome is working at they can't be made as fast as C++ code.

Multi-Platform Compatability

Chrome is meant to be available on many platforms: Linux, Mac, etc, not just Windows. While Mono is a viable option for C# on linux, it adds significant complexities and trade-offs. Java is an option but the promise of "write once, run anywhere" has been largely unfulfilled. Multi-platform development using C++ is a known quantity with many successful examples (Mozilla, Apache, Photoshop, etc.)

Because its main "selling" point over the competition (Mozilla, IE) is performance. Kinda tough to compete on speed using Java or .NET. Second reason is portability: .NET means Windows only and Java means dependence on a runtime that may not be available on the client. Keep in mind that Web Browsers are seen as a commodity these day that have to run on everyone's grandma's computer with no installation hassle whatsoever. A browser with dependencies is dead in the water.

Because back then when the WebKit development was started C# didn't exist (as a matter of fact it still doesn't really exist in the Mac platform as of today despite Mono), Java had inferior performance and it was not the default programming language for Mac or Linux.

The codebase was KDE html engine in C++ and that's why it is not in Objective-C.

They do have top notch C++ engineers so they wanted to take advantage of it. Are there any popular browsers done in C#? I guess not so it would be hard to build a team with experience in both C# and browsers. And perhaps most important thing. C# is MS technology -> if MS is not using C# to write even calculator in Vista or their MS Office why their competitor would do that?

I don't think the arguments "close to the system", "webkit" and so on apply. You can very well wrap this around and call that from C# and Java.

Let's turn the question around. Why shouldn't Chrome be written in C++?

Applications that was written in C++ can run without the need/dependency of any underlying VM. This will be easier for end-users because they don't need to install .NET framework/JRE first. Also, it will provide better performance and better reliability.

I guess only someone from Google could answer this, but web browsers are really system applications, and system software is written with C or C++, not C#/Java. All other major web browsers are written with C++ as well.

C++ was designed primarily so that the author and his friends would not have to program in assembler, C, or various modern high-level languages. Its main purpose is to make writing good programs easier and more pleasant for the individual programmer.
— B. Stroustrup (D&E, p. 106)

Performance

Unless I am wrong, Chrome is based on many librairies for which .NET wrappers simply do not exist.

Instead of creating wrappers, they chose to go with C++, so they would get performance boost and a faster development.

Creating wrappers for all the C/C++ libraries they use would have required a lot of time / tests.

The control, power and speed C++ provides can only be matched (surpassed ?) by C itself and not Java or C#. If you know exactly what you're about and after and do not need guidance from structures like the GC then you'd obviously go for as much control, power and speed as you can get. That's exactly what the Chrome team is doing I believe. Another possible reason is the one-thread-per-tab principle (concurrency of sorts) they've employed in chrome. To run such a system would need a lot of resources and access to these resources is crucial. Thus a language that doesn't hustle much to get to these resources ie. fast and close to the underlining machine architecture, would be the best bet to implement such a system in. Thats where C++ comes in.

Performance wise. as you could see, Chrome is super light-weight, its RAM size used is smaller than Mozilla.

For 'great performance profile' check out what a managed app does to your machine, something like VS.NET (and don't forget it is due to partial .NET adoption, if it was full-on you'd need a cray to boot it, just like Singularity which won't boot btw).

Silverlight and WPF are another few examples of great performance killers, eating CPUs.

VMs are written in C++, and by reading that Kronos pointer FAQ and believing in it, by definition you wouldn't have a Java or CLR VM available today, yesterday or ever.

Arrogance comes from simplifiers in managed land really..

When Google wanted their own browser, they did what any other company would do, they hired someone ^[1] with experience developing web browsers to lead their project. Ben Goodger, who was previously the lead Firefox developer, obviously had a lot more experince in C++ than C# or java (since Firefox is written in C++).

Its great to think of Google as so full of super-geniuses that they let their tea ladies design brand new browsers in each of the available languages (in the time they're waiting for the kettle to boil) and then released the fastest to us as Chrome; but the tangled twisted mess of web languages (HTML, CSS and Javascript) really is very hard to interpret.

Portability and performance are definitely one of the many reasons. I think Java would have been great except that you're now relying on the Java VM which is a punch in the face when you compare such a product to FireFox or IE which are standalone products. I've worked with companies that stay away from anything from Microsoft. To them it's an unnecessary dependency. Using .NET framework may not be extensible enough for what you're doing. You may want to roll out your own algorithms and logic instead of using built-in features. This is especially important for such product as a web browser which competes with giants such as FireFox, Opera, Internet Explorer and etc. You have to make it fast. You have to make it efficient. Otherwise you labor will go to waste as you're not going to be able to compete. This is why having your own framework is a better thing since it allows you to make it as good as you want it w/o getting stuck with what you have to use.

A benefit from writing it in C++ over C# is that they can as they plan to release versions for other platforms other than Windows. While it's possible to do this with .NET too it would have meant people would have to install the mono runtime which is not a very common thing on non Windows computers. Similarly writing it in Java would have created the dependency to the Java runtime, which would have been a better option. But it's not a very good idea to write something like a browser for a virtual machine because of startup times and performance, if they want to compete with firefox and other good browsers.

The other reason is the choice of rendering engines. Because they are using webkit which is written in C++ it's an obvious choice.

I imagine they made a trade-off of short-term benefits such as performance over long-term benefits like maintainability. C++ might be faster now than C#/Java code, but as hardware advances speed will be less relevent a benefit. It creates a terrible situation for security in that they are effectively snubbing the billions in IS work done to protect the .NET/Java Platforms from exploits. There is no way they can keep up. We might effectively be embracing the next ActiveX browser security hole by embracing Chrome.