The Google Dash/Dart leak

[opinali]

I've only now found this: "[Caja] Fwd: "Future of Javascript" doc from our internal "JavaScript Summit" last week"
http://markmail.org/message/uro3jtoitlmq6x7t

Wow... just wow. Google is really gonna replace Javascript (long-term). Some highlights:

- Translation to Javascript to make it compatible with all browsers; but of course, a browser that has a VM optimized for Dart will run it directly and faster. I guess the Dart VM will be an evolution of V8 (unified Dart + JS support).
- "Optionally typed". Very curious to know about the details - will code without type annotations be still statically typed in the extent that's possible (with inference), or the language will have a full dynamic-typed nature including metaprogramming? Is some kind of parametric polymorphism (generics) supported? Are prototypes or similar constructs on the way out, i.e. class-based OO?
- "Designed for performance", and will have a richer typesystem (the document typically criticizes JS for its single Number type). IMHO this pretty much finishes the discussion about whether Javascript can become fast enough to be a first-class language for CPU-intensive code: V8 is clearly the top JS VM today, and here we have the V8 team basically admitting that there's only so much they can do with a language that is not "designed for performance". Color me unsurprised... ;-)
- Like I expected though, web applications (in this case client-side i.e. in browser) will be only the first major usage scenario. Dart will eventually be available for the server-side too, and even for Android.

[mP]

Whatever happened to Go, ?

[Russel Winder]

On Sun, 2011-09-11 at 22:31 -0700, mP wrote:
> Whatever happened to Go, ?

Basically it is a done deal. Wherever Google and Canonical are and they
can replace C, C++, Python, Perl, etc. with Go, especially in anything
"cloudy" or "webby" they will be doing it.

Despite all the warts and irritants, Go clearly does make C look like a
1970s language that is past it's use by date except in some very
specific use arena, e.g. severely resource constrained systems where you
have to use assembly language but cannot abide the thought of using
assembly language. Usually this means "embedded systems" where you have
maybe 32kB RAM and 10Mb flash — if you are lucky.

--
Russel.
=============================================================================
Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel...@ekiga.net
41 Buckmaster Road m: +44 7770 465 077 xmpp: rus...@russel.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder

[Fabrizio Giudici]

On 09/12/2011 09:36 AM, Russel Winder wrote:
> On Sun, 2011-09-11 at 22:31 -0700, mP wrote:
>> Whatever happened to Go, ?
> Basically it is a done deal. Wherever Google and Canonical are and they
> can replace C, C++, Python, Perl, etc. with Go, especially in anything
> "cloudy" or "webby" they will be doing it.

But generally speaking, is Go gaining popularity?

--
Fabrizio Giudici - Java Architect, Project Manager
Tidalwave s.a.s. - "We make Java work. Everywhere."
java.net/blog/fabriziogiudici - www.tidalwave.it/people
Fabrizio...@tidalwave.it

[Casper Bang]

