

Google introduces Dart, a new programming language for web applications - andysinclair
http://googlecode.blogspot.com/2011/10/dart-language-for-structured-web.html

======
sambeau
While Google may need this for building large applications, this is something
that the web could do without.

The web needs a standard Intermediate Language: a machine code. This is what
Javascript is becoming and it isn't well designed for it.

~~~
forgotusername
I have no idea why people keep suggesting this. There isn't a single precedent
for a "universal IL" that isn't somehow tightly bound to one implied runtime
model, type system, etc., and yet people keep calling for something like this
for the web.

Look at the "bag on the side" that is the DLR, look at the attempts at making
Jython run quickly, look at the failed attempts over the years at providing a
common IL for UNIX (e.g. start reading here:
<http://en.wikipedia.org/wiki/Ten15>), look at the resounding failure of
Parrot to become a universal VM, look at the recent rebuttals at attempts to
use LLVM as an architecture-independent format.

What benefit do you expect your "machine code" to have over JavaScript?

~~~
overgard
I agree with most of what you're saying, but I think an indirect counter-
example is C. It's not technically a universal intermediate language, but it's
widely considered to be a "portable assembly language"; which many vastly more
dynamic languages compile down to. I think the web could use it's own version
of something like C -- that is, a low level, no-frills language that maps
closer to how hardware works.

I imagine for this web version of C -- and it should be a language, not a byte
code format -- it would need to satisfy these properties:

\- language constructs that map semi obviously to machine instructions (ie,
you don't need to spend a lot of time guessing what "switch" or "while" or
"struct" get turned into), while avoiding things that might not be so obvious.
(What does a closure look like in assembly? Or a generator?)

\- types that correspond to machine types

\- some sort of predictable and low level memory model (without pointers, but
with some sort of way to avoid garbage collection issues. Maybe something with
reference counting)

~~~
tomp
You're assuming that all code found on the web is well-written, without bugs
and with no malicious intents. Both Java and CLR bytecodes are designed
specifically in a way so that they are _verifiable_ , so that the compiler can
be sure that the code doesn't do anything it's not supposed to do (e.g. access
IO functions, write to unallocated memory, spawn new threads, ...). Also, a
browser has to be able to ensure that untrusted code can only use a limited
amount of resources, that is why we have garbage collection, and VMs
(interpreted/JIT compiled code can be controlled and interrupted more easily
than native code).

Higher level constructs carry more semantics, that is why they are easier to
verify/sandbox.

~~~
overgard
I am assuming no such thing, that's why I suggested pointers and such should
be left out. I'm not actually literally suggesting that we put C in a browser,
I'm using it as a design metaphor. You can do fast and low level without C
style pointers (for example, fortran* .. not that I'm advocating fortran
either )

Sidenote: GC wouldn't prevent anyone from stealing a lot of resources. Either
way you can ask for a lot of resources and not give them back.

* Yes I know fortran has a thing called a pointer, but it's a lot different.

------
harshaw
While looking through the sample code I found this gem:

static bool isVm() { return 1234567890123456789 % 2 > 0; }

Funny enough in javascript 1234567890123456789 % 2 == 0.

------
Meai
No IDE support, no VM in Chrome yet, also no support for calling existing
javascript libraries. These three things guarantee no quick adoption. I have
no idea what Google is thinking.

~~~
jmesserly
It's a very early tech preview.

------
mathattack
I can't open the website on my iPhone. I hope that's not a karmic hint on the
interoperability of the language.

------
meric
More discussion: <http://news.ycombinator.com/item?id=3092558> (it happens to
be the top link also)

------
bni
Is the JavaScript that comes out of the Dart compiler/transpiler readable
(like the JS CoffeScript generates) or is it mush like GWT?

~~~
bad_user
That depends on how close is Dart to Javascript.

CoffeeScript is pretty close. It just changes the syntax, but the type-system
is the same.

------
mikerg87
Did I miss the part where it says this will be an open standard? This looks
like embrace and extended but I hope I am wrong.

