Chrome 14 Beta Integrates Native Client

derGoldstein writes "This year Microsoft kept signaling that it's going back to lower-level code with a C++ renaissance. It would give C++ programmers the same priority that was, up until now, reserved for .Net programmers. They even launched a new show about it on their Channel9. Now Google wants to appeal to native programmers with their Native Client for Chrome. It seems the two companies want to cover both the higher-level JavaScript and lower-level C/C++. I dare hope this will give seasoned C/C++ programmers a place alongside JavaScript programmers at the web development table."

Comments

C++ Making its way to the web?

[trunicated]

AND replacing Javascript? Where do I sign up?

Re:C++ Making its way to the web?

[YodasEvilTwin]

There is no native client standard. They can't break compatibility by adding completely new features unrelated to anything else. They'll just result in web games etc. that only work in Chrome. It's like saying that Apple is "breaking compatibility" by making apps that don't work in Windows.

Re:C++ Making its way to the web?

[sqlrob]

C++ on the web. That worked so well last time

Re:C++ Making its way to the web?

[bragr]

I don't see it that way. There is no argument that Google is web company, and people can only experience the web through the browser, which means that the features that the "average" browser supports is a limiting factor in what Google can do.

I've always seen Chrome as a way for Google to stimulate other browsers to be better and drive innovation. Every since Chrome came onto the scene, showing off its fast rendering and javascript engine, other browser companies have had to step up their game, which is good not only for Google, but the internet as a whole.

Will other browsers support it? Maybe? If it turns out to useful, and programmers like it, I bet you can expect to see this in Firefox fairly soon. If not, it was an interesting experiment.

Re:C++ Making its way to the web?

[bragr]

At least Chrome is cross platform and open source(ish). So its not quite the same thing.

Re:C++ Making its way to the web?

[shutdown -p now]

The original ActiveX in IE was designed with practically complete disregard for security. NaCl is the opposite of that - it's a very cleverly designed sandbox for native code.

Re:C++ Making its way to the web?

[shutdown -p now]

Just when we seemed to get a standard web browsing experience

We did? I still see a lot of "-webkit-" etc in CSS for those new and shiny HTML5 websites.

Re:C++ Making its way to the web?

[sqlrob]

Making sure there's no problems with Javascript is easier than checking native code. Yet there's still flaws with that parser, enough so that most browsers have a "workaround" of "disable JavaScript". Why do you think this will be better?

Re:C++ Making its way to the web?

[drpimp]

C++ is over-rated ... we used VB as well and it's the bestest EVAR (shreeeeeek, music stops) /runs for cover

Re:C++ Making its way to the web?

[shutdown -p now]

Of course, verifying and sandboxing JS is easier. However, JS is not high-perf enough for many real-world applications. The question then becomes whether it is possible to sandbox native code without some mindboggingly complicated scheme. And the answer is yes - and I invite you to read the NaCl research paper for details. The scheme is, in fact, surprisingly simple - less so than e.g. bytecode verifier for CLR.

Re:C++ Making its way to the web?

[mswhippingboy]

Judging by the documentation it doesn't even have access to the DOM..

Sure it does.

The Native Client module. This module uses the Pepper Library, included in the SDK, which provides the bridge between the Native Client module code and the web page JavaScript and DOM. Currently, the SDK supports the C and C++ languages. When compiled, the extension for this filename is .nexe.

Re:C++ Making its way to the web?

[derGoldstein]

I've always seen Chrome as a way for Google to stimulate other browsers to be better and drive innovation. Every since Chrome came onto the scene, showing off its fast rendering and javascript engine, other browser companies have had to step up their game

That's true, and that may have been the initial intent, but they've been pushing the Chrome browser like practically no other product of theirs. A Chrome ad appears on Youtube pages very frequently, in several formats, and "types" of ads (some are animated, some are still images saying something like "browser faster"), and they keep making oddball viral-ish Chrome campaigns. I can't think of any product they push this hard (although Google+ may change that).

Chrome market share has been rising inexorably since its release.

It's not just a tech demo anymore. They want the browser market.

Re:C++ Making its way to the web?

[SanityInAnarchy]

Chromium is open source.

And yes, it's cross-platform and actually sandboxed. Unlike ActiveX, this actually would be a reasonable alternative to JavaScript.

Re:C++ Making its way to the web?

[farrellj]

Let me know when they replace Javascript with Forth! :-) ....I'm not holding my breath! :-)

ttyl
          Farrell

Re:C++ Making its way to the web?

[derGoldstein]

Yes, but it's not nearly as bad as when you had to accommodate IE6. The "-webkit-/-moz-/-ms-" hacks are usually just to add extra graphical detail, not actual functionality. Then there's the DOM and XHR stuff, to which there are plenty of solid, fast solutions that are plug-and-forget. You no longer have to make a chart of "browser capabilities" before starting to design a web app. HTML5 is still in Draft/Working Draft status, but in practice things aren't nearly as bad as they were ~3 years ago.

Re:C++ Making its way to the web?

[PCM2]

It's not just a tech demo anymore. They want the browser market.

Ah, yes... that lucrative, lucrative browser market.

Re:C++ Making its way to the web?

[Rhys]

Yes, because what I really want to do is use a language that is terrible at string processing! If this were perl, python, or ruby, I might care. I'd rather learn javascript from scratch, than do string processing in C/C++.

Re:C++ Making its way to the web?

[PCM2]

Note that NaCl code is only cross-platform in the sense that it's OS-independent. Being true native code, it's not processor-independent; if you want NaCl modules to run on x86, x64, and ARM, for example, you need to have compiled three separate versions of your NaCl binary, one for each architecture.

Re:C++ Making its way to the web?

[PCM2]

NaCl has access to the DOM via the "bridge" you mention, but in practice what that means is that NaCl's access to the DOM is handled through inter-process communication calls. Google has said that games that rely on a lot of DOM access would probably be better off being written in JavaScript for this reason. The two technologies are clearly meant to be complementary.

Re:C++ Making its way to the web?

[Riceballsan]

I do believe the point is they are trying to make their changes as something plausible for the competition to follow. Google's goal is to ensure that they can do what they want to do on their web pages, they couldn't care less if the user is looking through chrome, Firefox or even IE, that is if they can make their software work in that format. The difference between active X and C++, is Google WANTS Microsoft and IE to follow suit and add C++, while active X was designed as something that Netscape couldn't do if they wanted to.

Re:C++ Making its way to the web?

[wootest]

Define standard. If you mean standards-based, we're there. Many of the vendor prefixed CSS properties are initial implementations of standards, and many of them have since graduated to actual standards. Even the ones that are made up by a vendor (like the canvas element) are written up, submitted, improved and adopted; a far cry from attempts to insert a box with a new environment in the middle of everything (ActiveX, Silverlight, Flash, Java; the list goes on). NaCl looks like a more well-meaning version of those boxes. With Chrome OS and the pain of NPAPI plugins, I understand why Google would want it in Chrome. The case isn't so clear for the rest of the world.

The vendor prefix is a symptom of incremental adaptation of lots of smaller features. I prefer it to necessarily waiting five years to start using an entire versioned standard.

Re:C++ Making its way to the web?

[praxis]

The browser market might not be the most lucrative, but there is some return on one's investment.

Re:C++ Making its way to the web?

[derGoldstein]

Do I really need to explain why it's beneficial to own the leading browser? The leading browser sets the agenda -- just look at how long it took to get rid of the *extremely* non-standard IE DOM stuff. You could argue that they don't make money off of Android, but it's obvious why they need it to succeed. The browser is gradually becoming the biggest software platform. You see the web through the browser's eyes -- and in Chrome's case -- Google's eyes.

Re:C++ Making its way to the web?

[shutdown -p now]

Oh sure, things are much better than they were even 4 years ago. Just saying that we're not quite there yet, and won't be until all the features of HTML5 that are necessary for rich apps are standardized (at least de facto, across all major implementations). I'd say, give it 3-4 more years...

Re:C++ Making its way to the web?

[PCM2]

Do I really need to explain why it's beneficial to own the leading browser? The leading browser sets the agenda

That's not what you just said, though. You said Google "wants the browser market," in rebuttal to a guy who basically said Google made Chrome as a way to set the agenda (causing other browser vendors to "step up their game" in the process). Google still makes 100 percent of its money from Web sites, not browsers. As such, it still does not benefit Google to create a browser full of nonstandard things as a way to "own the browser market." The more different browsers that can use Google's Web apps, the more Google benefits.

Right now, Google's Web apps are accessible to pretty much 100 percent of the browser market. Some browsers might run them more slowly, and some might have some rendering quirks, but they're mostly available to anyone. As soon as Google starts restricting things to its own browser, it effectively cuts off a part of that market share. If Google's compatibility is 100 percent now, what sense does it make to start pushing toward 85 percent compatibility or lower?

Likewise, what sense would it make for Google to crush Firefox, Opera, and Safari, and leave the market with only two credible choices: Chrome and IE? Is that a scenario Google wants to see happen again? (And you know IE will never go away as long as Microsoft ships it free with Windows.)

