Hacker Newsnew | comments | show | ask | jobs | submit login
More information on Google's new web language, Dash (markmail.org)
256 points by praxxis 1421 days ago | 141 comments



As an ex-MSFT person, this doc sounds like a Microsoft doc more than something you would see from Google.

And I'm amazed at sentences like these - can you imagine MSFT saying this and getting away with it? "The goal of the Dash effort is ultimately to replace JavaScript as the lingua franca of web development"

and

"What will Google developers be using? We will strongly encourage Google developers start off targeting Chrome-only whenever possible as this gives us the best end user experience."

-----


And also: ”Developers using Dash tooling will be able to use a cross-compiler to target Javascript for browsers that do not support Dash natively.”

Not very different to having native support for e.g. CoffeScript in browser X and supporting other browsers via JS.

Of course the main issue is that this is yet another language. Since all browsers are essentially becoming poor man’s virtual machines, why not drop the pretense and adapt some kind of bytecode instead. There’s JVM/CLR/LLVM/NaCL — just pick one already! Alas, politics (Oracle/Microsoft/Apple/Google).

Well anyway, Dash is a very positive news nevertheless. The biggest issue with current cross-compilers (GWT, Pyjamas, Haxe etc.) is that they lack good tools to develop and debug. Having support for those natively, there’s hardly any reason to target JS directly anymore. And once Chromium has the infrastructure to support more than one language, it’s possible that the abstractions will be general enough to add support for other languages as well.

“Our approach is to make an absolutely fantastic VM/Language and development environment and build great apps that fully leverage it in order to help other browsers see the wisdom in following. Once Dash has had a chance to prove its stability and feasibility, we are committed to making Dash an open standard with involvement from the broader web community.”

-----


Mainly browser-vendor politics - MS/Apple/Opera/Mozilla. A proper runtime would weaken their chokehold over the Web client. It's almost certainly not a coincidence that the one major browser vendor which does support a VM is the one which is mainly interested in the Web client as a platform for its applications. Of the other four, two have strong interests in holding back the Web as an alternative to OS-native applications, while the remaining two are more or less nothing without their position of power over Web standards.

-----


I can't figure out what you're implying. Why would the two organizations that are "more or less nothing without their position of power over Web standards" be opposed to making the Web better able to compete with native apps? After all, if the Web loses to iOS and Android, then Opera and Mozilla become irrelevant.

The reason why Opera and Mozilla oppose bytecode standards is that they genuinely think they're a bad idea. I mean, we tried that once; it was called Java. It lost to JavaScript.

-----


Java (in the browser) was a plugin that was mostly completely sandboxed from the real page DOM with its own entirely separate (and very poorly designed -- AWT was horrendous) attempt at a UI layer. That's the problem it had, not the fact that it was a byte-code based VM.

Make the byte-code VM a first class citizen and things are completely different.

-----


Even having the option to load a single JVM instance and share it between different frames/pages/tabs would be a tremendous improvement over current situation. At the present, the best you could do is to fake it using inter-frame communication (and some heuristic to elect most-likely to live longest), which is only slightly less bad.

-----


NaCl is LLVM, bby the way. Portable NaCl is really cool though - it's an intermediary LLVM bytecode that's cross platform.

-----


The next version of NaCl, called PNaCl, will be LLVM. Right now it's all native code (x86, x64, or ARM).

-----


Just wondering, how do you know it's going to be the next version?

-----


It's already under development. Here's the (perhaps optimistic) roadmap: http://www.chromium.org/nativeclient/pnacl/release-roadmap

-----


I'm not sure what you mean by Haxe debugging. That happens with whatever run time debugger you have for js, php, etc. As far as development goes, there's flashdevelop, an eclipse plugin, a few textmate bundles, a vim package, etc. http://haxe.org/com/ide

If you don't mind me asking, what part of debugging/development in haxe turned you off?

-----


I’m not familiar with haXe all that well, just enough to include it in the list. However, in the end haXe is too, statically translated into Javascript. GWT has an excellent debugger as well, but there’s only so much you can do on that level of indirection.

-----


"Just debug the machine-generated code instead" is not really an answer.

-----


You can say whatever you want until you've squandered the public good will, and then the public will skeptically peruse even the most innocuous of words coming from your mouth.

People's skepticism of Microsoft is based on what they (MS) have done in the past.

-----


Indeed. Especially worrying for me was this phrase which appeared a few times:

> Developers who can focus solely on Chrome can [..] Developers focusing on all browsers will have to [..]

This seems to imply that Chrome is the preferable target: If developers can focus soley on Chrome, they should. Or if they must target all browsers, which is less desirable in the viewpoint here, then there is some tier-two option.

Scary stuff for anyone who cares about the open web.

-----


They mean that you can use Chromium as your primary target — your development stack — and their cross-compiler will take care of supporting legacy/incompatible targets. This is just like GWT does now and it seems the technology (apart from VM, grammar and debugger) will build on the existing codebase of GWT and the Closure compiler.

> What happened to JSPrime?

> The JSPrime effort was begun to unify and be a (single!) successor to GWT and Closure/JSCompiler, suitable for large-scale development inside and outside Google, including being amenable to IDE-like tools and static compiler optimizations. The JSPrime team is happily folding its efforts into Dash now that everyone agrees Dash will explicitly include the same goals.

-----


