Weird that a systems language and a web language are different, huh?

I said "coherent" not "identical". They could be coherent on shared features, such as type specifications or variable declarations, which have little to do with the "class" of the language. They're not.

I don't see any reason why the syntax of a systems language couldn't be the same as the syntax of a web language. They can have different libraries available to them for example but syntax doesn't have to be different.

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...

One has pointers and no security model and produces binary processor-dependent artifacts, the other has to support untrusted code, mobile code that runs on any device.

Go doesn't really have pointers in the same manner as C, though, does it?

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

Go allows you to take the address of any value. You just can't do pointer arithmetic like you can in C. That is, you can't address uninitialized memory.

I assume you mean "any lvalue"? You can't take the address of rvalues, can you?

Go doesn't define "lvalues," in the spec, but it does define "addressability." My comment would be more accurate if I had said "Go lets you take the address of any value in memory." (stack or heap)

I don't think Go lets you take stack addresses. If you try to do that, it will copy the data structure onto the heap.

The compiler is free to optimize this how it sees fit. Taking the address of a value doesn't necessarily move it to the heap.

I imagine this optimization can only happen once escape analysis is performed. In the general case, address-of moves the data to the heap, or causes it to be stored on the heap in the first place. Correct?

Yes.

If they had taken Javascript (or if you prefer a more coffee-script like syntax) and added Go's best features: interfaces-as-duck-typing, channels as fundamental types, string iteration over runes rather than bytes then they would have had a nice little language.

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.

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

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

Airplane: move people from point A to point B.

Boat: move people from point A to point B.

Voiture: transport des personnes du point A au point B

Car : move people from point A to point B

Yeah, you didn't really get the point. Again.

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.

Avion: transport des personnes du point A au point B

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.

I might not get the joke. Do you mean this ironically?

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.

I mean that (programming) language is a special kind of object that has enough versatility to express any idea in a reasonable form. Historically, our programming languages weren't that good in versatility and made various utterances an universally agreed on pain. But we are getting better and there is no law in the universe saying that we'll be forever stuck in Babel.

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.

"Historically, our programming languages weren't that good in versatility"

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).

> Well, we're not yet to the point that barrier between systems and web programming languages to be eliminated.

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.

Well, by "web programming" in the context of the original comment, I was talking mostly about web backends. If you mean that, then yeah, we'd develop those in one language, in fact we already do in some case (node.js et al).

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".

Go is a systems programming language, not a web programming language. It's like saying Javascript is incoherent with C.

Yes, science forbid they be coherent on the exact same feature such as a type specification.

Do you even read what you write?

Why should they resemble each other? They are unrelated languages produced by unrelated teams for unrelated purposes.