So while yes, Google would like people to use Chrome and benefit from its fast JavaScript performance, good Web standards support, and automatic updates, "owning the browser market" is not really on the agenda, IMHO.

Re:C++ Making its way to the web?

[oakgrove]

So, you didn't get enough vandalizing the other thread so you had to come spread some FUD in this one too, huh? This is nothing like ActiveX. ActiveX was a completely closed proprietary technology that works only in ie. This is open source and can be implemented in any browser that the developers care too. How long until this screen name gets retired to that great shill home in the sky?

Re:C++ Making its way to the web?

[derGoldstein]

First, if we're going for semantics, you said "that lucrative, lucrative browser market", which implies (since you were being sarcastic) that there's no money to be made by having more people using your browser. In the macro sense, this just isn't true.

And yes, I think that people are being naive. I can't know what the original intention was on the first day they started working on Chrome. At that point, they may well have wanted the other browsers to accelerate their development, and comply with standards. But Chrome's market share is rising. Whatever their plans are, unless they're going to intentionally slow down Chrome development, it will keep rising.

Like you said, IE will always be here as long as Windows is the dominant PC OS (also, IE9 is really quite good, they seem to be taking it seriously this time). Safari will likely be there because it's not in Apple's nature to let it go. But Firefox? I'm not sure. If you're using Firefox (which I am), then, on a PC or an Apple, you've made the decision to switch to a different browser. If people decide that Chrome is the better alternative browser, then there's no safety net for Firefox.

I really hope this doesn't happen, I like an array or competing browsers, but I don't see Google backing down just to let Firefox keep up. You're basically asking Google: "would you like to have Firefox's market share?". Do you really think they'd say "no"?

Re:C++ Making its way to the web?

[PCM2]

You're basically asking Google: "would you like to have Firefox's market share?". Do you really think they'd say "no"?

That's what I'm saying.

As long as there's no direct profit to be had from gaining Firefox's market share, it's not a discussion that comes up at meetings at Google.

Re:C++ Making its way to the web?

[PCM2]

First, if we're going for semantics, you said "that lucrative, lucrative browser market", which implies (since you were being sarcastic) that there's no money to be made by having more people using your browser. In the macro sense, this just isn't true.

Sorry to reply twice, but how is it not true? Right now, what makes producing Firefox "lucrative" for the Mozilla Foundation is .... (drum roll please) ... royalties from Google from searches powered by the Firefox search bar. That's it. 97 percent of Mozilla's income derives from that one source: Google. Google obviously profits even more from the same searches, though, or it wouldn't have the money to pay the Mozilla Foundation. That's business.

But wait! Google would profit even more if it didn't have to pay the Mozilla Foundation anything -- right? Well, not really. There aren't just two browser choices on the market. So if Google took a bunch of dynamite and blew up the Mozilla offices, every single person who uses Firefox now would need to switch to Chrome in order for Google to be assured the same number of searches it gets now (because to my knowledge, no other browser but Firefox and Chrome has a search bar that automatically defaults to Google). Would that be a smart business decision? Would the additional amount it had to spend marketing Chrome be substantially less than the portion of search royalties it pays Mozilla?

Google wants to create a high-performance Web browser and generate user excitement around the concept of Web browsers and browser technology because it is a company that has staked its entire strategy on Web browsers and browser-based software. If all software is going to run in the Web browser, the way Google wants it to, the software has to perform well enough that people are willing to use it. Google is trying to make sure this is true, and to the extent that other browser vendors need to compete, it has forced them to improve their own JavaScript performance, among other things.

As for "taking their market share," though, as I said, I really do not believe it is on Google's agenda. Google would obviously like users to steer clear of browser deficiencies that cause Google's Web applications to perform poorly. But it doesn't make much of a difference to Google whether that means users switch to Chrome or that the other browser vendor simply fixes the deficiencies. Google does not make any money directly from Chrome (except possibly by licensing Chrome OS to Samsung and Acer, I'm not sure about that one). To the extent that Google makes money indirectly from Chrome, however, it makes just as much (if not more) from Firefox, and almost as much from the competing browsers (to the extent that the people who use those browsers also access Google Web applications and services).

I really hope this doesn't happen, I like an array or competing browsers, but I don't see Google backing down just to let Firefox keep up.

Who said anything about Google backing down? If Google really does succeed in making a browser that's demonstrably superior to Firefox in every respect, I would switch tomorrow and so should you and everyone else. But since you don't use Chrome and I only use Chrome some of the time, apparently Google has yet to succeed at that. Still, any product that has that much of an advantage over all of its competitors deserves to succeed, and I won't spend any time crying over Firefox if that happens.

What you seemed to be saying, though, is that Google wants browser market share. I and others argue that's not the case; Google simply wants to create a better browser. If that leads to Chrome gaining more market share, well, that's how markets work.

Re:C++ Making its way to the web?

[dirtyhippie]

The sandboxing on NaCl actually is relatively incredible. Only a modified subset of x86/amd64/arm is executed - potentially unsafe instructions are not. It's actually a lot like (para)virtualization. Read about it:
    http://en.wikipedia.org/wiki/Google_Native_Client
    http://code.google.com/chrome/nativeclient/faq.html#PreventBreakouts

Re:C++ Making its way to the web?

[derGoldstein]

First, if we're going for semantics, you said "that lucrative, lucrative browser market", which implies (since you were being sarcastic) that there's no money to be made by having more people using your browser. In the macro sense, this just isn't true.

Sorry to reply twice, but how is it not true? Right now, what makes producing Firefox "lucrative" for the Mozilla Foundation is .... (drum roll please) ... royalties from Google from searches powered by the Firefox search bar. That's it. 97 percent of Mozilla's income derives from that one source: Google. Google obviously profits even more from the same searches, though, or it wouldn't have the money to pay the Mozilla Foundation. That's business.

But wait! Google would profit even more if it didn't have to pay the Mozilla Foundation anything -- right? Well, not really. There aren't just two browser choices on the market. So if Google took a bunch of dynamite and blew up the Mozilla offices, every single person who uses Firefox now would need to switch to Chrome in order for Google to be assured the same number of searches it gets now (because to my knowledge, no other browser but Firefox and Chrome has a search bar that automatically defaults to Google). Would that be a smart business decision? Would the additional amount it had to spend marketing Chrome be substantially less than the portion of search royalties it pays Mozilla?

I wasn't talking about the money they'd save if they didn't have to pay Mozilla for search results. I'm talking about the overall "Good for Google" picture:
Google makes web apps/software for the browser. This software is "rendered/run" in a browser. If they control both the software and the browser rendering it, they can optimize both ends -- make their web apps especially optimized for Chrome, and push elements in Chrome that they need for their web-based software. Also, Google isn't the only company that makes web applications -- practically every company they consider to be "competition" also delivers their software/content through the web (not exclusively, but rather "also").
Technically, MS is the only other company that can, potentially, control both ends* (IE9, and, for example, Office365). The rest of the competition has to run their code in another company's browser. If Facebook wants to optimize performance, they have to optimize for IE, Firefox, Chrome, Opera, and Safari. But they can only optimize one end -- not both. This gives Google the advantage -- simply by making their existing apps better/faster -- and that's worth money. It also means that they have an incentive to increase their market share.
(*I'm forced to add an asterisk here because, technically, Apple also can control both ends, but Apple's business model is completely different -- they need a native browser for iOS, they're not really pushing Safari to be installed on all Windows machines, even if the browser can run on windows)

As for the fate of Firefox:
I'm really just making a mechanistic observation -- Chrome is taking "market share" (yes, I understand that this term isn't ideal here... maybe "userbase" or "installbase" would be more accurate) from all browsers, but the graphs show that the two main browsers they're taking users away from are IE and Firefox. What I'm saying is that if the trend continues to be what it's been for the past 2 years, Chrome will eat into IE and Firefox.
MS is going to be able to fight back, especially if they make sure that their browser remains technically competitive (and if Windows Phone begins to penetrate the market). Firefox, however, will ultimately not have the financial means to put up a fight -- a reduced userbase means less income, and they have to keep developing their browser for desktop/laptop (the Intel/AMD stuff) and mobile platforms. The hardware landscape is moving faster all the time, which means that they have to optimize their browser for mo

Re:C++ Making its way to the web?

[hairyfeet]

Would that really be so bad? It isn't like the user would have to download all three versions, just have the browser do a check and return a CPU flag.

I'm sure I'll get grandpa jokes for saying this but IMHO this is one of the things we have been doing wrong lately. In the old days code was more optimized for the particular arch and frankly wasn't nearly as bloated. If the code can be compiled for the features of the various chips, thus giving us users better performance and less bloat? I personally am ALL for it.

Re:C++ Making its way to the web?

[maxwell demon]

Note that NaCl code is only cross-platform in the sense that it's OS-independent. Being true native code, it's not processor-independent; if you want NaCl modules to run on x86, x64, and ARM, for example, you need to have compiled three separate versions of your NaCl binary, one for each architecture.

That's what traditionally is meant with cross-platform code: You can compile it for several platforms.

Re:C++ Making its way to the web?

[Instine]

Alchemy didn't replace Javascript. Why should browser specific solutions threaten it. Plus JS is the most popular language in the world for a reason. In fact for many reasons.