Don't be ridiculous. The entire spec is to be open source. This is nothing like Internet Explorer. If Internet Explorer played this nice when it wanted to innovate (AJAX) from the beginning it would probably still be relevant. Is Mozilla the only corporation allowed to create new web features now?

This backwards compatible approach isn't exactly Google's idea and it's a good one. Having a backwards compatible, faster, and more sane web language is going to improve developing the open web. Why should anyone be scared?

-----


This is exactly as open as Android. The language is developed entirely in secret, and code is dumped into a repository on the day of a big announcement. Google's preferred partners (in this case, Chrome) get to see the source before the public does.

Quibbling about whether this qualifies as "open" or not is arguing semantics, but I think recent history has shown that the Android model doesn't lead to the openness that its proponents had suggested it would.

-----


I agree completely. The developing stuff in secret and play fast and loose with the definition of open source works fine with their own platform. The Web is everyone's platform. I find it a tad insulting to be blocked off of the process and then be told that the Elite Engineers of Google have solved this problem for us.

There doesn't have to be an exact parallel between this and ActiveX for this to be bad. Mozilla announced about a month ago that they would be developing a not-yet-cross-platform set of APIs called WebAPI. Except they invited any one to participate. I'm subscribed to their mailing list and actively participating. I can submit patches if I so choose. Dash sounds like an almost-finished product that the rest of the community has to either adopt or opt-out of.

-----


This point might be valid in general, but it can't apply to programming languages. There is no way to do language design in a committee (one might have a shot at enhancing an existing language, but it's difficult).

-----


There's a difference between (a) doing some language design work in private and (b) doing an entire language spec, as well as all the implementation, in secret, then one day shipping it to users and telling everyone else "here's how it is, now standardize this".

I'd also argue that languages on the Web should be held to a different standard than general-purpose languages, since there are five primary players and the Web as a whole will be worse off if some of the browsers refuse to implement what other browsers are pushing.

-----


Just because it is open doesn't mean the other browsers will, or should, implement it. NaCl will never see the light of day in other browsers even though it is entirely open-source.

Until NaCl, Dash, and whatever other stuff they decide to shove into Chrome, makes it into a standards body and is recommended by WHATWG & W3C, it is an attack on the Open Web.

Don't put stuff in a browser that isn't web standards compliant, I thought we already learned that lesson?

-----


How did we learn that lesson when Microsoft did exactly what you're describing when they created XHR, and now almost every website uses it? It took 6 years for it to become standard, and I almost doubt it would have if it wasn't already in every browser by the time it did. My personal opinion is that this type of behavior boosts competition and helps innovation. If it's something clearly useful others will implement it or become obsolete. Waiting for a committee to standardize a feature before implementing it sounds like it would slow the web down to a halt. Mind you I already consider it to be painfully slow just looking at how many years it took to get 20-30 new functions into JS runtimes.

-----


I think it's more practical for browser vendors to develop ideas (in the open, not like Dash) and use vendor prefixes (-o, -moz, etc.) and then bring those ideas to the standards bodies. We've seen this a lot recently, particularly with mobile. meta viewport tag was not brought to standards bodies first, Apple developed it and everyone else adopted it. To my knowledge it's still not part of WHATWG, although I'm sure it eventually will be.

-----


There are some examples that can convincingly target Chrome only, e.g. Chrome extensions

-----


"cyclone of innovation"? Sigh.

But it seems like an attempt to supersede JS with something significantly better before JS becomes further entrenched as the dominant language for nearly everything (slight exaggeration of what lots of people are saying) is worthwhile.

I wonder what Google's internal prediction markets (if they still have those) says about chances of success.

-----


Didn't you see Brad Abrams' name on that list? After all, the more things change...

And yeah, I agree: it felt exactly like reading an internal MS memo...but ballsier.

-----


And Peter Hallam, original J#/C# compiler dev lead, IIRC.

It's like an ex-MSFT .NET party over there!

-----


I did not know that. Hilarious :)

-----


From the Executive Summary: "Push for Dash to become an open standard and be adopted by other browsers."

I think the "Don't be evil" factor is well represented on that sentence.

-----


It's clear that adoption by other browsers is a prerequisite for really being able to use this, unless Chrome manages to corner the browser market.

It's clear that other browsers won't adopt something like this without an open standard.

So this is not "don't be evil" but simple pragmatics.

"Don't be evil" would involve doing something other than presenting a fait accompli to a standards body and asking for a rubberstamp.

-----


> Lars has promised to “sweet talk” the other browser vendors

Sweet talking is no evil!

-----


I can't believe any self-respecting dev would ever use the term "lingua franca".

-----


America fuck yeah! Literacy is for faggots!

-----


Don't try to associate literacy with douchebaggery.

-----


Whenever I look at all these old and new curly-brace languages, I imagine a world where they are different runtime libraries for the same language instead, and no one has to learn the subtle syntactic differences introduced by the latest group of well-meaning overlords.

I mean, there's only one widely accepted way to write a "for" loop in a curly-brace language, right? Only one possible syntax for the ternary operator. One obviously right way to organize classes and imports. A couple competing ways to declare types (Foo foo or foo:Foo), but perhaps we as a community could make a bold choice just this once? One obvious syntax for generics, and so on.

The lowest common denominator I have in mind looks almost exactly like early versions of Java, except with optional typing ("var"), some rudimentary generics and without checked exceptions.

