Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Chrome Is the New C Runtime

timothy posted about 8 months ago | from the ok-but-does-it-have-a-browser dept.

Programming 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."

cancel ×

196 comments

Sorry! There are no comments related to the filter you selected.

Bloat. (4, Insightful)

qubex (206736) | about 8 months ago | (#45997457)

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

Re:Bloat. (0)

Jmc23 (2353706) | about 8 months ago | (#45997475)

Yes bloat always begins by using something already installed and in memory instead of creating a separate pile of shit that has to be loaded. They're soooo stupid... wait...

Re:Bloat. (3, Informative)

qubex (206736) | about 8 months ago | (#45997513)

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. (0)

Anonymous Coward | about 8 months ago | (#45998337)

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

Well, you can't spell Chrome without 'me'.

Re:Bloat. (0)

Joce640k (829181) | about 8 months ago | (#45997531)

Yes bloat always begins by using something already installed and in memory instead of creating a separate pile of shit that has to be loaded. They're soooo stupid... wait...

Yep. Chrome is already installed and running on every machine in the world.

Not.

Re:Bloat. (5, Insightful)

gbjbaanb (229885) | about 8 months ago | (#45997775)

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. (5, Insightful)

Anonymous Coward | about 8 months ago | (#45997883)

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!

Because slashdot is still in 1999 mode. (0)

Anonymous Coward | about 8 months ago | (#45997895)

Just a shit new UI design. Come to reddit where it's -6 with no comments:

http://www.reddit.com/r/programming/comments/1vhfys/chrome_is_the_new_c_runtime/ ;-)

Re:Bloat. (-1, Troll)

Bengie (1121981) | about 8 months ago | (#45998531)

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

Yeah, the 2x performance gain is totally worth longer development times. Do whatever works best for your situation.

Re:Bloat. (1)

dkf (304284) | about 8 months ago | (#45997891)

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. (1)

martin-boundary (547041) | about 8 months ago | (#45998075)

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

Re:Bloat. (4, Informative)

tibit (1762298) | about 8 months ago | (#45998121)

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. (0)

Anonymous Coward | about 8 months ago | (#45997867)

Yeah. We can safely assume that when Chrome is loaded, the C runtime proably isn't yet... Errrm...

Re:Bloat. (1)

Anonymous Coward | about 8 months ago | (#45997915)

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

Re:Bloat. (0)

Anonymous Coward | about 8 months ago | (#45998045)

Except you arn't running in the Chrome browser the user is running. You are running your own copy of chrome code. So you end up having multiple instances of the hellishly bloated chrome framework in memory

Re:Bloat. (2, Insightful)

beelsebob (529313) | about 8 months ago | (#45998389)

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. (5, Insightful)

Anonymous Coward | about 8 months ago | (#45998521)

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. (0)

Anonymous Coward | about 8 months ago | (#45998417)

So you end up having multiple instances of the hellishly bloated chrome framework in memory

Hey, show a little compassion. Chrome recently signed up for Netrisystem to help it shed some of those extra bits that make up its load handles. You know, with those weekly updates delivered automatically you never have to think about it. Netrisystem does it all for you and before you know it you've lost all that privacy, um, I mean bloat.

Re:Bloat. (0, Troll)

Anonymous Coward | about 8 months ago | (#45997537)

Linux is the new embedded device! So that's why my wireless router takes 45 seconds to boot up. There was a time when networking equipment would power on instantly and begin working immediately, but no one remembers how to build things without bloat anymore.

Re:Bloat. (1)

nurb432 (527695) | about 8 months ago | (#45997603)

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

Re:Bloat. (0)

Anonymous Coward | about 8 months ago | (#45997735)

Lots of people remember. It's just that people aren't willing to pay them to reinvent the wheel over and over again.

i7: It's called JAVA (1)

Anonymous Coward | about 8 months ago | (#45997703)

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 ...

Java as the cure for "bloat"? What the fuck, son? (1, Insightful)

Anonymous Coward | about 8 months ago | (#45997771)

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:Java as the cure for "bloat"? What the fuck, so (4, Insightful)

tibit (1762298) | about 8 months ago | (#45998159)

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:Java as the cure for "bloat"? What the fuck, so (4, Informative)

TheRaven64 (641858) | about 8 months ago | (#45998367)

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.

Non-native controls (1)

Anonymous Coward | about 8 months ago | (#45997721)

Everybody love non-native controls!

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

Re:Bloat. (2)

quax (19371) | about 8 months ago | (#45998345)

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.

mad. ave. storm typers underwhelmed with hobbyists (-1)

Anonymous Coward | about 8 months ago | (#45997465)

burlesque style overkill is not new either on the badtoll field or here. overdosing on WMD on credit cabal hypenosys has the opposite of the intended effect as everyone knows rendering /. unvalid

Re: mad. ave. storm typers underwhelmed with hobby (0)

Anonymous Coward | about 8 months ago | (#45997509)

...the fuck?

Re:mad. ave. storm typers underwhelmed with hobbyi (0)

jones_supa (887896) | about 8 months ago | (#45997679)

Well, the secretive undertones of the can are about to temper at some point anyway. Why not simply adjust to the tougher hue and dispatch the categories of mirror images.

Re:mad. ave. storm typers underwhelmed with hobbyi (1)

sa666_666 (924613) | about 8 months ago | (#45997685)

Hmm ... What ???

Re:mad. ave. storm typers underwhelmed with hobbyi (1)

akozakie (633875) | about 8 months ago | (#45998385)

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?

How big is Chrome? (1, Interesting)

serviscope_minor (664417) | about 8 months ago | (#45997489)

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? (1)

tibit (1762298) | about 8 months ago | (#45998171)

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.

It makes sense (0)

Anonymous Coward | about 8 months ago | (#45997501)

Chrome is a complete OS running on top of another complete OS.

Re:It makes sense (1)

qubex (206736) | about 8 months ago | (#45997521)

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

Re:It makes sense (1)

maxwell demon (590494) | about 8 months ago | (#45997551)

You mean, you can run Chrome in Emacs?

Re:It makes sense (2, Funny)

Anonymous Coward | about 8 months ago | (#45997589)

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.

Re:It makes sense (0)

Anonymous Coward | about 8 months ago | (#45997675)

Only if you run Emacs in Chrome first.

Re:It makes sense (1)

peragrin (659227) | about 8 months ago | (#45997947)

no but you can run emac in chrome

Look for emac mode chrome ext.

Re:It makes sense (5, Funny)

CdBee (742846) | about 8 months ago | (#45998351)

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

And also... (5, Interesting)

serviscope_minor (664417) | about 8 months ago | (#45997517)

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... (0)

Anonymous Coward | about 8 months ago | (#45997549)

Yeah, well, you know, that's just, like, your opinion, man.

Re:And also... (5, Funny)

maxwell demon (590494) | about 8 months ago | (#45997587)

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.

It's just the hipster ignorance yet again. (4, Interesting)

Anonymous Coward | about 8 months ago | (#45997709)

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. (1)

martin-boundary (547041) | about 8 months ago | (#45998141)

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. (2)

Sponge Bath (413667) | about 8 months ago | (#45998319)

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:And also... (0)

Anonymous Coward | about 8 months ago | (#45997719)

To be fair, if the author is the type of person who says that he is "building an app" rather than writing a program, he probably can't imagine doing something that is not related to the web.

Like XUL based apps? (-1)

Anonymous Coward | about 8 months ago | (#45997533)

Welcome to the non-party you're only over a decade late!

If you want a cross platform C runtime, try GLib & Gtk.

Mozilla NSPR (5, Interesting)

abies (607076) | about 8 months ago | (#45997541)

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 (4, Funny)

maxwell demon (590494) | about 8 months ago | (#45997567)

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

Re:Mozilla NSPR (0)

Anonymous Coward | about 8 months ago | (#45997615)

Isn't that the argument for writing your product in Flash or Silverlight?

Re:Mozilla NSPR (2)

rvw (755107) | about 8 months ago | (#45997645)

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 (1)

zakeria (1031430) | about 8 months ago | (#45997737)

I've been using NSPR for this reason for years !

Re:Mozilla NSPR (3, Informative)

Florian Weimer (88405) | about 8 months ago | (#45997823)

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

Re:Mozilla NSPR (1)

TheRaven64 (641858) | about 8 months ago | (#45998381)

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

unpaid endorsement (-1)

Anonymous Coward | about 8 months ago | (#45997565)

my chromebook is the handiest fastest laptop i've ever had. proprietary is a trade issue..... it runs for hours per charge... gushing is unusual for me...

Applications in a Web Browser? (2)

Anonymous Coward | about 8 months ago | (#45997573)

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.

Plugins. (0, Offtopic)

ElectraFlarefire (698915) | about 8 months ago | (#45997613)

So Google.. the company that made such a huge thing out of HTML5 and how they hated flash and wanted to do away with plugins..
Have now made their own plugins? That only works in their own browser.. But don't worry! They own it, and they say it's the best, so it's apparently quite all right...
"The more things change, the more they stay the same." I think is the line.

Re:Plugins. (0)

Anonymous Coward | about 8 months ago | (#45997785)

Mod parent up.
I am not sure if GOOG actually pushes for it being a framework, or just the writer is a GOOG sucker and he thought for it to be a good idea.

Re:Plugins. (0)

Anonymous Coward | about 8 months ago | (#45997827)

Chrome and Mozilla are phasing out NPAPI support. NPAPI served a need at the time but is a security issue and doesn't offer easy cross-platform support as it did back when everyone ran on Windows.

Write against HTML5 and whether running on Chrome on a Linux laptop on x86, Firefox on ARM, Nook, or on the computing device on the headrest on a Southwest flight, the code is the same. HTML5 doesn't yet have the code library of Flash, but I'm certainly not sad to see it and all the other poorly written NPAPI plugins go away.

The more things change, the more we have to... you know, change. It's cyclical at best, but it's certainly not the same. Technology changes and trite comments that the state of technology hasn't changed doesn't mean it is so.

Re:Plugins. (4, Interesting)

Gavagai80 (1275204) | about 8 months ago | (#45997843)

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. (4, Informative)

gbjbaanb (229885) | about 8 months ago | (#45997847)

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.

Re:Plugins. (1)

ElectraFlarefire (698915) | about 8 months ago | (#45997981)

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.

Re:Plugins. (0)

Anonymous Coward | about 8 months ago | (#45998083)

Congratulations, though, on getting a +3, Insightful (as of now) comment while still being completely off-topic.

Imagine what you could do if you actually read the stories you reply to!

Re:Plugins. (1)

tibit (1762298) | about 8 months ago | (#45998189)

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

How about no? (3, Informative)

loufoque (1400831) | about 8 months ago | (#45997617)

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.

Yeah but google code is crap (-1)

Anonymous Coward | about 8 months ago | (#45997625)

Have you seen google code? It is on a wing and a prayer code. Battle-tested? Haha. You silly schmuck!

Funny (2)

msobkow (48369) | about 8 months ago | (#45997633)

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 (1)

tommeke100 (755660) | about 8 months ago | (#45998231)

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

or not (3, Insightful)

smash (1351) | about 8 months ago | (#45997641)

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.

Re: or not (0)

Anonymous Coward | about 8 months ago | (#45997655)

Making it bold isn't going to make it any less gibberish to most folks.

Getting better (0)

Anonymous Coward | about 8 months ago | (#45997651)

At concealing ads as actual articles. The AI is getting smarter. Fuck!

Let's replace NPAPI with 10 new standards! (0, Offtopic)

Anonymous Coward | about 8 months ago | (#45997661)

For those of you who don't know, NPAPI is the common interface used by several browsers that allowed plugins to be written: Flash, Silverlight, Facebook Video, etc. Lately there's been a lot of talk about NPAPI being blocked by default, and will be completely removed from future versions of various browsers. While there are plenty of issues with this standard (The least of which is noticeable because the N stands for Netscape), everyone's solution seems to be a resounding "We've got our own new, similar way to do this that offers X, Y, and Z, is better because of this, and if you want to participate in the future you should use it.

Just googling replacements for NPAPI gives a huge list of new alternatives, each of which seem to be supported by only one browser. As a developer, I'm not looking forward to this.

Re:Let's replace NPAPI with 10 new standards! (0)

tibit (1762298) | about 8 months ago | (#45998213)

You do know, you raving lunatic, that the fine article has got nothing, nothing at all to do with plugins, and nothing to do with NPAPI? Informative, my ass. Another fucking idiot. Why do people, who see "Chrome" and "API" in the same paragraph, automatically think it has got anything to do with web-browser-centric development? The whole point is that they are using the platform abstraction code, present in any large cross-platform software project. Firefox got it, Chrome got it, LibreOffice got it, many cross-platform application development frameworks have it. What's so hard to wrap your head around that?

Re:Let's replace NPAPI with 10 new standards! (0)

Anonymous Coward | about 8 months ago | (#45998641)

Obviously a lot of people misinterpreted the point of this article. Maybe it's a bad summary, maybe they all just started responding to the early comments, I don't know. But you come across as much more of a 'raving lunatic' than the OP responding with a profanity laden rant. I bet you could get your point across just as good, if not better, by simply informing the poster that they misinterpreted the article. People make mistakes, and rushing in with your guns blazing to yell at every person who did makes you much more of 'another fucking idiot' than any of the people here that posted about plugins.

Civil discourse. It may be the internet, but it's still a thing.

No (1)

Anonymous Coward | about 8 months ago | (#45997665)

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 (0)

Anonymous Coward | about 8 months ago | (#45997829)

Jesus Christ, I thought you were joking about the author's name and the blog's tagline, but you aren't.

What the fuck has happened to our industry? If it isn't the on-shore JavaScript-and-Ruby-loving hipster dipshits fucking things up, then it's off-shore third-worlders spewing buzzwords. What a sad, sad state of affairs.

Re:No (2)

tibit (1762298) | about 8 months ago | (#45998237)

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 [woboq.org] . 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.

Aside from the obvious security issue... (3, Insightful)

hyades1 (1149581) | about 8 months ago | (#45997689)

...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... (3, Informative)

tibit (1762298) | about 8 months ago | (#45998251)

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".

please (0)

Anonymous Coward | about 8 months ago | (#45997769)

1. logically it just semms stupid to have a non-network related application dependent upon chrome source code.
2. there exists already battle hardened and well tested libraries ideally suited for cross platform development. think libevent.
3. those libraries which are open soured have extensive support and are thus not dependent upon some large corporate entity.
4. yes, there are applications, such as medical imaging applications, which have fuck all to do with a network and should in fact not access any network of any kind.
5. c++ , driven by boost development, has undergone a revolution in the last couple of years which means that platform issues, while still a concern, are not the disaster that they once were.
6. the author of the article use to work for google.
7...you get the idea

So... (1)

Anonymous Coward | about 8 months ago | (#45997773)

...which C runtime is Chrome using?

No. (1)

GrahamJ (241784) | about 8 months ago | (#45997799)

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

It sounds more like (3, Funny)

Anonymous Coward | about 8 months ago | (#45997815)

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

writing abstractions is not hard (0)

Anonymous Coward | about 8 months ago | (#45997841)

Write them faggot!

Jesus Slashdot (5, Insightful)

gbjbaanb (229885) | about 8 months ago | (#45997865)

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 (1)

marcello_dl (667940) | about 8 months ago | (#45997995)

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 (0)

ElectraFlarefire (698915) | about 8 months ago | (#45998117)

Where are my mod points! I want go give! Mod it up!
Just because the words where wrong doesn’t mean the reactions weren't.

Why are native API's stuck in the 80's? (1)

amorsen (7485) | about 8 months ago | (#45997949)

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? (1)

Noughmad (1044096) | about 8 months ago | (#45997985)

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? (1)

amorsen (7485) | about 8 months ago | (#45998139)

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? (0)

Anonymous Coward | about 8 months ago | (#45998305)

Every native API of a networking OS offers some sort of logging, crash reporting, DNS-lookup, et cetera facility. The APIs are different, it's expectable, and it's not going to change unless different OS converge.

If you need to target more than one operating system, however, you either need to write separate code for each operating system or use cross-platform libraries such as Qt.

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

tibit (1762298) | about 8 months ago | (#45998261)

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

this is not runtime (0)

Anonymous Coward | about 8 months ago | (#45998037)

i would not call this c runtime , this is huge library for programming . not "C Runtime" specifically

What, it's full of buffer overflows? (1)

lseltzer (311306) | about 8 months ago | (#45998105)

(nt)

Not the first (2)

w_dragon (1802458) | about 8 months ago | (#45998229)

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 (4, Interesting)

TheloniousToady (3343045) | about 8 months ago | (#45998249)

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.

Idiotic headline (0)

Anonymous Coward | about 8 months ago | (#45998535)

Pretty stupid headline for someone saying "we're getting good mileage out of using the libraries that Chrome uses". So has my company, and we're not limiting ourselves to Blink/V8 - there's also Gecko, Webkit, and a whole WORLD of software out there. Standardizing on just the Blink libraries because they're convenient is a recipe for disaster.

No. (0)

Anonymous Coward | about 8 months ago | (#45998591)

Qt is. HTH.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>