Re:C++ Making its way to the web?

[Instine]

Sorry, link to Alchemy .
If you want native speed in any browser and the benefits of C++, then stop your moaning and give it a try....

Re:C++ Making its way to the web?

[TheRaven64]

Yes, a very lucrative market. If you control the browser, then you can harvest a lot more information about browsing habits than if you just get to inject some code into a lot of sites. That information then lets you sell a lot of targeted adverts.

Re:C++ Making its way to the web?

[Kjella]

That's all well and good but there's a reason thick clients are still around. By pushing "application-like" functionality in Chrome they can start making their web apps more like normal desktop apps, only delivered online over the Internet. Yes, it will require you to run Chrome to get the extra "desktop-ish" qualities but what exactly would be Google's problem with that? It wouldn't be to own the browser market as you know it today, but to control the next-gen application delivery framework. They want you to go to Google Docs with Chrome and have a MS Office clone - or at least something just as technically capable - spawn from your web browser. The browser market would continue to exist but it'd be "just" a browser, using it for apps would be what Outlook Web Access is to Outlook.

Re:C++ Making its way to the web?

[sgt scrub]

Besides, if google was trying to go for lock in wouldn't they have done it for Go instead of C or C++?

Re:C++ Making its way to the web?

[Jesus_666]

"Why should I compile for ARM? I've never even heard of that. Everyone uses x86."

Unless NaCl used something like Apple-style fat binaries that are guaranteed to contain all supported architectures we'd see a lot of people who only compile for their own architecture or who only upload those files they deem relevant.

Of course now Google wants to add functionality to let people distribute their code as LLVM bytecode that the browser has to compile. That does eat into the benefits of NaCL a bit; after all, having to first compile the code for the local platform requires more time and power than just loading a library. Plus, the question is whether current non-bytecode NaCL will be deprecated or if we will have to put up with "best viewed on x86" for a while. But it's still better than forcing web developers to think about how to cross-compile their code for random architectures.

Re:C++ Making its way to the web?

[Jesus_666]

Vendor prefixes are GOOD. Here's why:

When a browser adds a new CSS property, for example box-shadow, the property is added with a vendor prefix to denote that what the browser currently supports is the current snapshot of what the development team thinks the property should work like. Now, the dev team might be wrong or they might be conding against a feature that hasn't yet been finished. These things happen.

If nobody used vendor prefixes it'd be 1998 all over again: Web designers would need to find parsing hacks to exploit so they could make sure that each browser only acts on that one implementation of box-shadow that conforms to the way the browser works. We can't expect browser vendors to get their implementation 100% correct on the first try so saying that they should only make the property available once it works right is not a solution. Plus, it would mean that nobody could try to implement parts of the spec that haven't been set into stone yet, which would make it harder to find problems with the spec.

The nice thing about vendor prefixes is that they are self-disabling. If the real prefix has already been formalized you can write something like this:

#fooBox
{
/* Mozilla preliminary implementation */
-moz-box-foo: 1px 1px 2px 2px red;

/* Opera preliminary implementation */
-o-box-foo: 1px 1px 2px 2px red;

/* Microsoft preliminary implementation - color attribute is ignored */
-ms-box-foo: 1px 1px 2px 2px red;

/* WebKit preliminary implementation - sizes switched around */
/* This was how the first draft specified it */
-webkit-box-foo: 2px 2px 1px 1px red;

/* Standard implementation */
box-foo: 1px 1px 2px 2px red
}

While a browser only has preliminary support, that browser wil use the prefixed version of the property. Since the non-prefixed version comes last, however, it overrides the preliminary version if the browser supports it. Even if the preliminary implementations have quirks that persist, once the standard way is supported the browser will support it in the standard way. Thus, as soon as a browser has a conforming implementation, it will supersede the perliminary one since it was defined last. The designer needs to do no work whatsoever to make th new version of the browser behave correctly.

It's true that having browser-specific code is ugly but given the way web standards work it's really the best way we have to avoid much uglier hacks.

Re:C++ Making its way to the web?

[Jesus_666]

You don't have to accomodate IE6? Lucky you. At my job, we make websites for businesses. Of course "working well in IE6" is still a core requirement. I guess we'll see the end of IE6 as mission-critical software not before Windows XP dies out far enough to not matter anymore. Given the fact that there are still businesses happily using Windows 9x I'd say that web design-wise 1998 will end somewhere in the 2030s.

Yeah, I'm so excited

[AdmiralXyz]

I dare hope this will give seasoned C/C++ programmers a place alongside JavaScript programmers at the web development table.

Yeah, nothing thrills me more than the prospect of a language with absolutely no memory safety or bounds checking being exposed to the public Internet. What could possibly go wrong?

Re:Yeah, I'm so excited

[epyT-R]

you mean like when the browser itself is exploited in the same manner by crafted javascript?

the only way to truly secure 'the web' is to remove the ability to script browsers beyond basic formatting that can be done in html.

honestly if we're gonna keep javascript, I wouldn't mind seeing C++ as well..

Re:Yeah, I'm so excited

[shutdown -p now]

I suggest that you read about how NaCl actually works before commenting. It is a sandbox for native code. It doesn't run just any code, either - there are certain constraints in place which make it possible to verify the result for safety. "Safety" here means that code cannot break out of the sandbox - it can, of course, still crash itself, but that would be fully isolated, and cannot be used in the usual manner as a privilege escalation exploit.

Re:Yeah, I'm so excited

[PCM2]

"Safety" here means that code cannot break out of the sandbox - it can, of course, still crash itself, but that would be fully isolated, and cannot be used in the usual manner as a privilege escalation exploit.

Or that's the idea, anyway.

Re:Yeah, I'm so excited

[siride]

I'm guessing you haven't used any languages other than C++. Aside from having a lot of libraries (not all of them good, mind you), the benefit of time (to understand all of the inane quirks of the language and make compilers that are almost halfway decent) and its performance (which other languages are catching up to), it's not a pretty language, it's not elegant, it's not easy, it's not orthogonal. It has a lot of warts and misfeatures. If it weren't for the fact that you can write fast code in C++, I doubt it'd be used nearly as much as it is.

Re:Yeah, I'm so excited

[derGoldstein]

It's scary *now*. There are new exploits daily -- search Google News for "new browser exploit". I wouldn't be browsing without NoScript on a computer with any information I care about. I use Chrome only on sites that I know and trust (basically a whitelist). I'd probably use Chrome more if it had a reliable script blocking add-on.

Re:Yeah, I'm so excited

[DemonGenius]

The walls of a weak sandbox can break, both in real life and in code.

Re:Yeah, I'm so excited

[derGoldstein]

It's the nature of digital logic. If you want memory management, you need more cycles. If you want "better" (more flexible and succinct) syntax, you need more cycles. C++ is popular because it's the highest abstraction you'll get that's still fast. As long as there isn't some insane quantum leap in computing power, C++ is the best option you have for creating "compute-intensive" software.

Now for my subjective viewpoint: I program using whatever language has better support for the task. I wouldn't use C++ for general server-side development when PHP will do most of the work for me. I use JavaScript on the browser because that's the only option. I use Perl and Python for housekeeping scripts, since they have countless libraries that will serve most of my needs. Having said that -- if there's no specific requirement from the environment, I choose C++ whenever I can. If there was a widely supported scripting language that was basically C++/STL, I'd use it instead of other interpreted languages. C++ is an explicit, flexible, OO language with fewer warts than most other languages. Yes, there's a long "here's what you shouldn't do" list, but once you have that down it's probably the language you have to "hack" the least to achieve your goal.

Re:Yeah, I'm so excited

[shutdown -p now]

Sure, but similarly JavaScript interpreters (and even more so modern JIT-compiling VMs such as V8) can have exploitable bugs, including code injection. Heck, even an HTML parser can be vulnerable, if written in C or C++!

The trick is to make strong sandboxes. Formal proofs help there. There are a few of those in NaCl paper.

Re:Yeah, I'm so excited

[david.given]

I find myself a little perturbed by the fact that they're using code verification and sandboxing. If the sandboxing is solid --- which isn't actually that hard; any modern operating system already does this as a matter of course as part of the process model --- then the verification shouldn't be necessary.

Re:Yeah, I'm so excited

[gmueckl]

The crazy thing is that process isolation as provided by operating systems is relying heavily on hardware support. Most processors only have a kernel mode and a user mode and the mode switching is a part of what isolates processes. The 80386 was cleverly designed to have 4 modes, called rings, 0 to 3, where each inner ring would have more privileges than the outer rings. This was at a time where most of the OS makers ended up looking at this design and scratching their heads in wonder, having no idea how to use that feature. OS/2 was one of the few exceptions. Well, most other OS makers were thinking about compatiblity with other CPUs and put the kernel at ring 0 and the user space at ring 3, leaving no ring above and below. This is why hardware support for virtualisation has to add another layer below ring 0. And this is also why NaCl needs such an elaborate sandbox: it can't use the support already within the CPU because it can't run in ring 2 and let the downloaded code run in ring 3, which would be the ideal solution.

Re:Yeah, I'm so excited