There seems to be no good reason for new languages like Dash to embrace a different style. And there's one big reason why you'd want source-level compatibility: polyglot libraries! For example, there's a rather huge open source library for dealing with geographical coordinate systems, basically a huge bunch of complicated math with almost no platform dependencies. How awesome would it be to have it compilable for the JVM, the CLR and the Flash player from the same source code?

I'd imagine many shops would jump at the chance to future-proof big parts of their code in this way. And the syntaxes are already so tantalizingly close to each other! Juuuust different enough to enable platform lock-in...

-----


There is much much more to programming languages than syntax. If syntax was the main difference between programming languages it would be very easy to write translators from one language to another. Lots of people like their pet language more than JavaScript, so why don't we see tons of compilers like Python->JavaScript, Lua->JavaScript, Ruby->JavaScript etc?

The answer is that syntax is just the tip of the iceberg. Even ignoring major language differences (garbage collection, static vs. dynamic typing, lexical vs dynamic scoping, eager vs. lazy, threads vs. coroutines) there is an incredibly long list of very detailed semantics that you probably don't even realize you're dealing with when you move from one language to another. For example:

  - in a complex inheritance hierarchy, which method is selected for a.b?
  - how much precision do numeric types have?
  - what happens when numeric types overflow?
  - what order are arguments evaluated in?
  - what happens if fewer arguments are passed than were declared?
  - are keyword arguments supported?
  - are default arguments supported?
  - when are default arguments evaluated?
  - are simple types like integer and string classes?
  - can they be subclassed?
  - can they be monkey-patched?
  - will types be implicitly converted?  (ie 1 + "2")?
  - does 0 evaluate to true or false?  what about "0"?
  - are function arguments passed by value or by reference?
  - are values hashed by their identity or by their logical value?
  - what hooks can you define to customize the behavior of your object?
Nothing in this list is about syntax. Syntax is just the tip of the iceberg when it comes to what makes languages different.

-----


> Lots of people like their pet language more than JavaScript, so why don't we see tons of compilers like Python->JavaScript, Lua->JavaScript, Ruby->JavaScript etc?

Uuuuhhh, I'm really embarrassed to ask, but did you check with Google before posting that? "Tons of compilers" is exactly what we have now: https://github.com/jashkenas/coffee-script/wiki/List-of-lang... . In fact my own job involves writing Java code that ends up being compiled to JS.

I'd be overjoyed if such things were not necessary. I would even be okay with never using things like 1 + "2" or monkeypatching in 50% of my code if that made that 50% conform to some widely adopted cross-language standard. That would mean 50% less effort spent on any future rewrite. 50% less risk from using the new and shiny platform that came out yesterday. 50% lower rate of platform-induced bitrot for the project as a whole. C'mon, who wouldn't want the world to work like that?

-----


It sounds like you're not looking for a bold choice; you're looking for language innovation to stop.

The only widely accepted for loop syntax is the C-style for loop, which was invented 40 years ago and is vastly inferior to for..in loops, ruby's .each / .each_index and python's list comprehensions. That says nothing of generics[1].

The reality is, we can make much better languages today than Java or C#.

[1] http://weblogs.java.net/blog/arnold/archive/2005/06/generics...

-----


As a consumer of programming languages, I'd like the evolution of languages in the mainstream to be less incremental and more punctuated.

If you make a new language that's exactly like the old language but has a slightly tweaked syntax for one or two little things (e.g. changing the capitalization of the name of the string class), you're forcing lots of programmers everywhere to rewrite their code in the new flavor. You're forcing companies everywhere to spend more resources on hiring, retooling, etc. And you actively contribute to bitrot by weakening the incentives to keep old code running as-is on newer runtimes, because "no-one writes such code nowadays anyway". It's basically a lot of waste that could be avoided.

The jump from C++ to Java was big enough: it introduced garbage collection, proper modules, proper strings and other nice things into the mainstream. The jump from Java to Python, if it happens, might be marginally big enough to merit rewrites (we gain many nice small-scale constructs like dicts, generators and list comprehensions, but lose the IDE tooling and guaranteed-correct refactorings enabled by static types). The jump from JavaScript to Dash doesn't seem big enough to justify all the busywork. Please come back in five years with more shiny things.

...A man can dream, can't he. Obviously the big guys will keep introducing new languages where a new library or a new runtime could've done the job. They have incentives to do so. But it's not so pleasant to the rest of us.

You'll note that I have avoided using the word "innovation" so far. That is because genuine language innovation generally happens outside of the mainstream and takes decades to percolate. For example, the idea of list comprehensions is older than I am (NPL '77). For that matter, so is the idea of lazy pure functional programming (SASL '76), and the idea of parameterized types (ML '76), and any number of other ideas that people mislabel as "innovative" to justify creating new languages today. Adding 30-year old features into curly brace languages, bit by little bit, and forcing us to rewrite all our code at every step doesn't sound to me like the noble practice of innovation. It's more like a big coordination trainwreck.

-----


As a consumer of programming languages, I'd like the evolution of languages in the mainstream to be less incremental and more punctuated.

While there is such a thing as punctuated equilibrium, I believe you'll find that evolution is largely incremental in nature. Seems like evolution simply has to happen this way, whether we're talking about biology or technology, including programming languages.

-----


> The jump from C++ to Java was big enough

You are aware that many people still write C++, yes?

-----


Today's C# is much better than its original Java-clone status. I wouldn't brush it aside lightly.