IANAS (I am not a statistician), but on GitHub [https://github.com/languages/] Scala has 385 recently updated repositories, while Go has only 110. Given that both languages belong to the same open source realm, and how Google Code is in agreement with GitHub, that alone is enough to suggest Tiobe's conclusions have to be taken with a grain of salt. Go does not appear to be particular trending compared to Scala!

Seems to me Tiobe's main problem is how it mixes long-term and short-term data points, and how it arrives at a conclusion which is impossible to verify. Hence, it remains far more interesting to me what developers have actually been using the last 3 months, than what the total accumulated usage amounts to. Apart from public source code repo's (which fails to account for closed-source development), publisher data is another objective indicator that's interesting to follow (I.e. http://radar.oreilly.com/2009/02/state-of-the-computer-book-mar-22.html).

[Fabrizio Giudici]

Back to Dart, Gilad twittered:

https://twitter.com/#!/Gilad_Bracha/status/112181374332579840

Lots of speculation about Dart; few facts. All will be revealed at GOTO
Aarhus.

[Phil]

I was going to be flippant and say it has been and gone. Then I read
Russel's reply.

If Google are adopting Go for internal systems where it fits, do they
really care about the speed or degree of public adoption?

For internal use the language need only be focussed on solving
Google's own problems more efficiently - in the most abstract sense.
So it saves money now, or in the future (either by being a 'better'
language or by allowing Google to do more with less), or it solves a
significant pain point for the company, or it allows them to do things
they couldn't do before.

Success inside a company of that size will encourage adoption
elsewhere. If it goes quiet and stays quiet - well either the benefits
are so big that Google doesn't want to shout about them, or they've
tried it and failed.

Reminds me of some of the 'experiments' that IBM has carried out in
the past - like Fagan Inspection. Entire projects were run with it to
test and refine it. I worked at a company that used Fagan Inspection
on one project, and then dropped it. The software quality was so high
the customer cancelled the support contract. That was in the early
90's...

On Sep 12, 10:40 am, Fabrizio Giudici <fabrizio.giud...@tidalwave.it>
wrote:

> Fabrizio.Giud...@tidalwave.it

[robogeek]

On Sep 11, 6:21 am, opinali <opin...@gmail.com> wrote:
>
> - Like I expected though, web applications (in this case client-side i.e. in
> browser) will be only the first major usage scenario. Dart will eventually
> be available for the server-side too, and even for Android.

Okay, you make a good case that Google could just put Dart into Chrome
and that would perturb the choice of language for client side (in-
browser) app development. If they're smart about it, the license will
be compatible with use in Firefox, Safari, Opera and Internet
Exploiter so that there's a good chance Dart would be accepted in all
those browsers.

If Dart is running atop V8 then it can get into server-side pretty
quickly thanks to the Node.js project.

+ David Herron
http://davidherron.com/node.js

[Fabrizio Giudici]

On 09/12/2011 03:57 PM, robogeek wrote:
>
> Okay, you make a good case that Google could just put Dart into Chrome
> and that would perturb the choice of language for client side (in-
> browser) app development. If they're smart about it, the license will
> be compatible with use in Firefox, Safari, Opera and Internet
> Exploiter so that there's a good chance Dart would be accepted in all
> those browsers.
>

Concerning Android, I'm still not understanding the point. Android is
polyglot, so no doubts that one will be able to use Dart for making
Android apps. It's still unclear to me how this could solve the Oracle
lawsuit, given that it's VM based. The VM we're eventually considering
is not something new, that could have new technologies working around
the lawsuit (I must say that the patent is generic enough to make it
probably impossible to make a VM with high optimizations working around
it). It's V8, which is well known. Maybe there will be suprises at the
conference, but they talked about a *language*, not a *brand new VM*.

--
Fabrizio Giudici - Java Architect, Project Manager
Tidalwave s.a.s. - "We make Java work. Everywhere."
java.net/blog/fabriziogiudici - www.tidalwave.it/people

Fabrizio...@tidalwave.it

[Cédric Beust ♔]

On Mon, Sep 12, 2011 at 4:17 AM, Phil <ph...@surfsoftconsulting.com> wrote:

If Google are adopting Go for internal systems where it fits, do they
really care about the speed or degree of public adoption?

Very much so. If you use obscure languages that nobody else knows, you will have a very hard time recruiting.

-- 

Cédric

[Casper Bang]

> It's still unclear to me how this could solve the Oracle

> lawsuit, given that it's VM based.

It can't, but we all know that the VM is attacked as a proxy for Java the language, so it could still be used by Google to further distance themselves from Sun/Oracle technology.

> Maybe there will be suprises at the 
> conference, but they talked about a *language*, not a *brand new VM*.

Given Lars Bak's background, it's most certainly going to involve a VM of some kind, perhaps a generalization of V8 (which optimistically maps JavaScript into OO concepts  and further down to x86 code complete with a generational GC).

What would be really nice to see, is some kind of merge between Dalvik and V8. I can't help wondering why we haven't seen much of V8 in the Android browser; could it perhaps be because there had to be considerate work done in the above regard?!

[Fabrizio Giudici]

Hmm... So are you saying that there are lots of people that could work
for Google and say no just because they would work with an obscure
language?

--
Fabrizio Giudici - Java Architect, Project Manager
Tidalwave s.a.s. - "We make Java work. Everywhere."
java.net/blog/fabriziogiudici - www.tidalwave.it/people

Fabrizio...@tidalwave.it

[Fabrizio Giudici]

On 09/12/2011 07:16 PM, Casper Bang wrote:
>
> Given Lars Bak's background, it's most certainly going to involve a VM
> of some kind, perhaps a generalization of V8 (which optimistically
> maps JavaScript into OO concepts and further down to x86 code
> complete with a generational GC).
>

I think it's likely they'll talk about the VM, but I said a completely
brand new one, that it's the only way I can think of to work around the
patent issues.

> What would be really nice to see, is some kind of merge between Dalvik
> and V8. I can't help wondering why we haven't seen much of V8 in the
> Android browser; could it perhaps be because there had to be
> considerate work done in the above regard?!

Sure, there are too many VMs around. Ok where there's competition, but
where the producer is the same I'd like to see a convergence. But I
think that Android and desktop hardware are still too different.

I'd also like to know why products such as LLVM, which are supposed to
be really free (or perhaps not?), aren't considered by Google at all.

[Cédric Beust ♔]

2011/9/12 Fabrizio Giudici <fabrizio...@tidalwave.it>

Hmm... So are you saying that there are lots of people that could work for Google and say no just because they would work with an obscure language?

You seem to be implying that if people are offered a job at Google, they will take it no matter what they do or what technology they use. This might be true today because of Google's popularity as an employer, but my original claim stands: a random company using a non mainstream technology in-house will have a harder time recruiting than others.

And probably a harder time being competitive as well since the fact that the technology is not mainstream means that there will be very little external support for it (StackOverflow, books, etc...).

Whatever you are using internally, there is very little (no?) drawback to wishing it to be as mainstream as possible.

-- 

Cédric

[Phil]

OK my take here, first on Cedric's original point.

> If you use obscure languages that nobody else knows, you
> will have a very hard time recruiting.

I'm currently working for BSkyB. All my work is in Groovy and Grails,
but I'd not touched it until I started there. They recruit engineers
who can demonstrate the ability to learn and adapt, not just to repeat
what they've been doing for the last 'x' years. They also use Ruby.
Neither skill is particularly common, but the benefits outweigh the
costs of using a (relatively) obscure language. A nice bonus is that
I've yet to meet a contractor who's mindset is fixed and inflexible (I
imagine that they tend to be self-deselecting at or before interview
because they don't want to do something different). The results are
pretty good!

As to Cedric's more recent point:

> my original claim stands: a random company using a non mainstream
> technology in-house will have a harder time recruiting than others.

I agree. But my original point was that Google specifically can do
this if they choose - because of their size - if they perceive that
the benefits outweigh the costs then they have the money behind them
to simply say "we can make this better, and it is in our interest to
do so".

On Sep 12, 8:34 pm, Cédric Beust ♔ <ced...@beust.com> wrote:
> 2011/9/12 Fabrizio Giudici <fabrizio.giud...@tidalwave.it>

[opinali]

On Monday, September 12, 2011 2:27:10 PM UTC-4, fabrizio.giudici wrote:

On 09/12/2011 07:16 PM, Casper Bang wrote:
> Given Lars Bak's background, it's most certainly going to involve a VM
> of some kind, perhaps a generalization of V8 (which optimistically
> maps JavaScript into OO concepts  and further down to x86 code
> complete with a generational GC).
>
I think it's likely they'll talk about the VM, but I said a completely
brand new one, that it's the only way I can think of to work around the
patent issues.

There is no question that Dart will come with a new VM; the leaked email cannot be more explicit - "Dash is designed with performance characteristics in mind, so that it is possible to create VMs that do not have the performance problems that all EcmaScript VMs must have". The superior performance of a custom VM will be one of the major arguments to justify Dart, so I think this will be offered since the first public releases. So the major area of speculation is the nature of this VM and its relationship to other VMs that Google already makes. Due to Dart's primary field of use and also the patent suit, I'm sure it will be either a brand-new VM or an evolution of V8 that can work as a unified VM for Dart & JS. And the latter option makes much more sense for lots of reasons; primarily integration. Even if Dart is very successful, it will have to coexist with JS for a long time, including mixing of both languages in the same web apps; this can only be accomplished efficiently and seamlessly if both Dart and JS code are executed by a single VM, sharing objects in a single heap.

A+
Osvaldo