[shutdown -p now]

The original paper makes an explicit assumption that OS process/sandbox isolation boundary is not foolproof.

Re:Yeah, I'm so excited

[shutdown -p now]

They are already working on PNaCl, which - you've guessed it - uses LLVM bit code as the portable representation.

Re:Yeah, I'm so excited

[aeoo]

"Safety" here means that code cannot break out of the sandbox

That's one heck of a claim. You do realize that, right? How long do you think until we get a 0-day that breaks out of NaCl sandbox? At this point it's probably not worth the trouble since NaCl is not even slightly close to being popular. But once and if it gets popular I say it will take something on the order of a few months for an exploit to show up.

Re:Yeah, I'm so excited

[shutdown -p now]

Of course I'm not saying that NaCl implementation is guaranteed to be free of security flaws. But neither is the JS interpreter in your browser. Nor the HTML and CSS parsers in that same browser. Heck, remember the zlib exploit?

Re:Yeah, I'm so excited

[epyT-R]

even if the OS is secure, there can still be a flaw in an application once you allow it to process data brought in from outside. the closer it gets to turing complete, the more the risk.

well...

[superwiz]

Intellisense is by far the best C++ dev environment. As much as I hate having to work in Windows, homo technicus beats homo sapien any day. And I find that I write faster and better when I have the right tools than when I have a big ego. If Chrome can produce a better environment AND be the first to support all C++11 features, I'll be happy to watch MS slide into history. Until then, I expect MS programmer base to grow.

Re:well...

[zget]

It's Visual Studio. Intellisense is the autocompletion feature...

Re:well...

[YodasEvilTwin]

You mean Visual Studio. Intellisense is a small component of it, not a dev environment.

Re:well...

[superwiz]

Intellisense is also automated syntax checking. There is no other environment which is able to do a full parse of C++ without compilation and determine the errors. There are environment which PARTIALLY accomplish the task, but none do it fully.

Re:well...

[JonySuede]

netbeans is a quite powerful c++ IDE and contrary to VS it is multi-platform. Have a look at that http://netbeans.org/images_www/v7/screenshots/cnd.png

Re:well...

[jeremyp]

Xcode 4.1 has that ability.

Re:well...

[bberens]

Rumor has it MSFT is about to ditch .net developers in favor of HTML 5 + Javascript for "native" applications. Windows 8 allows you to run HTML 5 + Javascript "natively" (at least, as native as .net). The conferences MSFT has thrown lately have been light on .net love. So I expect the MS programmer base to grow, but not C++. C++ and likely always will but that place is shrinking.

Re:well...

[shutdown -p now]

I think you misunderstand what NaCl is. It is not some kind of C++ interpreter or VM; it does not "support C++ features". It runs native code. Said native code can be the output of a compiler of any language - there are some restrictions on what the output can look like (e.g. opcodes must be aligned), but there's no inherent restriction on languages. Today, Google supplies a C++ compiler (modded Clang? not sure what it is) that respects those constraints, but anyone can do so as well, including VC++.

And, of course, you can use VS to edit code while compiling it with a different compiler - .vcxproj files are MSBuild scripts, and so you can completely override the default build process and hook up g++ or whatever - and still have your intellisense (though no debugging).

Re:well...

[superwiz]

Netbeans is 2nd best. VS is still #1. But that is not to say that Netbeans is bad. It's really good. It's just not Intellisense. It has it small problems and long-term problems. The small one is that it is too Java-centric. It attempts to use an AST for C++. Which is all fine and good except it doesn't know how to handle "friend". So it ends up not being aware of the methods which are visible in the friended scope. It's long-term problem is that it's in Java. And given how poorly Oracle has handled Java as a platform, it's future is becoming questionable. I certainly would not commit any large project to Java at this point -- not as my first choice. One rarely succeeds on the web by burning bridges as fast as Oracle has been doing it with Java. There is a lot of inertia built into it because the programmer base is so large, but if you look at any of their latest development, it's down-right depressing. They are slashing modules and language support from Netbeans (7.0 doesn't have Python support anymore). They are just an overall mess that brings more headaches than it solves.

Re:well...

[PCM2]

Said native code can be the output of a compiler of any language - there are some restrictions on what the output can look like (e.g. opcodes must be aligned), but there's no inherent restriction on languages. Today, Google supplies a C++ compiler (modded Clang? not sure what it is) that respects those constraints, but anyone can do so as well, including VC++.

I guess in theory there's nothing stopping any compiler from outputting NaCl binaries, but at present none does, except for the aforementioned Google toolchain that comes with the NaCl SDK (which is a modded version of GCC). Code output for NaCl carries the extension ".nexe" -- technically it is native machine language, but the binary won't execute anywhere but inside NaCl. The SDK and its APIs are also changing a lot; .nexes compiled with earlier versions of the SDK won't work with Chrome 14 or later.

I kicked the tires on NaCl for InfoWorld earlier this year.

Re:well...

[superwiz]

Xcode is still GCC 4.2. MSVC 10 has most of the nice features of C++11:

http://wiki.apache.org/stdcxx/C++0xCompilerSupport

Re:well...

[loufoque]

Intellisense is by far the best C++ dev environment.

I guess it's a matter of taste.
I find that Visual Studio is very unintuitive and impractical for the way I code in C++.

In that category, I've had better experience with Eclipse.

If Chrome can produce a better environment AND be the first to support all C++11 features, I'll be happy to watch MS slide into history. Until then, I expect MS programmer base to grow.