-----


The article is specifically about generics in Java. I don't know Java generics, just the c# ones, so it's hard for me to say if the author is right about generics in java only or just wrong in general. Either way, a pointless article for this discussion.

-----


You presume syntax is like fashionable clothes all decorating the same basic thing underneath; that's not at all true. Syntax is a reflection of the underlying differences in semantics of these languages, they're not just decoration.

You can write procedural C style in any language, but you're not really using the language if you aren't using its idioms which will inevitably reveal the reasoning of its syntactical choices. Lisp is a perfect example, as is Smalltalk.

-----


I explicitly talked about minor syntactic differences between curly-brace languages, not about Lisp or Smaltalk. Switching from one curly-brace language to another generally doesn't involve any deep paradigm shift, it's essentially just memorizing a bunch of irrelevant syntax differences. If I have some procedural C style functionality implemented the same way in languages X and Y (happens pretty often), having the code 95% identical is missing out on the nice things that I could have if the code were 100% identical.

It's true that the Java runtime and the C# runtime provide different services. But the same is true for databases. Oracle's feature set is different from PostgreSQL's. Yet the database community got its act together enough to standardize the syntax for basic features at least, so you don't have to relearn inner joins when you switch, and you can mention "SQL" in job openings and be understood. (I wonder if the NoSQL community ever gets smart enough to do the same?)

-----


BS. Syntax is exactly like fashionable clothes. It's irrelevant to how warm your clothes are.

The number of developer years wasted coming up with yet another programming language or syntax is staggering.

It's a solved problem. Pick an existing syntax and use it.

You don't see people endlessly coming up with new syntax for math do you. We've got one, it works well, so we use it.

-----


> It's a solved problem.

No it isn't.

> You don't see people endlessly coming up with new syntax for math do you.

Actually, yes, yes you do.

-----


There are many mathematical notations for the same things, usually depending on the domain or different focus. Just like with programming languages.

-----


Choice of syntax affects how easy it will be to create tools for the language (IDE syntax highlighting, code browsing/navigation, automated refactoring, etc). There is still plenty of room (and need!) for improvement, for innovation. At the other extreme, imagine a world where every language used C++'s syntax.

-----


Imagine a world where instead of writing books, authors spent forever needlessly inventing new languages to write them in.

-----


They already do both; have you not ever read Lord of the Rings?

-----


There are more differences between steel-toed boots, sandals, and stiletto heels than just how warm they are. In modern times it is also rather rare to encounter individuals wearing togas and/or powdered wigs. I'm not convinced that fashion is a complete explanation for these phenomena.

-----


FYI (based on comments in this thread made by you and others), C# is nothing like Java, despite similar C-derived syntax.

-----


... Flash player?

-----


In the FAQ section, they mention a "Cloud IDE" named Brightly, which frankly seems more interesting than the language itself:

"How does this affect our cloud IDE (Brightly)? Brightly will enable building any web application in V1 using today’s Javascript plus the additions in Harmony. As soon as it is ready, Brightly will support Dash as well. We expect that the more prescriptive development aspects of Brightly that will come on line in the future will be more Dash focused."

-----


Google is working on a web-based IDE named Brightly for building JavaScript and Dart apps.

source: http://geddesign.com/post/10097230191/google-dart

-----


Maybe rather than a new language, we should work towards browser "assembly" code. Lots of modern JavaScript development is in the direction of: write in language X, compile to JS. Would be nice if there was a lower-level target than JS

-----


They are doing that with NativeClient. It runs x86 assembly and LLVM IL in the browser. Supposedly they'll even make it work in other browsers than Chrome.

-----


NaCl does not allow direct manipulation of the DOM or provide other JavaScript APIs like canvas. NaCl provides alternative ways of getting things done like pp::Graphics2D, but it is not meant for DHTML. Dash, on the other hand, provides access to JavaScript APIs.

I think that browser "assembly" code, like Dash, would have to support this, particularly if it is meant to be an alternative to compiling to JavaScript.

-----


Pepper is the link between NaCl and browser APIs.

-----


PNaCl seems like a separate project from NaCl to me, and NaCl itself can't run LLVM IL.

Also, there's really opposition of having it implemented in other browsers, at least Mozilla vocally opposed it. I think that if they managed to do it via a plugin though, that could work.

-----


Agree 100%. The fact that Javascript is the only language you can realistically use to script the browser is a terrible limitation and legacy of bad technical decisions at Netscape more than a decade ago. I'm always surprised at the lack of concern about this.

While I do actually like Javascript a lot, I think we need to have more choices. When people point out Node as a benefit because "you can use the same language on the client and the server" I agree - but it misses the bigger problem in that, if you want to use the same language on the client and the server, you only have one real choice.

-----


I have a feeling that Dart may be some version of Bracha's Newspeak. If you read his blog post on Javascript's failings, you'll see him talk about how they are already trying hard to have Newspeak fill the gap:

http://gbracha.blogspot.com/2011/03/truthiness-is-out-there....

There is also an uncanny link between the features Dart highlights -- security, optional typing, modularity -- and Newspeak. The timing of Newspeak development and Google's Dart also coincide perfectly. The blog post talks about a Javascript compiler, pluggable type system, IDE (Brightly?) all being in the works.

Newspeak's pluggable type system sounds similar to what is known about Dart. For instance,

http://bracha.org/newspeak.pdf

