Overall: uninspired. Below what I was expecting. Probably good for Google goals (tooling, migrating developers, etc)

The language is somewhat interesting, but unfortunately saddened by an incredibly boring syntax. At this point, I am thinking that they would have been better off just going with the Go language for this. Looks like something good to migrate fleets of java engineers to, but not something that would inspire "hackers".

Now I feel like it is not worth to create any "brigthly" IDE whatsoever. Just go with eclipse.

I was planning to immediately rush to the language. But changed to wait and see now.

Misses:

  - Incredibly uninspired, boring Java-like syntax.
  - Not everything is an expression.
  - Java-like classes, instead of anything more interesting.
  - Lacks simplicity, symmetry and beauty.
  - Semicolons.

  In Dart, you can often create objects directly from an interface, 
  instead of having to find a class that implements that interface

  named constructors:
  var greeter = new Greeter.withPrefix('Howdy,');

  Every type in Dart is public unless its name starts 
  with an underscore ("_")

`var foo = new Bar()`?

Why can't a constructor just be a regular method that happens to return a new instance? What's with this new nonsense?

I think the overhead of adding that 'new' is worth it. Without it: in var foo = Bar(), is Bar a type or a function? If you decide it should be colored like a type, your syntax colorer needs deeper information about the code, making it harder to write, slower, etc.

    + alloc // reserves memory and creates an instance
    - init // initializes the instance
    - initWithSomething: // can have multiple inits

Why not? It makes no difference whatsoever. Make it so that the only constructor in the system is Object.new(), and so everything else that inherits behaves just like a method.

>Without it: in var foo = Bar(), is Bar a type or a function?

That's easy. Make it so that only classes and consts can be capitalized.

Blammo!

Perhaps this is by design, though? Presumably the syntax doesn't look too bad to people who spend all day writing JavaScript (i.e. the target demographic for this language).

Presumably some bright spark will eventually write a Python-to-Dart compiler and then we'll all be happy :-)

The world's experience outside of HN makes me think Dart will not be at all inhibited by its Java like syntax. If it doesn't catch on, it will be for other reasons.

Me too! We already have a very readable, simple and elegant language, let's use that. Anyone know why that wouldn't have worked? (Not using the current CPython implementation but maybe the same syntax but with a different (web-only) set of libraries, that is...)

With Source Mapping in browsers, it also means you'll be able to get a .coffee line in your tracebacks too.

  In Dart, you can often create objects directly from an interface, 
  instead of having to find a class that implements that interface

Sounds like Java's anonymous classes. Quite a useful feature, actually.

It's only useful because Java lacks first class functions and syntax for lambdas. This is the single most irritating thing about Java to me. When this is fixed with the release of 8, the only thing Java will be missing is a really good implementation of persistent data structures a la Clojure.

Where it shines IMHO is in the core library (http://www.dartlang.org/docs/api/index.html). Look there and you will find some interesting classes that deal with concurrency and asynchronous operations (Isolate, ReceivePort, Promise<T>). Also, unlike standard Javascript, there are collection classes for specific use cases (like Queue, Set, LinkedHashMap). This is where it is superior to both Javascript and mainstream static typed languages like Java.

  - Incredibly uninspired, boring Java-like syntax.

    someString.append(System.getProperty("line.separator"));

    some_string += "\n"

Trying to open and read a file in Java is probably a better example as the intent (open this file and read the contents) is buried in about 6 lines of boilerplate code

I use Java as an example because in a previous life I used to write it and see this as perfectly acceptable

Also, System.getProperty("line.separator") does not translate to n"\n".

The first makes your program more portable. Of course it could be made accesible easier, eg as a constant System.NEWLINE or something.

[UPDATE] Downvote? Really? Because someone thinks "\n" is the same as "line.separator"?

That would have been an improvement right there.

    Circle my_circle = new Circle();

    BufferedReader my_reader = new BufferedReader(new InputStreamReader(System.in));

var c = new Circle();

"Visual Studio does it for me. I can see the point if you say it's longer to read but it's also much clearer,"

So he's saying that: Circle circle = new Circle() is typed by Visual Studio for you, and clearer to read. I don't think it's clearer to read.

I think "beauty" is really a subjective consideration when it comes to programming languages.

It completely does. And I love that it manages to be completely incoherent with Go, the other "Google Language". That's so symptomatic of what google does on that front.

Server-side execution...

As was as I was aware, you can only have a pointer to an actual object.

The only thing I like is underscore for private variables. Go does the opposite (which I think is a safer approach): anything you want public has to start with a capital. It really works—it is both easy to do and easy to read.

Web language: move data from point A to point B.

Boat: move people from point A to point B.

Car : move people from point A to point B

Systems language and web language are not just a different name for the same thing --like Voiture and Car.

And, no, that their function defined in abstract and in totally generic terms is the same, doesn't make them the same thing.

"move data from point A to point B" can be said for any programming language. As such, it's not particularly enlightening when comparing a language's suitability to a specific task.

Turing-completeness aside, your argument misses the point that a particular language's design, compiler, library, toolset, (heck, even a particular language's community) can make it better suited for system programming or for web programming or for some other field.

Boot: Menschen bewegen von Punkt A nach Punkt B

We are talking past each other :) Here is your first comment interpreted through your second one. There is no reason to have different languages, but it's OK to have different jargon.

There sure is reason to have different programming languages, and it's called specialization (see: necessary engineering compromises).

My first comment says: two objects having the same generic functionality, does not mean that one and the same object can implement their specific (non generic) functionalities.

My second comment says: the same thing, basically.

To some extent, your point is that Shakespeare is better in English than in its German translation for style reasons. My point is that it doesn't really matter and that an universal language is better than Babel because of network effects. Life is too short to erect artificial communication barriers.

Well, we're not yet to the point that barrier between systems and web programming languages to be eliminated. You seem to imply that the problem is the inflexibility of the languages, but to me it's not a problem, it's a feature: I want different abstractions to work in different problem domains (e.g. systems vs web). So it's not that the languages are not flexible enough, but rather that we, as language designers and users, have MORE flexibility, to use a different tool for a different job.

Also: yes, Shakespeare is better in English than in its German translation. And it's not just the language, it's also the cultural universe that Shakespeare presupposes. For business use, maybe, but for culture I don't like universal languages, network effects be damned. Life is too short to reduce world languages and communication to a lowest common denominator [and that is inevitable, because any wannabe universal language will lack the historical and cultural ties and shared substructure of any particular population).

We are one or two iterations away. Look at this thread. A lot of people were expecting something looking closer to Go. Go itself is an example: statically typed, garbage collected "systems" language. If you ignore the differences in the type system and the slice syntactic sugar, that sounds conspicuously close to Java. And Dart itself sounds closer to Java than Javascript as well. Not that I believe we'll converge on Java, given the glacial pace of evolution in that community.

But the edges of the state-of-the-art are getting closer in this generation. Next generation (5-10 years from now) will be even closer, if not identical.

On a technical note: what exactly do you have in mind when making a distinction between "web" and "systems"? Backends qualify as "systems" in my book and I'd be a fool if I'd want to develop in two distinct languages when there is just one app. Thanks to GWT and now Dart, I don't have to.

But I don't qualify that as "systems programming", to quote Wikipedia:

"System programming (or systems programming) is the activity of programming system software".

and:

"System software is computer software designed to operate the computer hardware and to provide a platform for running application software".

Do you even read what you write?

Not only did they create V8, they write many boat loads of JavaScript so they are well placed to address both the technical and human pain points of scaling JavaScript. And in introducing a new language they can't stray too far from the mainstream if they wish large adoption. All that said, I am not moved.

Also, F# is Don Syme's work not Erik Meijer's. Although F# probably gained from some Haskell people in Cambridge (the original one).

I would expect PL theory to deliver great benefits at about the same rate as for other fields, e.g. that pure mathematics does for physics - some of it does; though it's common for it to be reinvented independently by people trying to solve specific problems.

BTW: Notwithstanding the over-general flame-bait title, I think his "types are anti-modular" is really just making the point that, while interfaces reduce your dependence on implementation, now you depend on interfaces. i.e. The problem with using types to hide decisions that you think will change is if your prediction about what will change is wrong. "On the Criteria to Be Used in Decomposing Systems Into Modules" http://www.cs.umd.edu/class/spring2003/cmsc838p/Design/crite...

Perhaps one solution is to specify all the types you use in a module, internally; and provide a mechanism for converting between equivalent types at the boundary, to remove the dependency while facilitating interoperation. This mechanism acts as a buffer or glue (or middleware) - a kind of interface between interfaces if you will.

† Although the technology adoption lifecycle gives the impression that a new technology with interesting properties is just the beginning of great things, the vast majority of new things do not become massively successful - it's just that the lifecycle is based on those that were. http://en.wikipedia.org/wiki/Technology_adoption_lifecycle

The issue is whether the interfacing technique adds in non-essential coupling. A technique that has at least the constraints of another technique will also have trivially have at least the non-essential coupling of the other technique.

Types add constraints, thus increasing coupling (and decreasing modularity).

Although types have benefits. And direct modularity is seldom the only concern. I.e. Correctness and reliability also enhances modularity in an indirect way - an erroneous module definitely decreases modularity.

I'm not sure exactly what you mean. Could you elaborate please?

I'll clarify my view with an analogous example: you can think of a database as having a set of types - its schema. Think of each of the applications that use that database as also having its own set of types - its classes or data structures in general. Now, an example of the "mechanism" I mean is that SQL provides a way for each app to translate data in the database's schema into its own data structures. If its data structures change, the SQL can change to adapt to that; similarly, if the DB's schema changes, it can also adapt by changing SQL (or even creating a virtual schema with another layer of SQL - a view). Of course, this only works if these are only changes of the representation of the information, and the information content itself is the same. If the information changes, in a way that the DB or an app depends on, then there's no avoiding that dependency.

A similar example are JSON/XML API's, where the JSON/XML is like the DB, and the data binding code is like SQL. The "type" of XML is often explicitly defined with an "XML Schema" document; JSON doesn't usually have that, but it is of an implicit expected form - which is still a type, just informally defined. There are also tools for converting between XML types - XSLT, and may GUI "XML mappers" that display two xml schema and let you draw lines between them.

tl;dr These enable "modules" with different types to interoperate without dependency. Each defines its own types at its own boundary, and so can be compiled independently. The middleware glue (SQL/databinder/XSLT/datamapper) facilitates interoperation by converting between types at the respective boundaries of two modules - provided those types are equivalent, i.e. contain the same information, just in a different schema/type.

Does your concept of "non-essential coupling" include the requirement of precisely identical types at the boundary? If so, by loosening that to only require the same information, this mechanism avoids that particular kind of non-essential coupling.

More trivially, adding types IS adding constraints that are verifiable at compile time.

If compile-time verification of that sort is not essential (or not desired, which is the more general form of not essential), then the constraints are non-essential (or not desired).

---

Whether you choose to

1. Choose a particular data-structure and implement both modules to pass and receive that data-structure.

2. Specify an interface: The interface requires the data-structure to have certain properties (e.g. some methods work on them). The modules then build to the interface.

3. Specify that an adaptor exist to convert the data-structure to whatever the module requires.

is a somewhat different issue, although the kind of type system used does affect the implementation complexity and effort required.

In summary when I saw the language this morning my first thought was: "Nothing to see here". But as a result my second was: "Get back to work". Maybe that's not so bad.

Other than that: it's got coffeescript's fast initializer syntax, but it's not as concise. It's got types but AFAICT no type inference. No destructuring either.

Only thing I can see it's really got going for it is some basic types which could have been provided as a standard Javascript library (and probably will become one...)

Not yet.

> No destructuring either.

There's a proposal floating around for pattern-matching that would address that too.

This is still early days for the language, so there's a lot left to be done.

I agree with you, the first impact with the language is terrible, the syntax is too reminiscent of Java. It seems that at Google Java is popular for web apps (GWT, Closure, ...). This must have had an influence.

I still fail to see what are the improvements over Javascript (while they managed to get the syntax worse). I guess a concurrency model, optional static typing, interfaces. Did I miss anything?

> Types can help you write and maintain your code, but they don't change how Dart programs behave.

That, in my opinion, is not a type system, it's a documentation system. Writing

  String a = 1;

    void doSomething(String a) {
        // Do something 1
    }

    void doSomething(Integer a) {
        // Do something 2
    }

    doSomething("1");
    doSomething(1);

The fact that type errors are only manifested as warnings is a (perhaps odd) design decision, but it doesn't stop them being type errors. They could just as easily made them errors, and String a = 1 would give a compile time error.

Hopefully they'll be a 'warnings as errors' flag for those of us more used to type errors being compile errors.

Uh... like this? http://brendaneich.com/brendaneich_content/uploads/CapitolJS...

C# had a hard constraint to start with - it was supposed to be an easy replacement for Java, it actually started from Microsoft's own Java implementation and it had to ship as fast as possible.

Even so, the language evolved nicely as they left room for improvement in a forward-thinking manner.

Also, C# 1.1 did have 5 things which I terribly miss from Java - delegates, P/Invoke, stack-allocated types without "special" exceptions, object properties and the GAC. From a theory-standpoint, none of them are groundbreaking, but we are talking about a language that's supposed to be grounded in real-world constraints.

I wouldn't be surprised if "performance" of the language meant "able to get our vast fleets of mediocre Java developers to write web apps faster" rather than "able to execute faster".

Yes, because Google is notorious for hiring "mediocre developers".

Or are Java developers especially considered "mediocre" by definition?

Or does dabbling in Ruby/Python/Lisp/Closure/Scala/Haskell make you "non mediocre" by definition?

It's the skills, it's not the language.

I would like to see something with the scope, ecosystem and functionality of, say, Eclipse, written in one of the non-mediocre languages (no, Emacs doesn't come close).

I agree that there are some amazing Java devs out there.

Most Java devs are not amazing (and heck most devs aren't amazing). But Java devs are not amazing with a frequency and depth that both boggles the mind and is entirely expected as that's the point of the language -- accommodate mediocre developers in a large shop producing boring enterprise code.

If you look where it's publicly known that Google uses Java, it's pretty much in Ads. The most boring, enterprisy kind of dev job Google has, but it's the money maker so it has to work despite having unmotivated "I'm just here for the paycheck" developers hacking on it.

Yeah, I know, it was used on the backend of Wave, and via GWT for the Wave web client (which was dog slow btw, I loved Wave, but have yet to encounter a web app as slow). And look where that got us.

As an aside, here's an interesting little writeup about why GWT is bad (with bonus example by pg of all people)

http://ryandoherty.net/2007/04/29/why-google-web-toolkit-rot...

And, at least publicly that's about it. If a dev can't be bothered to just learn the syntax of another language in a couple of weeks in order to properly support their target platform, they are a mediocre developer almost by definition.

All brilliant people, but you have to remember that not everyone thinks types are all that matters. I like type systems, but the majority of the world's shipped code was written in languages with unsound type systems.

    var q = from m in grains.OfType<Salt>()
            where m.Value.Contains(null)
            orderby m.irrelevance
            select m;

    return q.FirstOrDefault();

If you approach it as what it is, yes, a language-integrated query syntax, and avoid the fluent-chaining style most of the time, then you'll see an information-dense productivity booster instead of a "total mess".

The LINQ syntax fits on 1 sheet of paper:

    http://www.albahari.com/nutshell/linqsyntax.aspx

Now, as far as python and other languages are concerned, LINQ is less "python in C#" and more "PEP 202 in C#".

The from item in blah syntax is just SQL rearranged, and SQL isn't as expressive as programming language constructs, so why try to emulate it?

It encourages you to write the grain of salt statement I mentioned earlier, which requires programmers to read through and understand the implementation of what you are doing, instead of it being embodied in a meaningful method and called. Of course you could just wrap that in a method, and slowly grow the line to 2-3 wide-screen monitors as you add more conditions.

The more tools you add to the core of a language, the more of a monstrosity of a kitchen sink it becomes (c#/.NET). Now you can loop over a list in 6 different ways! Hooray! That is why Dart looks good - a few basic concepts that can be used to build things suited to a particular problem.

    grain.OfType<Salt>()
          .Where(m => m.Value.Contains(nothing))
          .OrderBy(m => m.irrelevance)
          .FirstOrDefault();

    grains.select{|g|
      g.is_a?(Salt) && g.value.blank?
    }.sort{|a,b|
      a.irrelevance <=> b.irrelevance
    }.first

    grains.select{|g|
      g.is_a?(Salt) && g.value.nil?
    }.sort_by(&:irrelevance).first

    sort_by{|g|g.irrelevance}

  $ ruby -e 'puts VERSION; p ["10", "2", "3"].sort_by(&:to_i)'
  1.8.7
  ["2", "3", "10"]

EDIT: said duck typing first. It's too early for thinking.

foreach (var g in grains) {

    if (g.TypeOf() == "Salt" && g.Value == nothing)

        saltGrains.Add(g);

saltGrains.sort(m => m.Value.irellevance);

return saltGrains.First();

or something.

A delightfully blank page :-) Yes it mentions classes, interfaces, optional types, libraries, tools, structured yet flexible language. But all of these are a given. Is there nothing else?

What about Generics, Covariance/Contravariance ? Type inference? Odersky thinks type inference in the presence of subtyping is untenable. Is it the same here? Are interfaces linearized as in Scala? What about immutability? It might be too much to ask for rank-2 polymorphism and Haskellish Type Classes but what about support for delimited continuations? Let me guess, these aren't "design goals". All I am saying is this isn't 1990 either.

For example: " Dart supports optional typing based on interface types. The type system is unsound, due to the covariance of generic types. This is a deliberate choice (and undoubtedly controversial). Experience has shown that sound type rules for generics fly in the face of programmer intuition. It is easy for tools to provide a sound type analysis if they choose, which may be useful for tasks like refactoring."

What Dart brings to the table is a dynamic web language that's somewhat more structured than Javascript by using a class mechanism and optional typing. This is a great region of the design space, inhabited by languages like Common Lisp and Dylan.

In CoffeeScript compilation is entirely local and highly modular.

You can get away from this by having a structural type system, or by being dynamically typed (duck typing ultimately being another form of structural typing). But within the constraints of the type system, you can't get away from this by merely changing the design - unless you put everything into a single module, which is the ultimate in anti-modularity.

Wow. And I thought nobody in their right minds would question Hejlsberg's chops or the work he did for .Net.

He is "not a PL theory expert"? Great. We need less of them in mainstream language design and more pragmatism.

Why not? C# 1.0 was terrible and most of the version since have been exercises in trying to fix it by piling more stuff on, in order to replace previous tentative fixes which did not work for any value of "work" worth using because they lacked generality.

> We need less of them in mainstream language design and more pragmatism.

I hope that's a joke, PL theory experts are nowhere to be seen in mainstream language designs (some have managed to get a claw or two into C# to add actually useful features like... lambdas...), and the "pragmatists" have a field days reinventing problems (not solutions) instead (hello, Go)

What language do you think was perfect at it's first release?

No, C# 1.0 was terrible for the reasons of being a slightly improved Java, without some of the baggage (before it created its own, because you can't be a good java descendent without building a pile of legacy garbage) and nothing more.

Fucking hell, I loathe this bullshit about "pratical", it's the most meaningless term since "strongly typed". You know what else is practical? Computed gotos, FORTRAN IV, Superzap, front-panel switches, punch-cards, tape decks and magnetic-core memory.

Releasing C# without generics and half-deprecating all of the collection hierarchy (but leaving it in an undead state by not actually migrating users of old collections) a version and 2 years later was not "practical", it was a lack of foresight. Not having iterables was not "practical" it was "a pain", taking 2 releases to get properties (in the first place, and not so verbose you wanted to stab your eyes out) was not "practical" it was "whelp let's get this shit out now, who cares", having nullable references still isn't practical to this day.

> What language do you think was perfect at it's first release?

None, I've yet to see a perfect language at all. But there's a gap between a terrible language and a good language, or even an interesting language. C# 1.0 was nowhere near a good language. It wasn't even interesting.

And it's not like this shit's new, most of it is multiple decades old at this point (the only language aiming at mainstream I've seen do anything even remotely novel as of late is Rust and its typestates). We're talking about making mistakes which have been solved for 20 years.

Algol 60.