With some work, you can probably use any compiler you want, since it directly executes machine code (albeit in a custom executable format, and I couldn't find information about the ABI).
The reference compiler is GCC.

Re:well...

[superwiz]

No, I didn't misunderstand. I know it's not a tool. I just expect that once Google adapts a language on its platform, it will put some effort into producing some good tools.

Re:well...

[shutdown -p now]

I actually suspect it may be possible to write a translator that'd take a PE or ELF binary compiled with a normal compiler, and convert it to NaCl - replacing instructions and padding them as necessary.

Re:well...

[shutdown -p now]

Given their love for Eclipse in Android development department, I'd expect them to just ship it with Eclipse CDT.

Re:well...

[JonySuede]

And given how poorly Oracle has handled Java as a platform, it's future is becoming questionable.

That is so true, they shipped Java 7 with a shipload of bugs, I stumble upon one today. And I am pretty sure that i am not the only one as there was a guy in a Minecraft complaining about the same exception.

They have killed a lots of cool research project that I cared about, Microsoft would have funded them as they would have originated from there Microsoft Research Labs. I miss Sun; I might switch to the Microsoft completely and byte the C# apple. Almost all the good library from Java are ported. And it seems that since Windows 7 they have taken the conscious decision to stop sucking.

But that is not to say that Netbeans is bad. It's really good. It's just not Intellisense. It has it small problems and long-term problems. The small one is that it is too Java-centric. It attempts to use an AST for C++. Which is all fine and good except it doesn't know how to handle "friend".

According to this https://netbeans.org/bugzilla/show_bug.cgi?id=179205 it is supposed to be fixed since 6.7 but I did not test it so... I hate Oracle so much that I would not be surprised that they reintroduce it on purpose.

Re:well...

[derGoldstein]

VS is "slow"? Setting aside the other arguments, I've never heard of VS being called "slow". Compared to what? Not Netbeans, and certainly not Eclipse. Unless you're running it on a netbook, it's the fastest IDE out there -- certainly for C++.

Re:well...

[zlogic]

Javascript may be OK for small applications, but it's using Java+HTML5 to write complex enterprisey stuff is insane.

Re:well...

[derGoldstein]

Intellisense isn't just an autocomplete, it models the entire structure of the code. Classes, methods, function overloading, operator overloading -- it'll catch "deep" errors before you compile. Eclipse has a pretty good general autocomplete, but it's no intellisense.

Re:well...

[superwiz]

I don't think so. I think they are preparing for a long-term separation from Java. And Eclipse is, of course, written in Java. Actually, I am mostly hoping that they are. I am just thinking that a company which managed accurate identification of web-wide unstructured text should have no problems producing a tool which would be superb at assisting in production of structured text like C++ code.

Re:well...

[derGoldstein]

See the following:
http://mariusbancila.ro/blog/2011/06/20/cpp-renaissance-at-microsoft/
http://herbsutter.com/2011/07/28/c-renaissance-the-going-native-channel/
http://channel9.msdn.com/Shows/Going+Deep/Craig-Symonds-and-Mohsen-Agsen-C-Renaissance
It's true that MS it starting to push JavaScript/HTML5, but there's also a "return to roots" movement for C++.

Re:well...

[derGoldstein]

That's the first thing I thought as well. Eclipse is a good "delivery system" for their dev projects overall, I'm sure they have plenty of people already working on the general Eclipse project. But I think they might/should go further. Look at Aptana -- it's specifically designed for web development. They could design Eclipse "variants" that are specific to Android-programming and, possibly, some version that facilitates programming NaCl modules.

Re:well...

[St.Creed]

It has always amazed me that no other compilers do "as you type" compilation, since the difficulties are, while not trivial, quite easy to surmount. You can construct grammar trees and fill them online. During my CS study we built such realtime parsers in one of the courses as an assignment. This was in 1990.

Re:well...

[tyrione]

XCode will soon be updated with the baseline of LLVM 3.0/Clang 3.0/LLDB/LibC++ probably around October or November. C99 is 99% compliant in Clang and C++ is humming along with C++ and C++0x support: http://clang.llvm.org/cxx_status.html

By the way, Chrome uses LLVM/Clang to build against.

Re:well...

[shutdown -p now]

The above is not valid NaCl, since any indirect jump is encoded as a pair of AND/JMP instructions to ensure that the destination is 32-bit-aligned. Instructions cannot straddle 32-bit word boundaries, either (padded with NOP as needed). Thus, it is guaranteed that no jump will happen into the middle of an instruction. You can make it jump to the wrong instruction, but since we're dealing with segmented memory here, at worst you'll fuck up your own data and/or stack, and eventually segfault (which the sandbox can easily intercept and handle gracefully by indicating to the user).

See http://src.chromium.org/viewvc/native_client/data/docs_tarball/nacl/googleclient/native_client/documentation/nacl_paper.pdf

Re:well...

[derGoldstein]

I can't know for sure, but I think it's a matter of scope. How many levels of abstraction do you go through? How do you deal with generics? You might be able to do it with C, but when you've got C++/STL/Boost, there's just too much branching to do it real-time (I think...).

Re:well...

[DragonWriter]

Rumor has it MSFT is about to ditch .net developers in favor of HTML 5 + Javascript for "native" applications.

This rumor appears to be based on nothing more than the fact that in showing off a demonstration of new features of Windows 8, they showed off the ability to run HTML5+JS desktop apps (which, unlike the ability to run .NET apps, is a new features of Windows 8) and not the ability to run .NET apps.

Re:well...

[SanityInAnarchy]

albeit in a custom executable format, and I couldn't find information about the ABI...

As I understand it, there are two formats. I remember the nexes being derived from ELF, but I can't find it now. There's also the Portable NaCl, which is some form of LLVM bytecode, so that it can be compiled on the client so as to natively support any architecture, without having to ship them C source.

Re:well...

[gmueckl]

Unfortunately, Eclipse still tends to choke on C++ code a lot in my experience. I'm not writing particularly devilish C++ code, but I still find that it just gives up in situations when it clearly shouldn't. Code folding is starting to misbehave all of a sudden when editing files, sometimes Eclipse has no clue what possible completions are, although it did a fine job discovering two lines above the current one etc. I really wished this thing was more robust. It would help me alot.

Would be great

[mcl630]

This would be great if all major browsers supported it, but developing web apps only for Chrome is a now-starter for most of us.

Re:Would be great

[mcl630]

Non-starter that is

Re:Would be great

[shutdown -p now]

Right now, this seems to be intended for "Chrome web apps" (which also run on Chromebooks), not as a general purpose extensibility mechanism.

Re:Would be great

[binarylarry]

It's BSD open source though, so someone could write a firefox plugin to support NACL apps.

Please don't use C/C++

[GGardner]

The phrase "C/C++", that is.

C++, especially modern C++, is such a different language from C, that it makes no sense to talk about them as if they are the same. A decent programmer can learn everything they need to know about C in about two weeks. Modern C++ really takes years to really master. When I interview programmers, I'm immediately skeptical of anyone who claims to know "C/C++". Often, this means the most advanced "C++" feature they use is the // comment.

Re:Please don't use C/C++

[superwiz]

I have a better check for C++ programmers who write C-spaghetti code with classes: they don't have a favorite IDE.

Re:Please don't use C/C++

[shutdown -p now]

"C/C++" is not meant to imply that the languages are almost the same, or anything like that. Rather, it's the recognition that these two are the most popular languages that are compiled directly to native code, by a very large margin. Another aspect of this is that many C++ programs use C libraries (SDL, zlib etc).

Re:Please don't use C/C++

[bberens]

I feel the same way about people who claim that since they know C and/or C++ they could learn Java in a snap. Yes, it's very likely that you will not have great difficulty picking up the Java syntax, since it's C-esque. That doesn't mean you'll be a "Java programmer" in 6 months.

Re:Please don't use C/C++

[oursland]

Quit spouting your ignorance. There are features in C that are still not supported in C++. A commonly used one is VLAs.

So, no, C++ is not a superset of C.

Re:Please don't use C/C++

[JonySuede]

that is so true. I know C99 and C++ (but I did use C++ since 2001) and they are quite different.

And C++ only takes year to master if you try to know all the obscure corner case. If you don't abuse the template system as a turning complete language interpreted by the compiler, use operator overloading in a limited way, avoid reinterpret_cast, use variable scope for memory allocation and shared_ptr from boost when you really have to have a new, it is a fine language.

Re:Please don't use C/C++

[JonySuede]

I meant did not use c++ since 2001

Re:Please don't use C/C++

[clampolo]

Well. Once guy judges programmers based on whether they say "C/C++" or "C and C++". The other one judges them by what development environment they use. That is all you need to know to see how skilled those 2 are.

Re:Please don't use C/C++

[mswhippingboy]

It doesn't? Granted, it's not pretty, but "not supported" is a bit strong.

#include
using std::va_list;

.
.
.

va_list list; // for storing information needed by va_start

va_start( list, count );

for ( int i = 1; i <= count; i++ )

total += va_arg( list, double );

va_end( list );

Re:Please don't use C/C++

[mswhippingboy]

That #include should have been

#include <cstdarg>

Re:Please don't use C/C++

[tyrione]

The phrase "C/C++", that is.

C++, especially modern C++, is such a different language from C, that it makes no sense to talk about them as if they are the same. A decent programmer can learn everything they need to know about C in about two weeks. Modern C++ really takes years to really master. When I interview programmers, I'm immediately skeptical of anyone who claims to know "C/C++". Often, this means the most advanced "C++" feature they use is the // comment.

And C99 isn't your C89 equivalent nor is C1x the same as C99. With C99 being the baseline for OpenCL I expect C1x will be a big boon for Parallel Programming.

Re:Please don't use C/C++

[oursland]

Variable length arrays, not variable argument lists:

http://en.wikipedia.org/wiki/Variable-length_array

If you're trying to convince me that C++'s VAs are are somehow demonstrating C++ "supporting" VLAs, then you could argue that C++ supports virtually any construct because you can simply include a library or template that provides it. However, the C++ standard does NOT support VLAs, but the C standard does. As a result, standard C++ is not simply a superset of C.

Furthermore, if a developer writes C++ as if they were writing C for a C++ shop they will likely find themselves either unemployed or, more likely, simply not hired. The vice-versa is true with C written as C++. They are different languages with different inherent programming styles and failure to conform to them is a detriment to the team. (Please do take note that the OP of this thread was speaking directly about "C/C++" on resumes and hiring programmers.)

Yo Dawg

[Anonymous Coward]

I heard you like programming, so I put some programming in your program so you can program your program while you're programming.

Re:Yo Dawg

[derGoldstein]

Damn it, my keyboard... mod parent up or something.

Will never fly

[Have Blue]

There are just too many architectures capable of browsing the web now, and some of the most important ones will never support a feature like this (read: iOS). This is the new ActiveX, only without a dominating monopoly and OS integration to push it.

Re:Will never fly

[Trongy]

Maybe, maybe not. If people find it useful they will use it. Plenty used ActiveX back in the day and flash is nearly everywhere despite it's downsides. There are only two architectures that are important for web browsers right now, X86 and ARM. Native Client runs in the browser, it doesn't rely on OS support. If Firefox and Opera were to support it it would be available on a huge number of platforms, including iOS.

Consistancy!

[wasabii]

First a story about how .Net is being ignored. And now a story whose headline claims MS has been giving priority to .Net.

Ahh, slashdot.

Re:Consistancy!

[derGoldstein]

Check the timeline. Up until this year, .Net *has* been getting priority, to the point where they dropped intellisense for c++/cli in VS2010. Now MS is starting to push JavaScript for Windows 8, and Native(non-managed code) is starting to get better treatment. This isn't a contradiction, it's a change over time.

*yawn* More impressed with Javascript PC Emulator.

[dan_linder]

How's the "Native Client" a big step when we've already seen the Javascript PC Emulator:

        http://bellard.org/jslinux/

I guess a Chrome browser pulling up that page, the Javascript PC Emulator booting X to run Chrome to run a Native Client PC emulator would be a neat hack...

Dan

interpreter/VM

[sourcerror]

" It is not some kind of C++ interpreter or VM"

Actually, everything that's not kernel code "runs in a VM". Operating systens do memory address translation and bounds check (i.e. not violating other processes memory) during runtime.

Re:*yawn* More impressed with Javascript PC Emulat

[Windwraith]

Wow, that's so meta. How many beowulf clusters will be needed for that?

C++ blows on multi-core and multi-platform

[SplashMyBandit]

C++ is useful for some tasks. However to make it work with the new multi-core CPU architectures is a total PITA. Not only do you have to choose a non-standardized threading implementation you also get a lot of headaches as to which thread owns which object (since you don't want to clean up too early or too late). That's one of the reasons Java and C# are so popular and even people with a huge amount of C++ time (like me) will never use C++ as our first choice again. Basically for whatever small percentage of extra speed you get with C++ on *one* core is totally lost when Java/C# uses multiple cores. Even if you make C++ multi-threaded and garbage collected it requires a much larger development time to get what Java/C# has built in. Even worse than the multi-core issues with C++ is the fact that it is generally not multi-platform (at least for non-trivial programs using graphics, networking sound etc) due to the platform dependencies of the libraries. These days the computing environment is becoming more heterogenous, not less. Aside from the supposed bragging rights of C++ programmers (feel they are somehow superior by using it, but fail to realize the more experienced you are the more you wanna get things done in the easiest way, not the hardest/l33t-est way) there is not much to recommend C++ apart from the memory footprint (and only a few people work on systems that are *that* memory constrained these days, most single-board-units have *huge* quantities of memory, eg. 512 MB compared to the old days).

Re:C++ blows on multi-core and multi-platform

[alexmin]

to make it work with the new multi-core CPU architectures is a total PITA.

HFT industry disagrees. But those devs keep quiet, they do need sluggish C-pound lovers on the other side of the trade to make money.

Re:C++ blows on multi-core and multi-platform

[SplashMyBandit]

HFT is a miniscule drop in the ocean. C++ is sluggish compared to assembler, but that doesn't make assembler a better purpose *general* solution language. Again, you're taking the snobby argument that because C++ is good for your tiny niche that it follows that it is better for all applications and then you proceed to rag on C# guys as if they all sucked. Personally, I'm no C# fan, but I'm not stupid enough to think C++ is better for the general scope of applications. Plus, you ignore the fact that in many cases JIT languages are actually faster than C++, due to runtime optimizations not possible to correctly predict at compile time, and the fact that the simpler languages (viz C++) allows some optimizations that cannot be made otherwise (which is why FORTRAN is still so damn fast).

Re:C++ blows on multi-core and multi-platform

[windwalkr]

I would think that most C++ programmers consider the lack of GC to be a feature, not a limitation. Speaking for myself, that's one of the major reasons why I prefer C++ over other 'more modern' languages- GC introduces a whole class of potential bugs and limitations that don't exist without it, and encourages the programmer to ignore object life cycle. I'm not saying that GC is all bad, but neither is it clearly better than the alternative for complex programs.

Regarding multithreading, program architecture is far more important than your choice of language. If you design a sensible flow of information through your program, you'll end up with an efficient and (relatively) bug-free result. If you have poor flow, you'll end up with horrible performance and deadlocks. A 'safe' programming language like Java/C# doesn't protect you from this.

You're right that C++ lacks standardised cross-platform libraries; the situation is improving, but slowly. It's not a deal-breaker in many cases but it is a cost that needs to be considered. The same is actually true of the other languages you name to greater or lesser degrees- C# really isn't practically cross-platform in many cases, despite Mono. Java is known for having poor cross-platform UI support. At least they get the lower-level primitives right though.

Re:C++ blows on multi-core and multi-platform

[Puff_Of_Hot_Air]

Multi-core may be new, but multi-processor certainly is not. Do you think multi-threading was only thought about since the advent of multi-core processors? I am a C# and a C++ programmer, and I started life as a low level C programmer, so I can see the pros/cons of the various approaches. .Net (and I assume Java) is clearly the better option for the majority of application development being performed today. The reasons for this are the extensive libraries, large communities, and highly sophisticated tool sets (such as the IDE, unit testing integration, performance profiling, etc). However there is one glaring exception to this, and that when you need to scale. If you need to scale, CPU and memory will frequently become your bottle-neck, and your work at minimizing these will define the limits of your scaleability. Here is where C++ really shines, I can code using all the modern safe techniques, but I can get down to the metal to optimize the hot path when I need to. I can take the smartpointers off those transactional objects that are generated in the millions to save memory and speed. I can't do this in .Net. In summary, if you are writing a desktop app, use Java or .Net, if you are writing a server app, use C++ or equivalent. I love both for different reasons; just pick the right tool for the job!

Re:C++ blows on multi-core and multi-platform

[njahnke]

ever used qt?

Re:C++ blows on multi-core and multi-platform

[SplashMyBandit]

Good points. I'd like to add that the best (and probably only) way to end up with with an actual defect-free (or fairly close to it) program is a proper testing strategy (eg. automated unit and integration testing).

Re:C++ blows on multi-core and multi-platform

[SplashMyBandit]

Why generate temporary objects in the millions? drawing from an (garbage-collected) object pool can often make a colossal difference to performance.

Re:C++ blows on multi-core and multi-platform

[SplashMyBandit]

Yes. It is awful macro madness at its worst. It's also not particularly natural from an object-oriented point-of-view either. In short, I'd much rather use Swing or Google Web Toolkit than QT.

Re:C++ blows on multi-core and multi-platform

[Puff_Of_Hot_Air]

Why generate temporary objects in the millions? drawing from an (garbage-collected) object pool can often make a colossal difference to performance.

Let's say I'm an I/O server processing the data from a moderate number of clients say 5000. These clients are sending me updates for a small data set, let's say 2000 points, once a second. My job is to pluck that data off the wire, format it as required by the rest of the sub-systems, then commit it off to say a database. Say it takes about one second for me receive a response from the system on average, before I can dispose of the data update. 5000*2000, means I've got about 10 million little data items I'm processing per second. Let's add another wrinkle. Worst case, I need to buffer that data in the case of a lost database connection for up to 15 min to give enough time for the database to restart or some such thing. 9e9 data updates in memory. Lets say each update consists of a 32 bit number, a 64 bit timestamp, and a 16 bit status field. That's 14 bytes in total. 14 * 9e9 = 1.8e11 bytes. 117.4 GB. Shit, I may be a big server, but I don't have that much memory!. OK fine, maybe I can make my safety margin smaller, lets just go for 4 min, if we can last 4 min, there will be just enough time for a redundancy switch-over for my database. Still need 31.3GB of memory. My server has 8 cores, and 16GB of ram, but it's still just not quite enough. 1.5 minutes. OK, now we can handle it, 11.7 GB. I also need to keep a reference to all these little data updates. If I go for a smart pointer, that's sizeof(std::tr1::shared_ptr) which = 8 bytes. 6.7GB. Dammit!, still over the 16GB. What if I use a bald ptr? sizeof(thing*) = 4 bytes = 3.35GB. Just fits. There is also a performance penalty for creating my smart pointers. This is obviously a contrived example, but it's not too far off the kinds of problems that have had to be solved in my current place of employment. If you go managed for this kind of stuff, the overheads become too large and the ability to scale is greatly impacted. I know this, because we tried it and just weren't able to get the scalability into the same order of magnitude. As I said before, just use the right tool for the job.

Re:C++ blows on multi-core and multi-platform

[sgt scrub]

I'm a serious newbie when it comes to C++ but... Isn't the latest version going have boost threads moved into the standard library. Also, aren't destructors the same as, or better than, garbage collection?

Re:C++ blows on multi-core and multi-platform

[SplashMyBandit]

Regarding the destructors, the problem is when you have several threads accessing memory allocated on the heap. Which thread gets to delete it and when? Then you end up reference counting and doing garbage collection - or allocating everything on the stack. This is problematic when your stack frame goes away. Either that or if you have long-lived objects that you have to try and clean up yourself if you want to release memory before program completion, but then as you program grows you find it hard to manage, so you starting writing yourself a framework to do it for you and end up re-writing a budget version of the Java/C# garbage collection and memory management strategies (which is now very good in Java's case with the G1 'garbage first' collector). With regard to Boost threading, it'll work for sure, but it'll never be as easy or as elegant as a language that was designed with synchronization in mind from the beginning. Even if the source code is cross-platform (although in C++ there are always niggles) the compile and build environment often is not. You can save yourself the hassle by choosing something like Java and spend more time fixing your domain problems instead of implementation problems. Like I said, after doing C++ for a decade and then moving to Java for the past decade (occasionally still doing C and C++ where I had to for native integration or embedded stuff) there's no way I'm personally going back. I'm just trying to impart some of my experience and save people the hassle of a decade of dealing with C++, when really they probably want to be solving problems instead.

Re:C++ blows on multi-core and multi-platform

[SplashMyBandit]

Thanks for taking the time to elaborate. One question I would have is if your clients are actually sampling data at 500 microseconds per point? Otherwise, why don't they send deltas since their last update (perhaps this is happening). What I'm trying to determine is if the architecture has them sending the same information again and again and again. Would it be possible to exploit the timestamp information in the data to reduce the requirements to store everything. Do you need to update the data set once a second. Otherwise you could load a dataset, do the update, dump the data and continue. Each operation would be slower than how you are doing it now, but you spread it over more machines. You would reduce the power of the machines until you reached the price/performance minima - it would also give you a lot more redundancy - this is the strategy Google appear to use. Also, using a 'smart' pointer or garbage collected object per data point is madness (I made the same mistake 15 years ago when Java came out and I was doing a lot of astrophysics calculations. Once I re-organized my data structures I found that the memory requirements for properly thought about structures did not scale badly as the size of the data increased [except in the very small scale end]). Surely you'd have a class per data set, which reduces your memory overhead by three orders of magnitude which allows you to use a newer programming language which increases your productivity by close to an order of magnitude as your codebase gets near the million line mark. If you use a class to represent each data set with a 64-bit reference plus some 64-bit references to hold each array of the data you are using (one for each database column, and use native types for the array elements where you can) you might use half a dozen references for a total of 48 bytes per in-memory dataset. That means you'll use 5000 * 48 bytes in garbage collected references for your in-memory data (ignoring my suggestion of using more machines). That's around 250 kilobytes of memory to get garbage collection, nice multithreading and synchronization support, the ability to use JVisualVM (which is just a fantastic tool for connecting to any running Java process to see where the memory and CPU is used - just like any profiler - except you don't have to compile anything different or start the program in a profiling mode, you just attach to it). Anyway, sounds like you could organize your datasets to be a lot better organized so that the garbage-collected references were totally negligible compared to your in-process data. Lots of people (including me) have processed much huge datasets using 'managed' languages, but you have to spend some time thinking of optimising in space in time rather than the brute force direct path that C++ coders often take (and since C++ can be used in this way it is an advantage, but you will always end up running out of resources at some point, using C++ just delays it a little in some cases). Good luck.

Re:C++ blows on multi-core and multi-platform

[Puff_Of_Hot_Air]

As I pointed out earlier, this was a completely contrived example. On our real system we are looking at data volumes of about this kind of changes/second from which I based my calculations. The actual usage of shared_ptr and it's impact on memory usage/performance is far more complicated than what I demonstrated in my example, and I'm not going to try and explain it all here. To clarify further this is a code base of approx 20 million lines or so (last I checked about 3 years ago), and I am describing the data volume on one machine. It is expected that the system will scale linearly across multiple machines, but the data volume/machine is the all important factor from the end users cost calculations (licensing costs are a big factor here). My point was to try and show that little things such as a shared_ptr, can have a large impact when you have so many operations being performed per second (as we do). As I also said, I code in both .Net (which i understand to be very similar to Java) and C++, and we did go through a process of trying to perform our I/O via managed code, however the performance just wasn't there (particulary with memory overhead). Outside of I/O we use .Net for all new code. C++ still has it's place in high performance code, but it isn't quite as nice to use, and is harder to do "right". I love them both.

Is it really the parser?

[SanityInAnarchy]

So, Chrome already sandboxes JavaScript in some of the same ways that they'd sandbox NaCl, but it's not the parser. JavaScript is a relatively simple language, syntactically, and any decent implementation isn't going to be fucking around with it on that level.

My guess is that it's a choice of which APIs you expose and when they're allowed to be called. Since JavaScript can't generate code which ultimately does anything other than call methods or access properties, it entirely comes down to which methods or properties you expose.

I don't think this will be better than JavaScript. I do, however, think it will be better than ActiveX. At the very least, it's actually sandboxing stuff.

Re:Is it really the parser?

[TheRaven64]

JavaScript is a relatively simple language, syntactically

Having worked on both a JavaScript compiler and LLVM, I can tell you that LLVM IR (used by NaCl) is a lot simpler than JavaScript. JavaScript's syntax has a lot of strange corner cases, but the semantics are really baroque in places. In contrast, LLVM IR is an assembly language for a virtual RISC architecture, with clean and orthogonal semantics.

That doesn't mean it's easier to secure. The obvious holes are gone, but it's probably possible to do some things involving calling functions with the wrong signature (which NaCl has to allow due to the insanely strict type system of LLVM) to jump to computed addresses. If I were trying to attack it, then I'd start by seeing what happens when you call a function that returns a structure with the type signature of one that doesn't. That should let you corrupt the stack, and should let you jump to an arbitrary address (I've done this by accident when writing an LLVM front end), so it should let you run arbitrary untrusted code by inserting some machine code in a structure.

Looking forward to it

[sproketboy]

Looking forward to stack smashing hacks again. Yay!

Re:CHROME 14?!

[aardwolf64]

Just wait until next month when they're in the triple-digits...

Am I using Chrome 143 or 142? ARGH!

PNaCl addresses this concern

[DragonWriter]

Note that NaCl code is only cross-platform in the sense that it's OS-independent. Being true native code, it's not processor-independent; if you want NaCl modules to run on x86, x64, and ARM, for example, you need to have compiled three separate versions of your NaCl binary, one for each architecture.

For now; though with NaCl now in a non-dev version of Chrome (its been in dev versions since 7 or so, I think) that probably means that there is going to be more focus on getting PNaCl (Portable Native Client) ready for public consumption, which will see code deployed on the web as LLVM bitcode and compiled to native code at the client, at which point you'll have real portability.

A quick googling finds that PNaCl is scheduled for Jan. 1, 2012 Beta release on Mar. 1, 2012 general release.

Re:PNaCl addresses this concern

[kripkenstein]

For now; though with NaCl now in a non-dev version of Chrome (its been in dev versions since 7 or so, I think) that probably means that there is going to be more focus on getting PNaCl (Portable Native Client) ready for public consumption, which will see code deployed on the web as LLVM bitcode and compiled to native code at the client, at which point you'll have real portability.

It is still not clear how much portability PNaCl will give, and at what performance cost.

Let's say that it supports x86, x86_64 and ARM. Is that enough? I would argue not, because it puts a big limitation on what future architectures can look like - because LLVM bitcode is not truly portable, it still encodes many assumptions about current architectures.

Of course JavaScript does as well - everything does. But JavaScript has far fewer such assumptions, making it much easier for someone to invent a new CPU and have it run the web well. With NaCl, we might lose that.

The argument is that NaCl is needed because otherwise performance will suck. But JavaScript is already almost as fast as languages like Java and C#, which are considered 'fast enough'.

Re:PNaCl addresses this concern

[PCM2]

Last time I tried regular-old NaCl, the startup time for NaCl modules was already significant. Really the whole experience reminded me of nothing so much as Java applets circa 1997. I'm sure performance can be enhanced in various ways, but at this point I'm still skeptical that NaCl will have much more appeal than Java did back then. The reason ActiveX was successful was because it exposed a lot of Windows functionality for browser-based apps -- it wasn't just wedging an immature platform into a little box inside a browser window. NaCl doesn't seem to be doing anything as compelling so far.

Re:PNaCl addresses this concern

[DragonWriter]

Of course JavaScript does as well - everything does. But JavaScript has far fewer such assumptions, making it much easier for someone to invent a new CPU and have it run the web well. With NaCl, we might lose that.

NaCl is not, in my view, a replacement for JavaScript, its a tool for certain purposes for which JavaScript is problematic (one might be re-use of substantial legacy code bases that aren't in JavaScript, but otherwise might be useful in browser-based applications -- in the long-term, you might want to replace them with JS, but recompiling for NaCl should in many cases be substantially cheaper than reimplementing from scratch; there's probably some performance-related use cases, too, but Google's done a lot on JS performance, and providing high-performance browser features that JS can drive for common uses cases, like 3D graphics, so those will probably be in edge cases.)

So I don't see NaCl, even if ends up being somewhat less easy to port to new architectures than JS, reducing the portability of the things the web is good at now, it just provides options that make the web good at things its not good at now, with potentially somewhat less future portability of those new capacities (though if they become important, resources will naturally get diverted to developing portable solutions, whether its moving PNaCl to new platforms or providing more portable platforms for the use cases that PNaCl enabled.)

Re:PNaCl addresses this concern

[dirtyhippie]

Java and C#, which are considered 'fast enough'.

Not for games or video processing.

Re:PNaCl addresses this concern

[kripkenstein]

NaCl is not, in my view, a replacement for JavaScript, its a tool for certain purposes for which JavaScript is problematic (one might be re-use of substantial legacy code bases that aren't in JavaScript

You definitely do not need NaCl for that. emscripten lets you compile C or C++ into JavaScript (see the demos in that link for examples). There are similar projects for other languages (but C/C++ is the most important case, since you can even compile the C code of CPython and run Python on the web using that).

Re:PNaCl addresses this concern

[kripkenstein]

Java and C#, which are considered 'fast enough'.

Not for games or video processing.

Actually for both of those cases, a lot of the intensive stuff would end up being in a shader on the GPU anyhow, so it would be fine in JS (using WebGL). But there are other things, like AI or physics, that is true, which are more problematic. NaCl might not be a solution for them though - it's sandboxing introduces overhead.

Re:PNaCl addresses this concern

[TheRaven64]

NaCl is basically LLVM bitcode. LLVM IR is not intrinsically platform independent, because things like calling conventions and the size of various types are lowered before generating LLVM IR from source code. This is why it's not possible to distribute C programs in a platform-independent form in the general case in any form other than source. The first pass in compiling C includes files (including system headers) and expands macros. You get a load of #ifdef blocks removed depending on what the predefined macros from the compiler are (e.g. __linux__, __lp64). You then compile, and you get a load of static functions from the header inserted into the code. For example, the isupper() function in FreeBSD and GNU libc have very different implementations, so the LLVM IR for a C file calling this will not work on the other.

NaCl works around this by specifying that the target is 32-bit, little endian, and has a fixed calling convention. The IR for this target is then compiled to native code by LLVM on the client. This means that NaCl code can call the libraries that Google ships, but can't call native platform libraries.

Re:PNaCl addresses this concern

[kripkenstein]

Yes. But what if the arch you are on is 64-bit big endian? And it does 32-bit loads/stores slowly - or even faults on lack of 64-bit alignment? You have a LOT of challenges in even running that 32-bit little endian code there at all, let alone fast.

Re:PNaCl addresses this concern

[TheRaven64]

If you're on a 64-bit architecture, then it will just use the 32-bit subset. Remember that you're not (directly) calling any native code, so you're going to be using Google's malloc(), while will only ever return addresses below the 4GB line. Currently, the only 64-bit big-endian architecture that LLVM supports is SPARCv9, and that's classed as experimental, so this issue hasn't appeared yet, but the SelectionDAG phase will most likely turn 32-bit loads into 64-bit loads and shifts if the architecture doesn't support 32-bit loads and stores. Will it be fast? Probably not as fast as real native code optimised to the target, but probably faster than a something like JavaScript.

Re:PNaCl addresses this concern

[kripkenstein]

If your code does this: a = alloca(4) b = alloca(4) [..] d = load64(a) Then the results there will depend on the endianness of the platform. And if that alloca wasn't 64-bit aligned, it might fail on some platforms, etc. It's very difficult to generate a fast, low-level assembly that doesn't limit you. That's why LLVM doesn't even try. Whether PNaCl will succeed is a big questions.

Game consoles are also big-endian last I heard.

Not going to be limited to C/C++ for long

[DragonWriter]

Yes, because what I really want to do is use a language that is terrible at string processing! If this were perl, python, or ruby, I might care. I'd rather learn javascript from scratch, than do string processing in C/C++.

If you can run compiled C/C++ code in the browser, you can use pretty much any language you want, since "compiled C/C++ code" includes the compilers and interpreters for most other languages as well. I'm sure there will be implementation tweaks needed to many existing language implementations to get them to work in the NaCl environment, but it'll be a lot lower barrier than reimplementing the compiler to target javascript, or reimplementing the interpreter in JavaScript.

Re:Good luck, you'll need it.

[derGoldstein]

History says you can program the same performance and capability as C++ in .NET, Java, C#, Scala, Ada, and Haskell

What does history say about cross-platform support? Or the availability of a huge existing codebase? Or the fact that practically every major software project is developed using C++?

If you want to put your money on Scala, be my guest. There's always a cool-new-thing, and it's usually fun to play with. But where's your paycheck coming from? If it's Java or C#, then start updating your resume. Java's legal crap (and Oracle crap) is pushing companies away, and .Net is getting gently walked off the plank by MS itself. The only languages that keep making a comeback (when people need a solid ground to work on) are C and C++. So far there aren't any exceptions.

So wrong in so many ways...

[SanityInAnarchy]

This is the new ActiveX,

It's got a sandbox. ActiveX didn't. ActiveX is for writing plugins; this is for building faster webpages.

only without a dominating monopoly

Google doesn't dominate search?

and OS integration

Granted, it's not integration into a monopoly OS, but it's integrated into Chrome OS.

Now, on to the real points:

There are just too many architectures capable of browsing the web now,

Really?

I count three that anyone cares about anymore: ARM, x86, and x86_64. If you're feeling generous, PPC and PPC64. And if you compile one nacl binary for, say, x86, that'll run on Windows, Linux, and OS X. Only reason the x86_64 plugin doesn't do the same (yet) is that Chrome, like all browsers, has stuck with 32-bit only for Windows and OS X until various plugins (*cough* Flash) get proper 64-bit support.

There's also an LLVM variant in the works. You compile to LLVM bytecode, the client compiles it to native code when it's downloaded.

and some of the most important ones will never support a feature like this (read: iOS).

Somehow, I think Android is more important than iOS, and for that very reason.

But how do you know this would never be supported on iOS? It already allows alternative browsers, and that's assuming Apple doesn't adopt this idea. You could make a point that Apple has a vested interest in keeping web development limited on iOS, but so far, they seem to have done just the opposite -- Safari is generally recognized as a decently modern browser with decent standards support, and they often introduce new and interesting things of their own (CSS animations, some of them 3D IIRC).

Now, it may never fly for other reasons, like the fact that very few applications need this much of a performance boost over JavaScript without also needing more than NaCl offers yet (like fast 3D -- can I draw from my NaCl library to WebGL without going through the browser and JavaScript?)

Still, it's an interesting enough idea, and this seems to be the direction things are going. Suppose I can deliver a modern game to you in a browser -- with bandwidth getting faster, I bet I could get you into a demo of my game in under a minute, without you having to install it from some random download site. And even if it were Chrome-only, that's still more portable than Steam -- but there's no reason it has to be Chrome-only.

My first commercial banking web site

[geekoid]

I wrote was in C. My next in C++

It's harder, but the results are faster. Not that it matters anymore, but in 1995 it sure as hell did.

NaCl is an anti-web abomination

[pslam]

NaCl is not so much about executing C/C++ code as it is about executing native compiled binaries. This has issues:

• If I compile my C++ code for x86, I can run it on x86 browsers (well, specifically only Chrome on x86).
• Ok now I have a cell phone, which is ARM. Guess I have to compile for ARM.
• Now I have to compile everything for both x86 and ARM.
• Ok now some other architecture is popular, but it won't run x86 or ARM.

It's incredible Google is even pushing this. It's so anti-portable and in concept anti-web.

There is a "portable" version of this, called "Portable Native Client". This means, of course, that NaCl is actually "Non-Portable Native Client" and that should itself be a clue. The "portable" version uses LLVM bitcode and a virtual machine. So more than a decade later, we've basically reinvented Java virtual machine applets minus the gigantic runtime (and language of your choice).

The only people who could possibly benefit from NaCl are Google. There's no general case use for this, and pushing it as standard into Chrome is a nasty move. Mozilla also reject the idea of NaCl. I believe Opera rejects it too (lacking a link). So, why is this being pushed?

Re:NaCl is an anti-web abomination

[shableep]

So, why is this being pushed?

Chromebook + Chrome Web Store

Re:Good luck, you'll need it.

[inglorion_on_the_net]

Or the fact that practically every major software project is developed using C++?

The page you linked to doesn't really back up that claim. It says right at the top that this page lists only software written in C++. Sure, there is a lot of software being developed in C++, but there is also a lot of software being developed in C (e.g. Linux, most of GNU, most projects on Freshmeat), Java (a lot of commercial development, and a growing number of open source projects, too), and don't forget PHP and JavaScript, which are widely used for programming for the Web (e.g. by Google and Facebook).

Of the applications I use on a daily basis, only my web browser (over time, this has been Opera, Mozilla, Konqueror and Firefox) is written in C++. Most of the rest is written in C, with a handful of things written in Perl and a handful in Ruby. Then again, I don't use Windows. It seems to me that C++ and C# are much bigger there than in the Unix world.

The purpose of NaCl, IMO...

[tangent3]

...is to allow the reuse of code that has already been written in C or C++

At the same time, it makes it easier to port applications and games that have already been written in C or C++ to run in a web browser, hosted on a webpage.
With the NaCl port of Qt, it will also be easy to write applications that can be built to run on various platform, including NaCl.

Re:The purpose of NaCl, IMO...

[sgt scrub]

With the NaCl port of Qt

Huh wha...! That would be really cool.

Re:End of .net ?

[greggman]

Native Client (NaCl) is an environment for running native code. That means you can run any language you want. There is already a version of Mono for NaCl, Python, and others.

Version compatibility

[clenhart]

I've been following NaCl, and it worries me that the compiled code only works on a particular version of Chrome. NaCl 0.5 only works with Chrome 14, 0.4 works with Chrome 13, etc.

http://code.google.com/chrome/nativeclient/docs/running.html#browser

Re:Version compatibility

[tangent3]

Did you read the part that says
"The need to match versions of Chrome with versions of the SDK is temporary; this restriction will be removed once we stabilize the Native Client application binary interface (ABI)."

I'm feeling old...

[laffer1]

I get it. The Google team must have people just out of college in there that never used Netscape. Seriously, this is called Java Applets. They ran in a sandbox too. Netscape 2 or 3 had a bunch of holes in it from escaping the sandbox. It's been done before! Aside from minor security improvements, it's active x too.

Let's find out how insecure it can be. Let adobe write an app for it and then give security researchers a few weeks.

Worst of all, they used C++. LLVM has terrible support for C++. It's getting better, but it's not there yet.

Re:I'm feeling old...

[Ant P.]

Good luck breaking out of a seccomp sandbox where the only syscalls the OS gives you are read() and write().

Re:I'm feeling old...

[laffer1]

Yeah it's not like browsers ever have security holes in their APIs... oh wait they do. You're assuming the "HTML5" interface will be secure. I'm not.

Re:Low level?

[rubycodez]

yes, they are the high end of low level languages, one step above assembly langauge. They certainly are not high level languages like Python, or LISP