> We also intend to extend Newspeak with an optional type system and a framework for pluggable types , enabling the language to enjoy most benefits of static type systems without incurring their limitations.

It also seems like a smart engineering choice to base whatever Dart is heavily on some proven language, even if there is a new VM. Given that Newspeak is Bracha's most recent attempt and it's goals are so well aligned, it's hard to imagine he'd start from scratch.

-----


Newspeak has a very cool IDE (that is written in Newspeak). Maybe this "Brightly" is just that with HTML/CSS as a presentation layer. I belive he said that its written in a way that could make it possible to replace the presentation layer.

-----


Maybe Dart does not require HTML/CSS.

-----


I really wish that we would see a concerted effort to get Python in the browser (or anything reasonable, really) rather than creating yet another new dynamic language that needs half a decade to grow a decent ecosystem. JavaScript has been around for years and only in the past few years have we seen a legitimate developer ecosystem emerge around it.

-----


I think that going from a language with real genuine closures to one with the half measure that Python has (lambdas) would actually be a backwards step.

Plus I agree with the other (downvoted) commenter that whitespace would be a huge annoyance. A language for the web has to be something robust to copying and pasting to / from web pages.

-----


Closures and lambda (anonymous functions) are orthogonal features. Python has closures (and one last limitation related to scope and rebinding was fixed in Python 3)

Furthermore although I agree Python's limited lambda's make it slightly uglier to do some constructs, it's merely syntactic sugar.

First-order functions are the critical feature. Whether you are compelled to give them a name or not isn't critical.

-----


That's because heavyweight clientside applications are only a more recent thing and JavaScript engines have improved alot.

JavaScript is great for event based programmming because of it's scoping rules. Python can't offer that.

That's why a few langang

-----


what scoping rules make javascript better than python for evented programming? I am not a big JS writer, but I can't seem to see anything important (nested functions, globals).

Maybe you are referring to the fact that JS has an arguably better syntax for anonymous functions?

-----


Python has implicit declarations, which lead to a world of hurt because you can't directly modify variables in arbitrary scopes. Python 3 has nonlocal, but that only extends the number of function scopes you can refer to to three.

I think having implicit declarations is probably the worst mistake Python made. It just makes things so much more confusing.

-----


Sorry, I made a mistake: nonlocal gives you as much power as usual closures. I still stand by my statement that implicit declarations make things very confusing.

-----


In python nested functions must be declared before calling them. Also stuff like this seems to crop up on me when I ry using closures: http://stackoverflow.com/questions/2516652/scoping-problem-i...

-----


that is what I meant as having a better syntax for anonymous functions. I agree it's bad (even with nonlocal in python 3) but that is not a matter of different scoping rules, it's only syntax.

-----


Wouldn't Python's use of whitespace to indicate nesting be annoying? JavaScript sometimes gets into pages embedded in script tags (as opposed to be being loaded from external files by script tags), and this is sometimes done by being echoed by server-side PHP or something similar.

Having to deal with getting the whitespace right while doing that could be annoying, and would also make the code much harder to read on the server side.

I think for this application, the more forgiving a language is about layout the better.

-----


coffeescript is probably the next closest thing. I think I remember firefox and/or chrome will enable it soon.

-----


This is from a year ago, but this is also the first time I've heard of it. Do we know the progress of this movement today? Googling for "Dash Language" and variants doesn't give me anything of note.

-----


Google is unveiling this new language at the Goto conference next month:

http://gotocon.com/aarhus-2011/presentation/Opening%20Keynot...

-----


There you go https://plus.google.com/112643613234453381402/posts/XTDu92t9...

Edit: this one says Dart, not Dash

-----


Calling it 'Dart' is rather confusing, given that there's already an existing Google product called DART: http://www.google.com/doubleclick/publishers/dart.html

-----


And Dash is confusing because there is already a shell/language called dash: https://secure.wikimedia.org/wikipedia/en/wiki/Debian_Almqui...

-----


So is it Dash or Dart? It was referred to as Dart earlier in the week when someon linked the conf that Lars Bak / Gilad Bracha (spelling) would be revealing all at. I'm confused now.

-----


It is Dart.

-----


But considering Google already stole the name "Go" from another language, it's likely that they just don't care.

-----


>Developers using Dash tooling will be able to use a cross-compiler to target Javascript for browsers that do not support Dash natively.

So it'll have all the inherent downsides of Javascript, because you can't cross-compile without restricting the abilities. I wonder how they feel about CoffeeScript?

At least Mozilla is trying something completely different with Rust. Maybe they could support that effort instead?

-----


Rust isn't intended to be run by Web content. It's designed to be a systems language. In that regard it's more comparable to Go.

-----


Later in the document they say that only a subset of Dash code can be cross-compiled into ordinary JS.

-----


Ah, thanks :) I didn't wade through the whole thing. There didn't seem to be a whole lot about the language itself.

-----


Hidden away in there is the news that Google plans to obsolete GWT.

Sorry, I mean "support teams for a long time on the current generation".

-----


There seem to be quite a few ex-Microsoft people involved.

-----


I Like the ethos behind Dash but language design is also an art, and judging by Go - Google is not very good at it.

-----


Wow, way harsh.

Those of us that actually use Go are pretty enamored with it.

-----


