Lambda the Ultimate

... with GvR on board and all?

I haven't seen any attempt to expand Python outside of its server-side niche.

Now, if chrome were to provide native support for a client side scripting language besides JS--that might be indicative of something. But I suspect that an attempt by Google to abandon/hijack a well established standard for the web ecosystem would nowadays be met with the same disdain were MS to try it (again).

The question is really do we need another scripting language? What does JS lack as a programming language? I'm not flamebaiting here, looking for a serious discussion.

JS' main problem has been poor performance and Google seems to be attacking that (and quite effectively). (X)HTML+CSS is also becoming closer and closer to being a very good UI layout language imho.

The attempt to use Python (and Ruby) as a client-side scripting language in a browser is actually pretty well-known - it's Silverlight, specifically the upcoming version 2.0.

Actually, they are smart enough not to enter this market directly. The closest you'll find is GWT (coming soon: chrome support). Comparing that with the Microsoft strategy is left as an exercise to the reader...

appears to be to continue to introduce dependencies on the Windows ecosystem. MS has some interesting and useful technology, including work done by SPJ and others (to keep this post kinda on topic), unfortunately, MS still insist in bundling it all up into a dreadnought operating system. Most of MS' products and technologies have equivalents in the free software ecosystem, as well as on the Macintosh platform--inertia seems to be paying the bills in Redmond these days.

Google's fundamental strategy appears to be to attract and retain eyeballs--their barrier to entry is the vast array of computational power, network bandwidth, and other resources; as well as a treasure trove of data they keep to themselves. There is no credible alternative to Google at the moment, at least not in the US (I can't speak of ASPs/search engines/advert servers located overseas, like Baidu in China). Yahoo tries, but hasn't "gotten it" for so long that it's probably too late for them.

Google has learned one important lesson from Microsoft in the latter's heyday--the care and feeding of developers is very important.

I do find it interesting though that despite the prominence of Peter Norvig (a longtime Lisp guru) in the Google technical hierarchy; so much server-side code is reportedly written in C++. *That* is kinda where I'd expect to see Google doing innovative work in programming languages--large scale distributed systems are one area not well served by any of the existing production languages--as opposed to an attempt to displace Javascript on the client.

I'm waiting for Google to come up with...
..their own programming language.

Sawzall - a popular language at Google

I also recommend searching the archives for GWT.

It's really well done.

And here's a nice LtU angle: "...instead of multiple threads, what if we have multiple processes? Each having its own memory and its own copy of the global data structures."

After all these years, it's sort of disheartening that this is a revolutionary idea... And it's frustrating to see another layer of process isolation around the same old global data structures. My new motto: "Functional programming: process isolation all the way down."

What is disheartening is that even though Google took the trouble of having this comic to explain why they did their architecture this way, on quite technical forums there are some comments 'but why don't is use multithreading?'

*Argh*, some people won't ever understand that 'early optimisation is evil', and using multithreading instead of multiprocessing is a memory optimisation which has many serious consequence and should only be used when benchmarks show that the overheard of multiprocessing is unbearable (which it very unlikely to be the case here: I've tried Chrome on my 4year old PC, and it doesn't seem to use more memory than the competition).

Saying that multithreading instead of multiprocess is "just" a memory optimisation is only true if you look at native threads, with some implementations of user threads, you get such a difference of memory consumption (not speaking about synchronization primitives here, especially since I'm rather thinking of things like Strategies in GHC Haskell) that the kind of things you can do with threads become radically different of what you could do with process.

In the context of navigator tabs though, I agree that multiprocess makes much more sense than multithreads : the only sharing is of tools, not of data.

as kernel objects?

I can't either.

That said--Jedal is correct--users seldom have more than a dozen tabs open at once. Mapping each one to a different process makes a lot of sense.