~~~
bzbarsky
You're not wrong, sadly. See
[http://3.bp.blogspot.com/-GBSGBbc9UtA/TmexwLaJN9I/AAAAAAAAAK...](http://3.bp.blogspot.com/-GBSGBbc9UtA/TmexwLaJN9I/AAAAAAAAAKs/06OaexCT5Ms/s1600/Lead%2Bdevice%2Bconcept.png)
for a discovery document from a recent court case that indicates what Google's
approach to things like this is nowadays.

------
pacemkr
I was expecting something more innovative.

All it is is a javascript like language with classes, interfaces, optional
types, and some extra built in data structures. A new runtime, biggest
obstacle being adoption, just for that seems a bit much.

------
frou_dh
That page crashed MobileSafari on iPad and continues to after a reboot. Is it
just me?

~~~
leonlee
It's sending me back to Hacker News after it completely loads on my
Blackberry.

~~~
brackin
Just go to Dartlang.org it's crashing in safari.

~~~
calloc
Safari 5.1 on Snow Leopard, no crashes here.

------
thomasfl
The optionally static types in the Dart language seems like a good idea. You
get both beautiful, simple code, like in Ruby, and the possibility to speed up
execution by adding types later.

On the other hand, you still don't have the great community like for instance
ruby has. Charles Nutter has created a static typed ruby like language, called
Mirah, which looks similar.

~~~
Peaker
Full type inference also lets you write beautiful, simple code -- without even
needing to add types later, you get them now. And speeding up execution is
just a bonus, the main benefit is catching errors early, and refactoring
safely.

~~~
bad_user
You cannot add "full-type inference" on top of a language with a dynamic type
system. You also cannot add such type inference to an object-oriented
language, like Scala (it may be possible, but very hard and nobody did it).

    
    
         the main benefit is catching errors early
    

Dynamic typing isn't about not specifying types. Dynamic typing is about
creating types at runtime.

This enables certain techniques that are very productive, and totally
different from what you would do in a language like Haskell, which does have
full-type inference.

I also do not think a static language would work as a client-side in-browser
language, simply because of the nature of browsers and the web. Such a
language needs runtime introspection and even types created at runtime like
air. For in-browser stuff I also prefer eval() over static-typing any day of
the week.

~~~
Peaker
There's an real conflict between static typing and eval() or reflection.

eval() is shown to be usable in a static typing environment by some of Don
Stewart's papers, though it does take more effort on the language
implementors' side.

Reflection is achieved in Haskell, for example, using reflective type-classes
(such as Typeable and Data).

~~~
Peaker
Doh, too late to edit.

Above should read: "There's no real conflict"

------
thirsteh
One of the design goals: "Ensure that Dart delivers high performance on all
modern web browsers and environments ranging from small handheld devices to
server-side execution."

Server-side execution? I thought Go was their systems programming language? It
sure sounds like they're competing rather than complementing each other.

~~~
almost
There's a lot of server side programming for which Go probably wouldn't be the
ideal language. Room for more than 2 languages in the world I think :)

~~~
thirsteh
Like what? Go is an absolutely excellent language for server-side programming.
I've yet to find anything it wasn't suited for.

There's room, I just don't get why Google would promote two of its own very
similar languages for the same purpose at the same time.

~~~
almost
What do you mean by "server side programming"? That's a pretty wide net to
cast. Do you really think that Go is the ideal language for every bit of code
that doesn't happen to run on a client of some sort?

------
grandalf
This is a great idea. With optional typing + V8 this could be really fast.
Google can leverage its strengths while opening up a language that lots of
people already know to additional server side use.

------
rorrr
Unless all major browsers support it, the adoption will be painful and slow.

It also seems like another incarnation of GWT, which, I heard, google
abandoned.

~~~
macavity23
From the article:

"Dart code can be executed in two different ways: either on a native virtual
machine or on top of a JavaScript engine by using a compiler that translates
Dart code to JavaScript. This means you can write a web application in Dart
and have it compiled and run on any modern browser."

What am I missing?

~~~
saiko-chriskun
not much ;)

------
saiko-chriskun
yes finally an alternative to javascript! zomg so excited :3

