Chrome Is the New C Runtime

New submitter uncloud writes "Cross-platform app development is more important than ever. But what about when you need the features and performance of native code, across platforms? And you're a startup with a small team and impossible deadlines?" His answer? Take advantage of cross-platform Chrome. From the article: "Out of necessity, the Chrome team has created cross-platform abstractions for many low-level platform features. We use this source as the core API on which we build our business logic, and it's made the bulk of our app cross-platform with little effort. Most importantly -- Chrome code has been battle-tested like almost nothing else, with an installed base in the hundreds of millions. That makes all the difference when you want to spend your days working on your company's business logic instead of debugging platform issues."

Comments

Bloat.

[qubex]

This is how bloat begins: with an apparently clever insight that ignores actual common sense.

Re:Bloat.

[qubex]

Not only are you assuming that a web-browser is already loaded, you are also assuming that that exact web-browser is loaded.

Re:Bloat.

[nurb432]

A few remember, but we are not making consumer devices.

Re:Bloat.

[gbjbaanb]

someone didn't read the article....

firstly they aren't using Chrome as a platform, they're using the libraries that Chrome uses to build their apps, also that the chromium dev kit lets you specify which libraries you want to use, and thirdly they're using C++ to build their code so the bits they don't use just don't get compiled into the final program. And of course, they're using c++ instead of some crappy bloated other system that comes with every manner of crap already installed in the language or an interpreted mess that is bloated to hell anyway.

So tell me, what's so wrong with their approach - using cross platform libraries that just happen to be written by the Google boys?

Re:Bloat.

[Anonymous Coward]

Why is that "-1, Flamebait"? For crying out loud, he's one of the only posters to correctly identify the facts in this story:

- It's the general, lowest-level libraries of Chrome that are being discussed here, not the Chrome browser itself.

- C and C++ do have a superior compilation and linking model, limiting the inclusion of unused code.

- C and C++ do offer huge performance benefits over Java, Ruby, and JavaScript.

- C and C++ apps don't require huge runtimes like the JVM, a Ruby interpreter or a JavaScript interpreter.

- C and C++ do offer superior portability. Their code runs just about everywhere you can imagine.

Mod the parent up. He's one of the few who isn't spewing bullshit in this story's discussion!

Re:Bloat.

[dkf]

So tell me, what's so wrong with their approach - using cross platform libraries that just happen to be written by the Google boys?

The fact that it's been done before many times? Or perhaps the fact that there are lot of platforms out there that have never seen a browser and which have never had Google testing the library stack on them? There's a lot of diversity once you're outside the consumer market, even now.

Re:Bloat.

[Anonymous Coward]

Because you really need a JavaScript interpreter for your C programs to run.

Re:Bloat.

[martin-boundary]

Well for one thing, the Google boys like to spy on us.

Re:Bloat.

[tibit]

They had alternatives. For native C++ development, they could have used Chrome's platform abstraction, Mozilla's, Apache's, or Qt. I'd say that going with Chrome may be a bit against the grain, but hey, if it works for them, it works for them. I wonder how well the damn thing is documented, because it's hard to beat Qt's documentation.

Re:Bloat.

[quax]

Insightful only if you haven't read the article or didn't understand it.

As even the headline stated they use it as a library to compile against.

/. has really dumbed down considerably when people fail to grasp this and moderate this cluelessly.

Re:Bloat.

[beelsebob]

You... you don't understand how operating systems page memory.

Hint: both applications will get access to the same (read only) pages that contain the library.

Re:Bloat.

[Anonymous Coward]

You're making several blatantly incorrect assumptions:

1) You're incorrectly assuming that the two or more apps are using the exact same shared libraries. This is not necessarily true. Many apps have their own private copies of such libraries, preventing such sharing.

2) You're incorrectly assuming that the apps are linked against the same version of the library, even if all of the library files are publically shared. If they're using different versions of the library, then sharing won't occur.

3) You're incorrectly assuming that the app or apps haven't been statically linked, which again prevents sharing of common code between distinct applications.

4) You're assuming that Chrome or some other app has already provided these common libraries. That very likely isn't the case. The Chrome binary was nearly 100 MB last time I checked, so it's likely that this core code is already linked in to the Chrome executable and not shared.

Nice try, buddy, but please know what you're talking about before you start talking about it.

Re:Bloat.

[Anonymous Coward]

If you only get 2x improvement on real code, your C sucks.

Re:Bloat.

[Hognoxious]

And you're assuming it's installed, which it isn't if you're using RHEL 5.

Re:Bloat.

[celle]

" C and C++ do have a superior compilation and linking model, limiting the inclusion of unused code.

- C and C++ do offer huge performance benefits over Java, Ruby, and JavaScript.

- C and C++ apps don't require huge runtimes like the JVM, a Ruby interpreter or a JavaScript interpreter.

- C and C++ do offer superior portability. Their code runs just about everywhere you can imagine."

      Replace 'C' with tweety and 'C++' with foghorn leghorn and you get my views. They aren't the same. And I haven't heard anything about the long C++ compile times yet.

Re:Bloat.

[celle]

"And you don't have the argument that "they're only using small parts of it". In fact, according to TFA itself, they are using most important parts of it."

      And what happens if Google decides they're a annoyance?

Re:Bloat.

[quax]

It is Open Source code with a BSD style license. Google can't just disappear the currently released source code.

If they want to move to a closed development model you could fork the code.

Re:Bloat.

[quax]

From the article I glean that they are developing some major business app. Usually if you want to make this platform independent you go with Java. Not exactly light-weight either.

Re:Bloat.

[Jane Q. Public]

Well, that's certainly true. But keep in mind that at least Java uses a common run-time, which most people already have.

Re:Bloat.

[HiThere]

What's wrong with the approach is that there isn't a link to API documentation, so you can't quickly judge how well it would fit your project. Source code takes a LOT longer to review.

If I were convinced enough, I could download the source and run it through DOxygen, but that's not much good unless the code has been properly documented. Is it? Not a clue. Yes, if I get convinced I can do it myself, but I take a lot more convincing if I can't see the API ahead of time.

This was a piece of PR fluff. Well done, but shy of all useful details. Yes, libraries are a very good idea. Why should I prefer *this* set of libraries? He doesn't say. He just says "Hey, it's great!". (Well, he does say in *very* general terms, but because they are so general, you can't prove hime wrong, which means he's not usefully right, either.)

Re:Bloat.

[HiThere]

Qt has many advantages. I, however, don't like 16-bit characters. (Possibly this is because of experiences with Java.) Either they should use utf-8 or utf-32. Or both. And the heavy emphasis on latin1 in the documentation of Qt is a real turnoff. (Yes, you can avoid it, but yeesh...the only useful thing to do with latin1 is to convert it into utf...either 8 or 32, depending on your purpose.)

OTOH, I've no reason to believe that Chrome libraries are any better. If the *have* a documented API, he didn't mention it, and didn't provide any links. Also, although he was pushing it as a C library, in the comments he reveals that much (most?) of the library code is in C++.

Re:Bloat.

[MikeBabcock]

Obviously you've never written code for a Windows system. Shared memory pages for libraries is so incredibly rare it isn't funny. Also, because the Windows DLL interface isn't intelligent enough, most people end up having to distribute their own copy of any libraries they use anyway so they can't be shared with other applications.

Re:Bloat.

[Anonymous Coward]

Qt has many advantages. I, however, don't like 16-bit characters. (Possibly this is because of experiences with Java.) Either they should use utf-8 or utf-32. Or both.

QT5 now uses utf-8 as its default character encoding.

Re:Bloat.

[quax]

"... which most people already have."

Yeah, that's the theory. With business apps this has turned out to be almost a joke. Any friggen' client (Oracle, SAS, SAP you name it) brings their own private Java run-time (typically outdated) because that's the one that's tested and supported.

Re:Bloat.

[Jane Q. Public]

Well, that's a good point. When I last upgraded my OS, certain applications insisted that I have a JRE that is a version or two behind the one that was bundled with OS X. Maybe it was planned obsolescence on their part, but if so, it backfired: I'll be damned if I'm going to go out and buy new copies just because I upgraded my OS. I'll find something else.

Re:Bloat.

[aminorex]

To lump Java with Ruby demonstrates utter disregard for actual performance in favor of ideological blinders.

Re:Bloat.

[HiThere]

Thanks. That's VERY good to hear.

Re:Bloat.

[tibit]

Use of a variable-length encoding for internal storage in a string type is really introducing a lot of runtime inefficiency, so it's best avoided. IMHO it was a valid tradeoff between flexibility and performance to use UCS-2 - a fixed-width encoding, as opposed to say UTF-16. It also reduces storage by 50% compared to using the fixed-width UTF-32, but makes some less-used code points non-representable.

There's nothing "emphasized" about latin1 in Qt, not even in Qt 4. These days you're supposed to encode your source code in UTF-8, and set this as the default encoding for 8-bit-to-QString roundtrips. I haven't used latin1 in Qt 4 code in a long while now.

Re:Bloat.

[spitzak]

You are very mistaken about the "inefficiency" of a variable-length encoding.

There is no useful string algorithm where the Nth unit of the string is "interesting" without first looking at the N-1 preceding units in order to calculate N. In that case you can replace N with the offset into the variable-length string, since this is calculated in constant time as a side-effect of looking at the earlier units.

Searching is entirely unaffected by variable-length encodings, provided they are self-synchronizing, which UTF-8 and UTF-16 are.

There is also the problem that useful "units" are not fixed-size. Normalization forms make all Unicode encodings variable-sized.

I suspect also you think UTF-16 is fixed-size, which it is not. Sorry. All Unicode code points after U+FFFF are 4 bytes, and all before it are 2. It is a "fixed sized encoding of UTF-16 code units", but it is equally valid to claim that UTF-8 is a "fixed sized encoding of UTF-8 code units".

I think you are correct that you can change Qt's default encoding, however you cannot change it to a version that does not throw exceptions on UTF-8 encoding errors. This in effect is a DOS bug (because code is rarely tested on invalid UTF-8 and thus the exceptions will be thrown unexpectedly) and due to this we are forced to wrap all conversions to QString in our own code that does a lossy but non-error-throwing conversion. This is actually very difficult because the default QString constructor is too easily called. Something that is BADLY broken however is Python, where you cannot change the encoding from the default of ASCII-only, even in Python 3. The real solution would be for them to start storing strings in UTF-8 so that errors are preserved, but Microsoft's filename api discourages that because of similar problems with it's ability to store and use UTF-16 errors.

Re:Bloat.

[spitzak]

Linux is a bit better for this, yes, but not good enough. Most commercial Linux software also ships with it's own copies of all the shared libraries, for the same reason this is done on Windows.

Re:Bloat.

[tibit]

You're just making stuff up as you go along. Seriously.

There is no useful string algorithm where the Nth unit of the string is "interesting" without first looking at the N-1 preceding units in order to calculate N

So obviously, the scenario of having fixed-format strings and having to extract something from their middle is not a useful string algorithm to you?

I suspect also you think UTF-16 is fixed-size

You really missed where I said "use UCS-2 - a fixed-width encoding, as opposed to say UTF-16". Use of any non-fixed-width encoding inside of a string class implies that you must use iterators instead of integer indices, otherwise every indexed string access has O(N) cost. The workaround is to embed index marks within the string, but then you have internal representation that can't interoperate as-is with anything else out there.

however you cannot change it to a version that does not throw exceptions on UTF-8 encoding errors

Qt doesn't explicitly throw. It is mostly exception safe when faced with exceptions thrown in user code, but that's it. None of its own code throws. QTextCodec IIRC by default replaces undecodable input by the unicode replacement character. Where the heck did you get the idea about exceptions and Qt?

Re:Bloat.

[JabberWokky]

Well for one thing, the Google boys like to spy on us.

To date, they have been open about it. Startlingly open, to the point that they have working groups like the Data Liberation Front and clear documents that state that you can delete your data, but they can't wash your meta and abstracted data from their summarized data, only your identity, if you delete it.

They are in a business where the SOP is not to explain what they do and push the boundaries of what they can get away with without getting caught. Google, on the other hand seem to be honest, to the point of penalizing internal divisions that have made ethical missteps using the same rules they hold outside groups accountable to.

Have no illusions: they do collect data, and are a commercially motivated company, and no amount of good behavior should result in a lax approach to watching them carefully, especially given their scope. But to date they are the best option out there, allowing and encouraging people to give informed consent (having two versions of all legalese, one legal, one plain language to communicate) and giving people the ability to opt entirely out of their constellation of services, even after having been a user in the past.

Re:Bloat.

[spitzak]

So obviously, the scenario of having fixed-format strings and having to extract something from their middle is not a useful string algorithm to you?

You can extract the center of strings using offsets. This has nothing to do with fixed-sized units.

You really missed where I said "use UCS-2"

UCS-2 is obsolete as it cannot store all of Unicode, and is not used anywhere. I might as well say "bytes can be used because I only use ISO-8859-1".

Qt doesn't explicitly throw

Looks correct, I think I was confusing this with Python. It is unfortunate that they think some perfectly valid 16-bit values are "errors" when written in UTF-8, as this prevents invalid UTF-16 from being stored, leading to the same problems on Windows that refusal to handle errors leads to the inability to use UTF-8 on Unix. If a filename can contain invalid sequences we MUST be able to specify such invalid sequences (http://qt-project.org/doc/qt-5.0/qtcore/qstring.html#fromUtf8)

Re:Bloat.

[HiThere]

According to the docs on the site, QChars and QStrings are both utf-16. If this is wrong, perhaps the documentation should be fixed.

Re:Bloat.

[MikeBabcock]

True, many do, but even Skype (maintained by Microsoft) has a dynamically linked binary download.

Re:Bloat.

[spitzak]

Yes I think it is common for a dynamically linked executable to be used, but it has rpath set to a relative directory and it is also shipped with .so files for everything. This does mean you can often remove/rename these .so files and use the central ones. GoogleEarth for instance had an old version of Qt that did not do antialiased text, and you could fix this by simply removing their Qt so files.

How big is Chrome?

[serviscope_minor]

How big is chrome?

  $ls -lh /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.17
-rw-r--r-- 1 root root 953K Apr 15 2013 /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.17

And libc is a mere 1.8M.

There are plenty of very well battle tested ways of targeting C code to multiple systems.

I think I'm going to stuff mine into libreoffice. That's only a few hundred meg and a start up time of a second or two.

Re:How big is Chrome?

[tibit]

You're just being obnoxious here. You seriously think that the stuff they're after is in the C++ standard library? Most of it, like 95% of it, isn't, and what is, is already used as-is by Chrome code.

Re:How big is Chrome?

[HiThere]

That's pretty much irrelevant. He's talking about using the Chrome libraries, so the linker will strip out any unused functions.

What this means is that it's likely providing a bunch of useful functions above and beyond the standard library. The problem is, he only talks about those routines in such general terms that you can't figure out whether they're useful, and he doesn't give any links to documentation, so you don't even know if they're documented.

N.B.: You *could* check the source and see if it was documented, if you were interested enough, but why pick this set of libraries instead of the ones you already know about? You need to be pretty much sold ahead of time. My wild guess is that they don't have any decent documentation, or he would have linked to it, but that *is* just a WAG.

And also...

[serviscope_minor]

From TFA:

Unless you are building your app for Windows 3.1, chances are that you want to talk to a server of some kind.

Why does everyone assume that everyone else is doing stuff exactly like them? For work I don't think I've ever written code that makes any kind of network calls.

In fact the main reason for me not to use any of the "highly optimized interfaces" they provide is that professionally none of them are of the slightest bit of use to me. It's interesting but there are more programs in this world than web-2.3.1-rc4 apps for phones.

Re:And also...

[maxwell demon]

Unless you are building your app for Windows 3.1, chances are that you want to talk to a server of some kind.

That's true: Sooner or later I get hungry, so I'll go somewhere to eat and ask the server to give me some food.

Re:And also...

[sunderland56]

What if I want to run my code *on* a server? Does this newfangled Chrome thingy run on Solaris/AIX/IRIX/HPUX/etc?

Re:It makes sense

[qubex]

I think he’s referring to the Chrome/Chromium browser, not the Chrome browser-on-linux self-contained-computing-environment thing.

Mozilla NSPR

[abies]

I have a strong feeling of deja vu - I have heard same pitch about Mozilla NSPR (https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSPR). Same thing - base library for many platforms, which is very well tested, developed for the needs of browser coding, but not really tied to hmtl rendering in any way.

So, assuming I want to be hipster should I:
- use NSPR, because it was available before reusing browser base libraries went mainstream
or
- use Chrome library, because really cool guys use Chrome rather than Firefox
?

Re:Mozilla NSPR

[maxwell demon]

Obviously you should make your product cross-platform by supporting both NSPR and Chrome ;-)

Re:Mozilla NSPR

[rvw]

So, assuming I want to be hipster should I:
- use NSPR, because it was available before reusing browser base libraries went mainstream
or
- use Chrome library, because really cool guys use Chrome rather than Firefox
?

As hipster and nerd, you should DYOFF (Develop Your Own Fucking Framework)!

Re:Mozilla NSPR

[Florian Weimer]

And Apache has the Apache Portable Runtime, with similar goals, but probably geared more towards writing server code.

Re:Mozilla NSPR

[TheRaven64]

And an API that makes the standard Java libraries seem clean, consistent, and concise.

Re:Mozilla NSPR

[phantomfive]

How is NSPR?

Re:Mozilla NSPR

[robthebloke]

Chrome libs includes a free cloud based backup solution for your data and passwords, all paid for by the NSA.

Re:Mozilla NSPR

[bill_mcgonigle]

serious question - do you have to use XPCOM and all that sort of cruft to do non-XULrunner things with NSPR?

Re:Mozilla NSPR

[abies]

No, NSPR is really low level. You can think about it as less readable libc+libsocket+libthread, which gives you platform-independent API.
So, it is
PRUint32 PL_strlen(const char *str);
instead of
size_t strlen ( const char * str );
(saves you from worry about what size_t is on given platform). And every other function you know from above libraries will be converted into some with strange prefixes, but well defined data types.
Well, there are few other goodies like hashtables, but generally it is about being really portable.

Re:Mozilla NSPR

[HiThere]

Also note that the Apache Portable Runtime is highly lacking in introcuctory documentation. What it has is DOxygen generated comments for poorly documented routines. They're probably quite adequate if you already know what they do, and just need reminding, but otherwise....sheesh!

Re:Mozilla NSPR

[bill_mcgonigle]

Nice. Thanks for the info.

Re:It makes sense

[maxwell demon]

You mean, you can run Chrome in Emacs?

Applications in a Web Browser?

[Anonymous Coward]

LOL. The 90s are calling, they want their Java applets back.

On a side note, articles containing the phrase "business logic" can be safely ignored as irrelevant trash.

Re:It makes sense

[Anonymous Coward]

Probably. Emacs runs lisp, for which a large variety of javascript implementations exist. x86 simulators for javascript do also exist. On these, some kind of operating system can be booted (be it windows or linux or whatever), on which the related version of chrome should be able to run.

How about no?

[loufoque]

Pretty much all the features they need are standard features or are better addressed by a dedicated library.
Also it's more a framework than a runtime. Learn the difference, it could save your life.

Funny

[msobkow]

When I think "business logic" I'm usually thinking "RDBMS interface".

What does Chrome's library do to deal with business data?

Nothing.

Re:Funny

[tommeke100]

It just means you don't have to write or worry about "boilerplate code".

or not

[smash]

Lets talk about this again in 12 months. Given the NSA bullshit, Chrome, Apple and Microsoft all being involved, I'm not sure people are going to be keen on yet another layer of abstraction for surveillance to be hidden in.

No

[Anonymous Coward]

Chrome Is the New C Runtime

No, it's not. Use the proper APIs on your target systems. But considering the authors name is Sanjeev Radhakrishnan and he's blogging "from the uncloud", what did I expect?

Re:No

[tibit]

Those "proper" APIs are usually chock full of bugs ("features"), intricacies, and generally can be a pain to work with. All this has been handled by people who develop the platform abstraction. You really need to go out more and look at how convoluted real-life cross-platform code is. All this crap took long time and lot of effort to get done. You can use it and get ahead, or you can reinvent the wheel, usually in a buggy way. Your choice.

Re:mad. ave. storm typers underwhelmed with hobbyi

[sa666_666]

Hmm ... What ???

Aside from the obvious security issue...

[hyades1]

...why would any sane person build their whole business on Google, with its reputation for pulling the plug on projects for no obvious reason, little or no warning, and absolutely no interest in granting stays of execution?

Seems like a recipe for disaster.

Re:Aside from the obvious security issue...

[tibit]

Seems more like an understanding fail to me. Their business is not built on Google. It's built on a platform abstraction library that currently works for their intended uses. It's a closed book, they don't need any further involvement from Google. If they want to, they can fork it and maintain it themselves. They've already got a big trampoline so it'd still be less work to maintain that code than to come you with a yet another in-house, buggy, under-tested "framework".

Re:Aside from the obvious security issue...

[Bing Tsher E]

You work for Google, in sales. Amiright?

Re:Aside from the obvious security issue...

[swillden]

Google, with its reputation for pulling the plug on projects for no obvious reason

That reputation is a product of /. groupthink, not reality. The reality is that Google has a history of pulling the plug on projects that aren't successful, niche products used only by a tiny percentage of the user base.

Chrome, however, is wildly successful. Plus, the code is all open source and has an active developer community outside of Google. Google isn't going to drop Chrome, and even if Google did, Chromium wouldn't be going away any time soon.

Re:Aside from the obvious security issue...

[hyades1]

And you sound like a hobo who gets most of their calories from all the semen you guzzle in public toilets.

So how about you get back on your knees and have some breakfast.

Re: Aside from the obvious security issue...

[rubycodez]

hit a nerve in your carcass, did I?

Re:Aside from the obvious security issue...

[tibit]

No. And google doesn't really get any benefits from people reusing Chrome's portability layer. Their salespeople couldn't care less about this.

Re: Aside from the obvious security issue...

[hyades1]

You shouldn't talk with your mouth full. :-)

i7: It's called JAVA

[Anonymous Coward]

This is how bloat begins: with an apparently clever insight that ignores actual common sense.

Yeah, and soon we'll need i7s to run 'Hello World'.

10 years ago, ...

and ..

Out of necessity, the Chrome team has created cross-platform abstractions for many low-level platform features. We use this source as the core API on which we build our business logic, and it's made the bulk of our app cross-platform with little effort.

20 years ago, Java was invented to do all of this and it has been tested even MORE than Chrome.

Geeze! I think all CS programs should have CS history. What next? Someone is going to 'figure' out how to page memory?

I have this idea to allow objects to be moved without having to pick them up or slide them, it's based on a circle, it called a Pi Mover (TM) and with an Axel (TM - NOT axle) and another Pi Mover, you can amplify your strength!

Yep, I'm looking for VC funding ...

It's just the hipster ignorance yet again.

[Anonymous Coward]

The software development industry used to consist of professionals. These were people who knew enough to know that not everybody works on networked software.

Then sometime around 2006 to 2008, the whole "Web 2.0" phenomenon started. It flooded the industry with hipsters. These are people who have no technical or professional training. They just like wearing fedora hats, glasses with no lenses, and expressing "opinionated" ideas about stuff they know nothing about.

To them, "software development" does not extend beyond JavaScript and Ruby on Rails. They don't know assembly, C, C++, or even Java and C#. They don't know about embedded software. They don't know about industrial control systems. They don't know about financial, scientific and engineering modeling software. To these people, all there is is web development. They can't even conceive the idea that there might be software that isn't networked.

Hipsters are an infection upon the software industry. They bring nothing but ruin and stupidity.

Re:It's just the hipster ignorance yet again.

[martin-boundary]

Except the industry has had several waves of clueless "programmers" flooding it before already (eg dotcom - 'nuff said)

People who truly know what they're doing have always been few - hmm, I guess that explains a lot.

Re:It's just the hipster ignorance yet again.

[Sponge Bath]

Then sometime around 2006 to 2008, the whole "Web 2.0" phenomenon started. It flooded the industry with hipsters.

Fiber is OK for the masses, but the bits sound "warmer" when transported by avian carriers.

Re: It's just the hipster ignorance yet again.

[defcon-11]

Hipsters didn't kill non-networked code. Amazon did. No manager is going to shell out for a big iron Sun box these days when your "scientific, financial, engineering" analysis code can run on a couple dozen ec2 nodes for a quarter of the price.

Non-native controls

[Anonymous Coward]

Everybody love non-native controls!

http://youtu.be/X7b0AwVTx8g?t=31m10s

Java as the cure for "bloat"? What the fuck, son?

[Anonymous Coward]

What the fuck? Are you seriously claiming that Java is less bloated that the C and C++ libraries underlying Chrome?

Come on. Have you ever worked with the JVM? It is by far the slowest, ugliest, most bloated cross-platform runtime there is. Java makes Mozilla's XUL/JavaScript monstrosity look clean and efficient!

A lot of hipsters will claim "The JVM is a great runtime!", but that's only because they're neck-deep in the latest Scala and Clojure crap, and they're resorting to the most unrealistic and misleading micro-benchmarks known to mankind to support their nonsense claims. They also have never used C or C++, and really have no idea what efficient software without any bloated external runtime is actually like.

Java isn't even that portable compared to C, C++, or even Python, for crying out loud. Modern versions of those run on systems where no JVM exists, or if it does exist, it's an ancient version from years ago.

At this point, Java and the JVM should be treated as an experiment that got out of hand. Yes, we'll be supporting Java-based software systems for decades to come, but that's no reason to use it for new systems, or to pretend like you do that it's somehow "less bloated" than real software developed using C or C++.

So...

[Anonymous Coward]

...which C runtime is Chrome using?

No.

[GrahamJ]

I don't want to use a base library supported by a huge ad network, thanks.

It sounds more like

[Anonymous Coward]

They should have chosen Java instead of C++ in the first place.

Re:Plugins.

[Gavagai80]

This has nothing to do with plugins. Chromium is open source, this is about using chromium source code in other projects. Does not require the Chrome browser to be installed on the system.

Re:Plugins.

[gbjbaanb]

WTF? You didn't read the article did you.

nothing about plugins - its about leveraging the libraries than Chromium uses to build Chrome. In that, you can leverage those same libraries to build whatever you like. Its got fuck all to do with plugins, or Chrome itself for that matter.

Jesus Slashdot

[gbjbaanb]

this is worse that usual, I read the article (well, skimmed through it) and all the guy is saying is: Chrome is built on some libraries that you can pick and chose and build your own programs using. So if you need a http server or xml lib or any other of the myriad bits that Chrome needs, there's a nicely set up way of getting all those for free, and cross platform. Then he describes the library-picker tool and how it can create project files for various platforms to make your life easier.

But all the comments in /. are:

why would you build it on big old bloated Chrome (I assume the browser);

but that's what java was designed for;

but that's way bigger than libc;

So google now want us to write plugins instead of HTML5

and so on, no-one really got what the article was about, thinking its somehow building programs inside Chrome, or using Chrome as a kind of new webkit.

Pathetic. I blame the editoral summary TBH, but the kids here just got to a new low in not RTFA.

Re:Jesus Slashdot

[marcello_dl]

Maybe they are kids, maybe they are old dogs who got burned by environments who were devise to be weaponized, increasing some corporations' hold on the market. It is irrelevant to scream "but it is open source!", google itself has shown how raw engineering power can be used to control a project with android.

Re:Jesus Slashdot

[reikae]

this is worse that usual, I read the article (well, skimmed through it)

This is a serious condition. Luckily a few more Bitcoin and Samsung lawsuit articles should make it go away.

Re:Jesus Slashdot

[PeerPressure]

I blame the headline.

Re:It makes sense

[peragrin]

no but you can run emac in chrome

Look for emac mode chrome ext.

Why are native API's stuck in the 80's?

[amorsen]

In 2014, why do we need non-native libraries to handle DNS lookups, crash reporting, logging? Surely these are part of what a proper platform should offer, yet none of them do. It is pretty sad when at least one GUI toolkit (QT) feels the need to include a networking API.

Re:Why are native API's stuck in the 80's?

[Noughmad]

Because you don't want to use differents API for DNS lookups on different platforms, you want to "write once, run everywhere". Considering the above-mentioned Qt already exists, I thought this was a solved problem, but apparently Chrome-fans have to reinvent the wheel.

Re:Why are native API's stuck in the 80's?

[amorsen]

So your proposed solution is that every platform should just include QT networking? Fair enough. It would certainly be an improvement. It would be nice with a C API as well though.

Re:Why are native API's stuck in the 80's?

[tibit]

Exactly. Qt is an application development framework. Networking is done differently on every fucking platform.

Re:Why are native API's stuck in the 80's?

[amorsen]

Every native API of a networking OS offers some sort of logging, crash reporting, DNS-lookup, et cetera facility.

There is no decent DNS-lookup and connection establishment C API in standard Unix. You are left to implement e.g. Happy Eyeballs (RFC 6555) on your own. You can of course use the low-level API's to send AAAA and A requests on your own, but there is no way to just say "give me a socket to google.com on port 80" and have it do the right thing.

Cross platform is something else entirely, that would be wonderful, but something platform specific would be OK too.

Re:Why are native API's stuck in the 80's?

[fyngyrz]

There is no decent DNS-lookup and connection establishment C API in standard Unix.

Yawn. Python. With great C bindings. :)

Re:Why are native API's stuck in the 80's?

[amorsen]

Absolutely. The higher-level languages do a much better job of this.

Re:Why are native API's stuck in the 80's?

[Noughmad]

Some C programmers, when confronted with a cross-platform problem, think "I know, I'll embed the Python interpreter." Now the program is not fast enough to calculate how many problems they have.

Re:Plugins.

[ElectraFlarefire]

I must admit I skimmed very quickly indeed and seem to have missed several things.
The 'Chrome Apps' thing has just been causing me problems trying to use Google products on no-blessed platforms and I reacted without thinking.
Sorry.

What, it's full of buffer overflows?

[lseltzer]

(nt)

Re:Java as the cure for "bloat"? What the fuck, so

[tibit]

There is a very efficient, hardware-assisted Java runtime available from Azul, but that pretty much just proves your point. You need dedicated hardware to make Java scream.

Modern C++, if you're not dumb about how you use it, lets you avoid all of the C's unsafety, automagically, and it can enforce many safety constraints for you at compile time, too. I don't really understand why anyone writing big, scalable server applications would want to use Java when running the same stuff on C++ will cost you less in datacenter power & cooling.

Re:Plugins.

[tibit]

This should be more like -5, Gone Full Retard.

Not the first

[w_dragon]

This guy talks like this is some new idea, but there are excellent libraries that already provide this stuff. A quick look at the list tells me that boost and openssl cover most of the functionality, and unlike chromium they are made to be libraries, so you can be pretty confident they work under all conditions and the developers won't screw around with the api between versions.

Yet another cross-platform API

[TheloniousToady]

Though I found TFA interesting, it seemed like actually doing what it suggested would be equivalent to learning a large new cross-platform API. Compared to the familiar wxWidgets, QT, and GTK+, the Chrome API may have some advantages in terms of features, but I doubt it would be nearly as well documented. It would probably be a pretty big mountain to climb.

Regardless of which of these things you adopt (or even Java), you always have the basic problem of learning a large API, so it's hard to commit to more than one of them. So, although the idea of using the Chrome source as a cross-platform API is interesting, I wouldn't actually get involved unless it offered something that I actually needed which the other cross-platform toolkits didn't already provide.

Re:It makes sense

[CdBee]

the real trick is to start chrome browser, start Fabrice Bellard's javascript x86 virtual machine in Chrome, start Chrome OS on the VM, start Chrome on Chrome OS, then once you've got an infinite software defined hardware loop running, just unplug the physical hardware and put it away

Re:Java as the cure for "bloat"? What the fuck, so

[TheRaven64]

Azul stopped chip development a few years ago. They found that the speed benefits in GC with their custom hardware were offset by the fact that everything else was slower than on a commodity x86 chip. They now primarily sell x86 systems, and do some insane stuff with the page tables to make the GC fast.

Re:mad. ave. storm typers underwhelmed with hobbyi

[akozakie]

Thanks for resetting my mind. I was a bit stressed today, but after reading this I don't even remember why.

WTF did I just read?

2x performance improvement?!

[Anonymous Coward]

Holy moley, I can't believe what I'm reading.

Your claimed "2x performance gain" is usually actually 10 to 15 times, for real-world software written in C++ versus Java, and 25 to 50 times for software written in C++ versus JavaScript or Ruby.

Don't bother trotting out your totally unrealistic Fibonacci sequence micro benchmarks where some Rubyists or Javaists have spent months highly tuning some Ruby or Java code so it's only 5 times slower than the equivalent unoptimized C++ code. That's not the kind of Ruby or Java code that exists in the real world.

And modern C++ is an extremely efficient language to program in. Maybe you're ignorant of C++11, but it adds many high-level language features that we don't even see in Java yet. C++ also has very mature tooling and libraries which further makes it very fast to develop with.

Re:2x performance improvement?!

[Wootery]

Don't bother trotting out your totally unrealistic Fibonacci sequence micro benchmarks

Indeed, it's difficult to demonstrate real-world performance advantages. From where, then, are you getting your numbers?

Re:2x performance improvement?!

[ahabswhale]

Out of his ass. A lot of people still think of Java 1.1 when they think of Java performance. They don't know things like Java is much faster at object creation than C++ or that it can optimize its performance at runtime based on usage (which C++ cannot do). They also think Java loads classes even if they are not used just because they are included in a reference jar file.

Re:2x performance improvement?!

[Wootery]

They don't know things like Java is much faster at object creation than C++

True, but don't forget the GC has to run some time. Faster allocation doesn't necessarily mean reduced overall time spent on memory-management.

or that it can optimize its performance at runtime based on usage (which C++ cannot do).

Also true, but profiling C++ compilers are out there.

They also think Java loads classes even if they are not used just because they are included in a reference jar file.

I've seen a similar misunderstanding regarding Java's import keyword.

What better name?

[tepples]

What's a better term than "business logic" for that which should be kept separate from presentation? There's "game logic", but that too is domain-specific. "Application logic" perhaps?

Re:What better name?

[Daniel Dvorkin]

What's a better term than "business logic" for that which should be kept separate from presentation? There's "game logic", but that too is domain-specific. "Application logic" perhaps?

Yes, I think "application logic" would be good. The problem with "business logic" is that it's domain-specific too; an awful lot of interesting algorithm development and implementation is taking place outside the realm of what would normally be considered business applications. Games are one example; scientific programming is another. In both cases, many of the principles that are useful in business programming can be usefully applied, but the purpose of the final application is very different.

-moz-subject, -webkit-subject, -ms-subject

[tepples]

The code isn't the same so long as 1. HTML5 prefix hell is allowed to continue and 2. companies like Apple continue to deliberately leave things like WebGL and getUserMedia unimplemented.

Like Java

[YoungManKlaus]

> "Out of necessity, the Chrome team has created cross-platform abstractions for many low-level platform features.
like java
> We use this source as the core API on which we build our business logic,
> and it's made the bulk of our app cross-platform with little effort.
like java
> Most importantly -- Chrome code has been battle-tested like almost nothing else,
> with an installed base in the hundreds of millions.
like java

so I kind of dont see a difference to just using what would be considered a higher-level language.

Longer

[bussdriver]

Mozilla was being used as a platform more than 10 years ago; not the browser but the framework underlying it which powered the browser, email client, irc chat, etc. I remember seeing a few books on it before Chrome even existed.

Apache has been running on everything forever; one could say similar things about using Apache for writing server software... in fact long before Chrome they made the common elements into a library called the Apache Runtime Library.

Lets not forget all the general frameworks out there which are not without their own complications but they are DESIGNED for this purpose instead of a spin off side project that is closely coupled to a single purpose.

All that said, making an HTML5 app with hooks into a browser engine looks to be the most portable with the least long term maintenance (aside from the issues with javascript - which are more style than language related, just like C++ it gives you plenty of rope with which to hang yourself.) More labor upfront, you bet it is... but to support every device quickly and not have to suffer every system upgrade (and support many versions of systems,) it probably pays off - more so with time.

Re:Plugins.

[Anonymous Coward]

This has nothing to do with plugins. Chromium is open source, this is about using chromium source code in other projects. Does not require the Chrome browser to be installed on the system.

Oh, so the point is "You can use third party libraries to save you time when developing your code."? Gosh, what an insight!

Re:Java as the cure for "bloat"? What the fuck, so

[Anonymous Coward]

They emulate their hardware in software. So their GC is highly concurrent, reducing latency, but on the whole their JVM is significantly slower than others.

This guy doesn't know what I was doing 10. ago

[istartedi]

10 years ago, you just whipped out your Visual Studio when you needed a client application, but not anymore.

No. I whipped out Visual Studio and created a header called plat.h and a source called plat.c. There were no more than 2000 lines devoted to platform issues, vs. something like 40k for the whole thing at its largest point. They allowed my application to run on Windows, Linux and FreeBSD. And yes, it did threads and networking! It used pthreads on Windows, and it worked very well. Eventually, the kernel module component (yes, kernel module) ran on all 3 systems in kernel mode. The plat.h/plat.c business never got out of hand. It was pretty manageable. At some point, we interviewed a manager who wanted us to switch to Eclipse, and couldn't understand how I could do what I did without using Java. Fortunately he was not hired.

Re:Java as the cure for "bloat"? What the fuck, so

[doublebackslash]

It isn't that insane. Instead of remapping one page at a time the queue up a number of changes and commit them all at once. This is because on stock Linux every page table re-map creates a lot of cache coherency traffic to make sure all the processors know of the new mapping. By committing them all at once they only need one round of that.

http://www.azulsystems.com/sites/default/files/images/c4_paper_acm.pdf

Section 5.1 is where it starts going into some details on that.

Re:Java as the cure for "bloat"? What the fuck, so

[ultranova]

They also have never used C or C++, and really have no idea what efficient software without any bloated external runtime is actually like.

Hand-coded assembly in COM format running on DOS and crashing if everything isn't set up as and you don't input exactly what the programmer expected, basically. Good riddance.

Re:Like XUL based apps?

[HiThere]

Sorry, but which version of Gtk? Gtk3 is pretty much incompatible with Gtk2. so I've stopped paying either version much attention. (The last time I checked, Gtk3 had mad many of the things I was doing with Gtk2 not work, so I stopped active development on the Gtk projects...or switched to other libraries. Admittedly that was several years ago, but I haven't heard many people singing the praises of Gtk since then. Qt, yes, and it has many nice features, along with some I rather dislike, but not Gtk...of course Qt is C++. There's much to be said in favor of C libraries, I'm a lot less convinced about much to be said in favor of Gtk.)

Re:Java as the cure for "bloat"? What the fuck, so

[ultranova]

Modern C++, if you're not dumb about how you use it, lets you avoid all of the C's unsafety, automagically, and it can enforce many safety constraints for you at compile time, too. I don't really understand why anyone writing big, scalable server applications would want to use Java when running the same stuff on C++ will cost you less in datacenter power & cooling.

Because as the size and age of the codebase grow towards infinity, the chances of at least one dumb person touching it grow towards one.

Limiting damage from dumb mistakes is more important than absolutely best efficiency. That's true for all projects, not just programming. It's pretty much the definition of Murphy's Law.

Seems like a solid idea

[Jeeeb]

At work we use Skia, the 2d drawing library for Chrome/Android, in a server application, to render charts and graphs based from seismic data into png images.

The library is a fairly light weight dependency, lightning fast and designed to take advantage of the power of C++, rather than sticking to a C api. However, dealing with Google's custom build system and the relatively sparse documentation made getting started a bit harder.

Depending on the kind of application being built, I would definitely consider taking advantage of other parts of the Chrome libraries, although they'd have to provide functionality not in Boost or QT.

Chrome and desktop notifications

[fyngyrz]

In a somewhat related bit of news, Google recently emailed me to let me know that they were no longer going to support the desktop notifier, that tool I use each and every day to let me know I have mail. However, Google went on to tell me, I could get that functionality back if I switched to Chrome.

I'm not going to switch to Chrome. Zero interest. Nice try, though, Google.

Here's the meat of it:

Important Announcement on Google Notifier Beta

We are writing to let you know about an important change to Google Notifier Beta. Starting on January 31, 2014, Google Notifier Beta will no longer be supported, meaning the app will no longer show recent emails and calendar events.

Since the Google Notifier Beta launched in 2005, a lot has changed. Smart phones can now notify us of new messages wherever we are, and improvements to web technology enable similar features to be built right into the browser.

If you want to continue to receive notifications, you can use any of the following alternatives to Google Notifier Beta using the Chrome browser:

Cloaca.lib

[fyngyrz]

Oh, another one who uses cloaca.lib -- yeah, not only warmer, but you get aimed results and splash damage.

Re:Compete

[aminorex]

You seem to be missing a dose of reality. A quality product at a discount price typically cannot compete with established manufacturing, distribution and advertising channels. It requires deep pockets and order of magnitude value improvements to succeed against an entrenched player. That's why we don't have flying cards and a Mars colony. Competition is so inefficient as an economic organizing principle that it is literally killing millions every day. Perhaps the only worse principle is central planning.