Let me explain, Rather than trying to make a language as aesthetically pleasing to the programmer as possible, the Go team tried to get by its limitations with design kludges and workarounds that are visually less appealing and intuitive then the many well-designed solutions that preceded it, e.g:

  - Error codes are a poor substitutions for Exceptions

  - Have to code around lack of generics, e.g. by abusing their typed map if possible 

  - Defer less desirable and intuitive than C# using

  - array bracket notation prefixing the variable

  - No proper classes?
I mean, take their example on a File type (http://golang.org/doc/go_tutorial.html):

type File struct { fd int name string }

func (file File) Read(b []byte) (ret int, err os.Error) {}

func (file File) Write(b []byte) (ret int, err os.Error) {}

file := &File{fd, "file.txt"}

The same signatures in CoffeeScript can be achieved by:

class File

  constructor: (@name) ->

  read: (cb) ->  

  write: (contents) ->
file = new File "file.txt"

Which I'm sure a majority of people would find a lot more readable.

Just for kicks I decided to rewrite Go's Cat example to StdOut in CoffeeScript for a side-by-side comparison. The examples are fairly close but not exact, i.e. cat.Go implements via streaming while CoffeeScript's is non-blocking.

https://gist.github.com/1207994

The CoffeeScript version ways in at 12 LOC, while Go's example is over 110 LOC and a lot more unfriendlier on the eye.

-----


I didn't want to get into a slinging match, but I take issue with all of your points.

"Error codes are a poor substitutions for Exceptions" This is debatable.

"Have to code around lack of generics" Some people complain about this, but in practice their absence hasn't been a big problem. It's still an open issue, though.

"Defer less desirable and intuitive than C# using" Again, debatable.

"array bracket notation prefixing the variable" http://blog.golang.org/2010/07/gos-declaration-syntax.html

"No proper classes?" This is a bizarre complaint. Go doesn't have classes. It has types and methods. Why would you need classes? What is a "proper" class?

The tone of your complaints implies that we didn't consider any of these things, or that these decisions were made through sheer incompetence. This couldn't be further from the truth. Language design is just as much about what you exclude as what you include. One of Go's major strengths is its simplicity. It's a very small language; so small, you can read the spec in one sitting! http://golang.org/doc/go_spec.html

As has been pointed out already, your comparison between Go and CoffeeScript is not illustrative of much. Go is typed, CoffeeScript is not. The "cat" comparison is very strange. Your (very unidiomatic, and in some places plain wrong) Go program re-implements everything from a syscall level, while the CoffeeScript example uses library calls. Why?

Here's how one might write a similar "cat" in Go:

    package main

    import (
        "io"
        "log"
        "os"
    )

    func cat(name string) os.Error {
        f, err := os.Open(name)
        if err != nil {
            return err
        }
        defer f.Close()
        if _, err = io.Copy(os.Stdout, f); err != nil {
            return err
        }
        return nil
    }

    func main() {
        for _, arg := range os.Args[1:] {
            if err := cat(arg); err != nil {
                log.Print(err)
            }   
        }
    }
This handles multiple files specified on the command line, and handles errors. (The CoffeeScript one just throws them, right?) Not bad for 24 lines of code.

-----


If you considered them it's even worse - by keeping the language simple you've made it more unintuitive and less readable for the programmer. IMHO the primary beneficiaries of Go are the compiler writers, not the programmers having to read and write source code.

Your example is not the same, this is just a C-style single method. The whole point of my example was using Go's own sample source code to showcase the hacks needed around structs to get around the deficiencies in not having classes. The resulting struct method signatures are ugly, verbose and unintuitive - it's not nearly as readable and wrist friendly as grouping them in a single class definition.

In following this pattern the defer keyword is a magic method that doesn't visually demonstrate its behaviour - compare that with C#'s using statement which does.

-----


If that's what you were trying to demonstrate then you were pretty far off the mark. The two programs are far from equivalent, and your Go code is just bizarre.

I think this statement of yours is quite revealing: "Your example is not the same, this is just a C-style single method." It's not a "single method," it's a function. Not everything is or should be about object orientism. It's not always the right choice, and people who obsess over making everything an object (those who think functions are a special type of method) are doomed to overcomplicate their design. (For example, there is no reason you should need to construct new objects to write cat.)

I'm confused as to why someone who clearly doesn't know Go would try so hard to discredit it. What's your motivation?

-----


The Go code is bizarre? That's the introductory Go tutorial showing off Types in Go (http://golang.org/doc/go_tutorial.html) Not a single line of the Go code is mine (I just copy and pasted the entire tutorial in a single file). If you want to blame someone for making Go look bad - blame the author of the tutorial - or better yet the inventors of the Go Language.

If you think OOP is not important for building and encapsulating large software code bases, then we operate in different worlds and Go wasn't designed for my purposes in mind. Feel free to keep using Go as a better C and I'll stick to mainstream languages without these deficiencies (aka trade offs).

-----


Just to play devil's advocate, here's what that example would look like with exceptions and something like `using()` in C# (here, any curly block can implicitly be treated like a try block, like in Ruby):

    package main

    import (
        "io"
        "log"
        "os"
    )

    func cat(name string) {
        using (f := os.Open(name)) {
            io.Copy(os.Stdout, f)
        }
    }

    func main() {
        for _, arg := range os.Args[1:] {
            cat(arg);
        } catch (err os.Error) {
            log.Print(err)
        }
    }

-----


That's a terribly biased comparison. The go example defined stdin/stdout/stderr from scratch and much else besides, while the coffeescript version basically called a library function.

It's very hard to compare statically-typed system languages with dynamically-typed HLLs. And it's utterly misleading to judge one by the standards of the other.

-----


Your comparison is unfair, because CoffeeScript and Go try to do vastly different things. Go is a fairly low level systems language, while CoffeeScript is as high level as it gets.

That said, what Go achieves with its syntax is remarkable, imho.

Consider this: How do you add another function (e.g. "close()") to your file class in CoffeeScript? By extending the existing class into a "MyFile" class? But then you have to make sure all your "File" instances are actually instances of "MyFile", so you can call your newly defined function on them.

In Go you just define the new function.

-----


Not to detract from your point of vastly different things, but you picked a bad example. You add a method to the prototype:

    File::close = ->
Et voilà, all Files are closeable.

-----


Nice, I didn't know that CoffeeScript has a shorthand for .prototype.

So, to revise my point: with "proper" classes (i.e. Java or C++) this wouldn't be possible, or at least more complicated and not the way to do things. Classes are not the ultimate solution and it's a good thing that Go tries a different approach to OOP.

-----


Nice logic! Shell is better than CoffeeScript or Go:

    #!/bin/sh
    cat file.txt

-----


I always liked Perl's version:

    perl -e 'while (<>) { print; }' file.txt

-----


I like Perl's other version:

  perl -p file.txt

-----


As are those who use just any language/environment of their choice. So what?

-----


Speak for yourself, I really don't like Go.

-----


Your best bet is to check out Strongtalk to see if the main designers have a good artistic sense. It actually has a number of similarities to how Dart/Dash is described.

http://www.strongtalk.org/index.html

Although perhaps because it's Smalltalk you can't learn much from this example.

-----


First Go now Dash, Google should really google for these names before choosing them

-----


That's probably the least of your concerns, especially when you have a near monopoly in the search business.

I think by choosing a not so unique name, they're ensuring that people remember to prefix these names with Google (Google Go, Google Dash etc). This should has a significant effect on Google's branding.

-----


How is "Dash" any less unique than "Python", "Ruby", "Lisp", "Java", "Basic", etc? We only associate those names with languages because those languages are established; I doubt googling "Ruby" in 2000 would have resulted in anything but minerals on the front page.

-----


Dash[1] (Debian Almquist SHell) has been around since the early 2000's and is the first thing that I thought about when reading the title of this post.

1 - http://en.wikipedia.org/wiki/Debian_Almquist_shell

-----


This looks like (from my admittedly limited perspective) an attempt by Google to build their own language ecosystem to reduce the reliance on Java and limit any potential future liability from patents held by sun/oracle.

-----


Why do you say that? The post doesn't mention Java, and is talking about an area (in-browser scripting) in which Java is largely irrelevant.

-----


I think Java prominent by its omission. So much so that it underlines the GP's point exactly. When you read all the stated goals of the project you can basically put a tick next to Java on every one:

    - runs in all browsers
    - works client side and server side
    - scales from large projects to small projects
    - contrary to your point, supports in browser scripting (admittedly, crudely).   
    - highly performant (with some specific issues)
They could easily inherit nearly all of these qualities by starting with the Java VM and going from there. The reasons not to basically boil down to NIH, politics and the encumbrances (not sure if there is a way to tightly embed a GPL engine inside a non-GPL product, but at this point it would rightly scare the hell out of anyone making a browser to even attempt it).

I see this as very much Google saying "We need a new Java, one that we control this time".

-----


Java doesn't scale to small projects and isn't "highly performant" when the metric you're trying to optimize is page load time, although it could conceivably be made to "support in-browser scripting".

Also, I think an implicit item on the list would be "doesn't suck", which is the whole point of the effort, not merely a constraint on feasible solutions like the "goals" you listed. They want something that sucks less than JavaScript, not something that sucks more, such as Java.

So I don't think "the reasons not to basically boil down to NIH, politics and the encumbrances"; they boil down to Java being a shitty non-solution to their problem.

-----


I understand that you don't seem to like Java, but it is really immaterial to my point. They stated all the goals of Java in their feature list and then didn't mention Java. If they thought Java sucked or didn't meet their requirements even though it has the same stated goals then they might have said so. But they didn't say anything at all - it's kind of an odd omission to make by accident.

-----


From the post:

  Does Dash replace Java?
  For many projects that will be a viable option but it
  requires significant engineering effort on Dash tooling 
  and an extensive set of libraries.

-----


I'd agree w.r.t. Go in a sense, but Java doesn't have much of a stake in front end web development.

-----


Where do you get that information? A large fraction of Google's frontends are written in Java.

-----


If you're referring to GWT, you're absolutely right, but thats more Google's stake than Java's.

-----


I think he / she means client side.

-----


I think they're just trying to improve the browser experience, since that's where their software runs.

-----


For a while it seemed like Google had a strategy with Go, NaCl and Pepper. But they have other "evolutionary vectors" and the reasoning is not obvious. Is it technical or political?

-----


Since they are the ones (IIRC) that started writing Java and converting it to Javascript (GWT), they wouldn't be pushing for a language without some static typing, right?

-----


Google's Closure compiler also has some kind of ability to add stati typing annotations to JavaScript.

-----


In Chrome by mid 2011, I guess it's a bit behind schedule..

-----


It might be written already, but waiting for a certain keynote before being released...

http://gotocon.com/aarhus-2011/presentation/Opening%20Keynot...

(Assuming Dart is just Dash renamed.)

-----


What they're talking about here seems a bit vague, but with all the talk of somehow being related to Harmony, this sounds more like Traceur (get a jump on that slow-moving JavaScript) than whatever Dart is going to be. But I could be totally off and maybe Dash is Dart.

-----


This sounds bad to me. I was hoping they had something real, but this is disappointing. It won't work as JS is too big (I would love to see them try), but it doesn't seem to 'fix' anything; it's just more of the same.

-----


> isolation, leaves the web in a hobbled state and unable to compete against the encroachment of other, less open platforms.

This seems more about fighting Apple Appstore than fixing Javascript issues.

-----


Interesting that they blame the rise of apps on easier to use platforms like iOs rather than the bigger issue of closed ecosystems with better hooks to devices and vendors crippling browsers.

-----


Brightly sounds almost as interesting as Dash. A web based IDE from Google!

-----


This sounds like a pretty good strategy to me. I'd like to see some syntax examples. And I hope they have a JavaScript-to-Dash converter so I can move over as much as my existing codebase as possible.

-----


The article says:

"The Dash Cross Compiler should be capable of taking typed Closure code (with some restrictions) and converting to Dash. Although the migration process won’t be fully automatic, it should make moving over to a Dash codebase somewhat easier."

I agree that a JS->Dash/Dart compiler is necessary to improve take-up of the new language.

-----


You kids and your new languages! While you endlessly debate over features and runtimes and whatnot, I still happily use PL/I under OS/360 on Hercules, and I don't think that I'm missing out on anything worthwhile. All of the below were built by real engineers, and have stood the test of time. It's an unfortunate waste of manpower that the industry keeps trying to reinvent things which remain perfectly usable. May the 60's never re-IPL!

http://en.wikipedia.org/wiki/OS/360

http://en.wikipedia.org/wiki/Hercules_(emulator)

http://en.wikipedia.org/wiki/PL/I_programming_language

-----


Thats the same thing some generals said when the wanted to replace the Cavalry with tanks and cars. There are always people like you but luckly there are always more people that want to push ahead.

If you trully belive that the last 50 years of PL/Compiler/VM research did do nothing, I pity you.

Luckly for you that these old PL/1 and Cobol-System will be almost imposible to replace since they are a monilitic blocks of messy code. I know of banks that teach the unimployed programming so that they can update there cobol code.

-----


Do you deliberately misspell words?

If you truly believe what you say, then you should tell IBM to stop providing PL/I certification (http://www-03.ibm.com/certify/certs/pl_index.shtml), and stop updating their PL/I compilers (http://www-01.ibm.com/software/awdtools/pli).

Apparently, the last 50 years of PL/Compiler/VM research did do something: It turned you into a sourpuss. I pity you.

"The geeks shall inherit the properties and methods of object Earth."

-----


Not everybody is a nativ english speaker.

Why should I tell them that, I never sad its not ok to make money of people that still use this stuff! Why should IBM not do it if there are still lots of people with old code that they can make money off? All I said is that there are languages way better then PL/I.

-----


I am also a non-native speaker. It's funny how you prefer modern software, yet you don't make use of a spellchecker, something which, to my knowledge, was not available on OS/360, but which is easily available today. Spellcheckers are the non-native speaker's best friend. I know that they may not catch certain things, like the difference between "their" and "there", but they would prevent most of your simple mistakes. You can make use of today's software to appear more professional, instead of just talking about how much better it is than the 1960's technologies that I prefer.

You should tell IBM, what I said, because their compiler upgrades and certification programs are not just for people with old code. PL/I is being used for new code, mostly by companies who are not persuaded by the shininess of the latest fads. PL/S, a proprietary dialect of PL/I, was used internally, by IBM, to create much of z/OS. XPL, another dialect of PL/I, was used to create the compiler for HAL/S, the language in which the programs that controlled the Space Shuttle were written. Incidentally, I note that HAL/S supported GOTO, which is amazing, considering that mission-critical aerospace applications could use GOTO, when written in a good language, whereas Javascript and its modern, GOTO-less brethren, regardless of speed, are not, as far as I know, worthy of such important applications.

I submit that there are no languages intrinsically "better" than PL/I, or, at least, that there isn't much else, that's been created since 1970, which is better than the latest PL/I (which is likely to be IBM's Enterprise PL/I for z/OS). Pretty much anything important, that you can code, in one of today's hip languages, I can also code, in my ancient PL/I "F" compiler, on OS/360, and those things which I can't do there, I probably could, by upgrading to MVS, under S/370, again on Hercules, where I can use the PL/I "Optimizing" compiler, but even that additional capability still puts me in the 1970's.

My original, fundamental point, which is correct, and which you cannot successfully argue against, is: Since the end of the OS/360 era, there has been a definite trend towards a tremendous waste of resources in rediscovering old programming truths, with some of the worst waste being in permanently forgetting about some very cool advances which we thus have to do without, today. A great deal of expensive, expert domain knowledge has been lost in old, abandoned codebases, and usually for no more reason than merely a glimmer of hope that some new way of doing things will be "better". One small example is Multics, an amazing operating system, written mostly in EPL, yet another dialect of PL/I.

http://en.wikipedia.org/wiki/Multics

-----




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: