Chrome Is the New C Runtime 196
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."
Bloat. (Score:4, Insightful)
This is how bloat begins: with an apparently clever insight that ignores actual common sense.
or not (Score:4, Insightful)
Aside from the obvious security issue... (Score:4, Insightful)
Seems like a recipe for disaster.
Java as the cure for "bloat"? What the fuck, son? (Score:1, Insightful)
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++.
Re:Bloat. (Score:5, Insightful)
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?
Jesus Slashdot (Score:5, Insightful)
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:Bloat. (Score:5, Insightful)
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:Java as the cure for "bloat"? What the fuck, so (Score:5, Insightful)
There is a very efficient, hardware-assisted Java runtime available from Azul [azulsystems.com], 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:Bloat. (Score:3, Insightful)
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. (Score:5, Insightful)
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. (Score:2, Insightful)
If you only get 2x improvement on real code, your C sucks.
2x performance improvement?! (Score:3, Insightful)
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.