Dart Is Not the Language You Think It Is
programming.oreilly.com
programming.oreilly.com
For that audience, they are given a language with optional static typing (most don't want it) and an Eclipse-based editor (most don't want it).
By way of contrast, consider Go. Go is (in my opinion) an extremely successful successor to C, in terms of its design. It fixes a handful of problems with C (strings, and I would argue pointer arithmetic), and modernizes and streamlines it. The interface system is fantastic. In terms of its design, I have nothing but good things to say about Go.
Dart does not seem to improve on JavaScript in a compelling way. It adds optional static typing, and as far as I can tell, nothing else.
Is it any surprise that Dart has failed to take off?
Dart is an ambitious attempt at simplyfing web development, reducing complexity and improving productivity which:
- Provides a familiar language with clean semantics and low ceremony
- Provides the fastest dev iteration times (there's no compile step,
just edit + run in Dart VM/Dartium)
- Provides ~10x faster start-up times with snapshots (Dart VM)
- Provides faster run-time performance, that's predictable and can take
advantage of real integers and SIMD instructions (VM Only)
- Provides a unified object model so all classes from all libraries can interoperate
- Providing a rich, well-defined, consistent API, real collections, removing JS WATs,
smoothing over browser quirks
- Provides a unified and composable IO model: Futures and Streams (repeating events)
- Provides a new powerful way to develop client apps with Web UI (Dart WebComponents)
offering unprecedented levels of encapsulation and reusability
- Provides optimal dev and deployment options, you never have to worry about choosing
the smallest libs as tree-shaking ensures only code used is compiled and minified
- Providing "full-stack" dev environment, e.g. same language on client and server
It's very disappointing that the first serious attempt to replace JS after almost 20 years is merely just another Java-syntax-like JIT-compiled single-threaded dynamically-typed garbage-collected language with global, shared mutable state. It's fundamentally the same language merely with some pet peeves removed and a bit of sugar on top. It's a waste of opportunity.
Every other attempt adds more layers and complexity and additional build times to web development, only Dart brings a clean re-write.
You don't need to write Dart in the Dart Editor if you don't want the IDE experience. I happily write Dart in Sublime, and Dart has command-line tools that I can use to validate the code that I write.
But web developers, who are the primary producers of JavaScript, will happily stick with Node.js, CoffeeScript, or plain JavaScript.
If web developers are happy with the tools they have, then that's just fine. The Dart team isn't trying to replace JavaScript, but instead provide another option for web development. What I think the Dart team is finding is that there are a lot of people that are having trouble with putting together all the pieces just to build a web app. This is especially true if you are new to the web platform, and you're familiar with the development from other places. Dart provides a very consistent platform that you can build web applications with, and you don't need to worry about jumping through all the hoops that normal web development requires.
By way of contrast, consider Go. Go is (in my opinion) an extremely successful successor to C, in terms of its design. It fixes a handful of problems with C (strings, and I would argue pointer arithmetic), and modernizes and streamlines it. The interface system is fantastic. In terms of its design, I have nothing but good things to say about Go.
In a way, this is how I see Dart too (though Dart is a much newer platform, not yet out of beta). Dart aims to fix a handful of problems with JavaScript (like better scoping semantics, a built-in module system, better toolability and static analysis tools, etc.), and then also takes the existing browser APIs and modernizes and streamlines them (for example, all of the core browser APIs use a consistent Future-based API for asynchronous values, which cleans up a lot of messy code that you'd ordinarily see in JavaScript web application code).
Is it any surprise that Dart has failed to take off?
It's not at 1.0 yet. I still think there is plenty of room for improvement, and plenty of time for adoption.
There's definitely room for both polish and adoption.
This is the same line argument made with regards to Java too.
But the fact of the matter is, these language bring in so complexity with their whole ecosystem. Working without an IDE isn't even worth that torture.
How do you use your JavaScript libraries today? Do you have evrything memorized?
I've written Java in plaintext editors before, and that is truly terrible. Dart is nowhere near that verbose. Dart's imports feel pretty lightweight (rather Python-esque) and the fact that the language has top-level functions and variables means that you're not always trying to juggle a bunch of classes and objects and interfaces when you don't need to. In fact, Dart's style guide explicitly recommends that you don't put things in wrapper objects just because you can. http://www.dartlang.org/articles/style-guide/
I really don't think that Dart brings in any more complexity than you'd have in a JavaScript application. I actually think it's a lot easier to hold a Dart application in your head because all the APIs have a consistent interface. With JavaScript, you often have a bunch of different libraries and you have to remember how each of them behaves.
All of this is courtesy of the Closure Compiler, which uses optional static typing.
Sometimes people chose to use a language for a new project because of existing labor pool, that is, who they can find to work on the project and what their preferences are. Sometimes it's because they want to use an existing codebase. Sometimes, people chose a new language because they are in an experimental mood and want to try something new.
If Larry Page were to say "all future apps have to be written in Dart", it would be damaging to company morale and culture, not because there's something wrong with Dart, but because people chafe being forced to make technical or personal decisions like that.
Google can no more force you to use Dart than they can force you to use CoffeeScript or GWT, I think people need to chill out and stop aggressing against anything that threatens Javascript hegemony. I mean, sheesh, people are even rebelling against some of the changes in ES6 which fix some of the most egregious problems that drive people to create transpiled languages.
Also, I meant it will be interesting if no team chooses to use Dart on the client, but it gains interest on the server. Presumably teams go with what makes sense and that will be interesting to watch.
> I think people need to chill out and stop aggressing against anything that threatens Javascript hegemony
They have over the last 6 months as more and more people are realizing that pure JavaScript is not entirely suitable for large scale applications that are becoming more common. As someone said, the efforts to make it so are 'heroic,' but obviously the hard way to do things, like choosing to write a large application in assembly language. Having done that once, I would never do it again, and would take someone who said this was best less seriously.
With Google production servers, there's only a few "approved" languages. I can't just go deploy a Rails app in one of Google's datacenters, for good reason, especially when you consider security.
With app-engine or compute-engine there's slightly more freedom.
AS3, C#, Java, and JavaScript developers. That's why they went with C-like syntax. It's familiar to most people.
>But web developers, who are the primary producers of JavaScript, will happily stick with Node.js, CoffeeScript, or plain JavaScript.
I'm writing JavaScript for a few years now. I'm really tired of it. It scales very poorly and there is zero tooling. For example, JSLint is mostly about formatting and conventions, because it got very little information to work with.
Also, if you want to take care of dependencies in JavaScript, you'll need boilerplate code (several flavors exist). If you want to document your code, you'll need lengthy doc comments (several flavors exist).
Finally, with JavaScript you're always discouraged to write extensive libraries, because everything you don't use is dead weight.
With Dart, you don't have any of those problems. It scales, there is proper tooling, you can use `import` and put stuff into packages, basic documentation is already done by adding some type annotations, and unused code is also removed.
Additionally, it's a lot easier to learn than JavaScript, because the language is less quirky.
>Dart does not seem to improve on JavaScript in a compelling way. It adds optional static typing, and as far as I can tell, nothing else.
Classes/inheritance, mixins, implicit getters/setters, implicit interfaces, import, lambda expressions, proper lexical scoping, a lexically scoped `this`, operator overloading, actor-like concurrency (isolates), SIMD, faster startup, better performance, const/final, factory constructors, optional positioned/named arguments... and good tooling.
Seen that "WAT" talk? None of that.
Dart is drastically better than JavaScript.
var count = 0;
for (var i = 0; i < arr.length; i++) {
if (some_func(i)) {
count++;
}
}
I love static analysis, I like tools that automatically format source code (indent, go fmt, emacs), but JSLint is just annoying.
Even when one understands the reasoning behind why a tool like JSLint suggests what it does, this doesn't change the fact that dietrichepp's observations are correct. JavaScript's scoping and variable hoisting are unnecessarily broken, leading to convoluted coding practices that wouldn't really be necessary if JavaScript itself wasn't so broken.
You can't really fix things. It would break the web. You can only add stuff on top.
>JavaScript's scoping and variable hoisting are unnecessarily broken [...]
It will get a bit better with ES6's `let` keyword. Annoyingly, that keyword was introduced with Firefox 2.0 (October 24, 2006) but you still can't use it.
Even Node.js needs a switch.
var foo = "The id number is: " + ++this.id + ".";
a Minifier may make that like
var foo="The id number is: "+++this.id+".";
which is a syntax error. Now of course you should be using a minifier that wouldn't be so stupid but it happened in our staging environment because some former employee used a very basic, yet aggressive minifier in the build process from Staging to Live.
JSLint gives you an option to turn it off though, plusplus:false. Same with the variable hoisting warning others have explained.
You realize Dart literally has broken generics? That the team thought covariant mutable collections was a good thing?
I remember that Dijkstra had some pretty good article about it.
Anyhow, JavaScript doesn't have any kind of generics or types. Do you really prefer that?
I know there is a stream of Java / C# / C++ programmers that desire a Java-esque, improved GWT experience and loathe Javascript. But I see Dart more as a refined/upgraded Javascript -- some additional language/toolset features like Objective-C or C++ do for C.
Advantages of Dart over Node.js or CoffeeScript or plain Javascript?
1. "Batteries included" -- instead of reliance upon assortment of modules, OO system built in, better DOM utilities than jQuery (query returns a first class object), functional like Javascript sans the function keyword).
2. So nice that you can split a project across a whole bunch of code files, yet it will condense and minify into one efficient javascript file. Yes, there are tools with all the various Javascript frameworks to accomplish this, but then you're reliant upon of hierarchical library dependencies that sometimes can be brittle.
3. Can run server side just as Node.js with a powerful VM, without the need (though certainly possible and optional) to install a plethora of other libraries.
I think it hasn't taken off because up until recent months, the language and library has not been stable enough for production development -- libraries have changed a lot and most of the code in all of the Dart books published to date will not run at all now (though the Dart SDK comes with a tool that can help migrating code).
There are still some sore spots I hope get addressed -- primarily, on server side, need for built-in DB libraries and on client side, JSONP/CORS that is as easy as jQuery makes it. At least in my XP.
The thing isn't static typing- it's static analysis. The ability to specify contracts in your code and have something validate your code. This is the same thing TypeScript and Closure try to address, but Dart is trying to tackle the issue at its core, with performance to boot.
There's also a plugin for Intellij IDEA[1], which is a great web (and other use) IDE.
Dart will never take off if the other vendors don't offer VM support on their browsers. Almost every language has JavaScript transpilers and as a Chrome only solution it won't work.
Both are compelling advantages of Dart.
Well, I am the opinion the browser is for documents.
I tried DART and did multiplayer online game http://shipsonline.org/ as my first "hello world" without any external code. Epic win for myself. It has more than static typing, please try write simple app and you will see. Eventualy it became stable and then became mainstream popular i hope.
"It adds optional static typing, and as far as I can tell, nothing else."
And as far as I can tell you don't have a clue of what you're talking about.
I received a lot of thoughtful, intelligent responses to my post, including many that disagreed. Unfortunately, yours was not one of them.
"Dart is a source code VM
The Dart VM reads and executes source code, which means there is no compile step between edit and run. As with other popular scripting languages, it’s very quick to iterate with Dart. The Dart VM runs on the command line and servers, and can be embedded into browsers. Just point the VM at Dart source code and you’re up and running!"
By that definition Dartmouth BASIC is a "source code VM" aka an interpreter. Why call it something it isn't?
I think Dart is interesting in its own way, and generally a useful exercise for thinking about how you might write an interpreted language that can run in untrusted contexts, but beyond that I don't "get" the problem it is trying to solve.
They want a replacement language that's more optimization-friendly so that they can continue pushing for faster Web clients.
Given this creator goal, and most programmers' goals of "use a language that better suits my needs," it's not terribly surprising that Dart hasn't seen the kind of community interest that CoffeeScript has.
That's why it has libraries, type annotations, a declarative top-level structure, and some of the reason for closed objects. Good tools for Dart are _much_ easier to write than tools for a very dynamic language.
When developing and running in the DartVM, Dart code can run natively inside the Dartium browser without needing to compile to JS first. Also Dart is declaratively structured and optimized for fast start-up times (e.g. opts for lazy loading) which means they can start JIT'ing and executing from the main(){} entry point (which is also the point where snapshots are saved at).
The DartVM uses a method JIT which compiles the source code directly to machine code. An interpreter has a main loop which runs instructions one at a time.
Wikipedia is a good place to start if you'd like to understand the difference.
http://en.wikipedia.org/wiki/Just-in-time_compilation http://en.wikipedia.org/wiki/Interpreter_(computing)
The definition of an interpreter is generally broader than a main loop running instructions one at a time. For example, everyone seem to agree that Python is an interpreted language while python interpreter transforms the source code into an IR before passing that to its main loop. Truth is the line between what is a VM, an interpreter and a compiler is rather fuzzy.
The implementation of a process virtual machine clearly is an interpreter of a bitcode. Now, it's not entirely absurde to consider the couple JIT and VM taken together as an interpreter. Actually, this is clearly encompassed by the third point of the definition of an interpreter provided by Wikipedia : "explicitly execute stored precompiled code[1] made by a compiler which is part of the interpreter system".
To come back to the article discussion, I agree with the previous poster than the expression "source code VM" is kind of meaningless. Actually, the paragraph following is even plain wrong. The Dart VM executes bitcode not source file and Dart is JITed.
In the same way, I find it quite surprising that forty years after Hindley paper, people still confuse type annotated and statically typed but well, c'est la vie.
I agree that there are many shades of the rainbow between a JIT and an interpreter.
"V8 compiles JavaScript source code directly into machine code when it is first executed. There are no intermediate byte codes, no interpreter." https://developers.google.com/v8/design#mach_code
Have a read about V8 and the DartVM's architecture. V8, and the DartVM have a different architecture than IE's Chakra and Firefox's monkeys. They use a method JIT which initially generates very simple native machine code directly from the AST. The machine code includes instructions to identify hot code, which is re-compiled again from the AST. The optimizing compiler converts the source into an SSA form, and IR, but this is not byte/bitcode. This is what Bak et al are referring to when they call this architecture a "source code vm".
Lars Bak on channel 9: Bytecodes are a silly thing in my mind. They can be used for different things interpretation. But interpreters are really slow. But they can also be used as a wire format, for instance in .net or java where that's what you ship over the wire. In javascript the wire format is sourcecode, and for each function you have, inside the running javascript program, you have to cook up the source code again. So that is the primary representation. So we just decided why not generate native code right away because the CPU is pretty fast.
http://media.ch9.ms/ch9/e6aa/354bf580-9c93-4383-bab3-cb6a3dd...
Optionally typed is extremely strange.
Here's optional type annotations in Haskell, which uses type inference by default but lets you override types with annotations. Note that f and g have different types, but the same body.
-- Haskell
f = return 5
g :: IO Int
g = return 5
; Dynamic +3 function
(defun add3 (x) (+ x 3))
; Static +3 function for integers
(defun add3 (x)
(declare (type integer x))
(+ x 3))In Dart, the types appear to be little more than advisory documentation.
I don't know Lisp; what happens to your add3 if you pass a thing that can't be added to 3? Does it crash at some sort of 'type checking phase' (whenever that may be) or only when it finally discovers it can't do the addition, essentially ignoring the type declaration? (Or both and neither, depending on what exact Lisp and macro set you're using, which is my guess.)
I may be wrong, but I suspect you don't know how Haskell type inference works. (1) This is just semantics, but the compiler is not "smart" and does not "figure out" types. It uses a straightforward type unification algorithm (should feel natural to anyone who's programmed in Prolog) with a monomorphism restriction. (2) The type annotations you add may be different than the types that the compiler would deduce in their absence, and these annotations may in fact be necessary in order for the program to be correct.
Your question about Lisp has already been answered, but I will expand. The type checking can be done at runtime, at compile time, or at some combination of both—it is not always possible to deduce the type of function arguments at compile time in a language like Lisp. Obviously, (+ 1 "ABC") is an error, but not all situations are so obvious. The same is true in Python, Ruby, JavaScript, Objective C, Java, Haskell, and any other language which supports dynamic typing.
Yes, Haskell supports dynamic typing.
Yes, it is. That entire paragraph was... less than useful.
"Yes, Haskell supports dynamic typing."
Yes, it does, but not with any of the features you've discussed. It supports it with Data.Dynamic. Type holes are still as I described; they are not a way to escape the type system or make it compile something that does not have some sort of concrete type, they are a way of asking the compiler what type it thinks goes somewhere. Here, the first hit for "ghc type holes": http://www.haskell.org/haskellwiki/GHC/TypeHoles
"This is the purpose of a hole: it has similar semantics to undefined, in that evaluating it is an error (you can replace all holes with undefined, and vice versa, and nothing has changed: you may even say undefined is just a really crappy, useless hole!) But it's special in that when GHC encounters a hole during compilation it will tell you what type needs to be there in place of the hole, for the type-checker to be OK with the definition."
This is not dynamic typing. It may superficially look like it if you just gloss over the definition, but if you really understand it that's not what it is. There is still some sort of concrete answer (concrete to the type system, for which constraints aren't that big a deal).
I return fire: I suspect you don't understand how Haskell type inference works, since you're making false claims about these features.
When I write a Haskell program, I start with the types and the code grows from there. The types are really the foundation for everything else. It doesn't really make sense to view the code without also thinking about types: after all, Haskell code is centered around functions, and functions are defined by their domain and codomain.
Among other things, this means that the types actually help me to prototype. Iterating on different types and seeing how that changes the sort of functions I can write is a very powerful technique. This is going to become even more apparent in the near future with features like type holes. The basic idea there is that you can leave parts of your code blank, and the compiler will tell you which type goes there! The type system can actually help you write the code.
Honestly, I think the difference between types in Java and Haskell is at least as large as the difference between types in Java and dynamically typed languages.
Basically, in Haskell, the types go well beyond correctness. I hope this clarifies what I mean.
It's far more readable and concise having it embedded in the language rather than buried and disjointed in the comments. Not to mention it also allows for superior tooling support.
I've personally been extremely productive with Dart (most productive I've ever been with any language). It's effectively a more consistent JavaScript with less ceremony with the benefit of optional typing which has caught errors on a number of occasions, giving instant feedback and identifying errors before I've even run the code.
Although Dart on the server is still in its early stages so you might not find all the libraries you need, e.g. I ended up writing my own Redis Client (https://github.com/dartist/redis_client) since there were fewer mature options. All the server APIs are there for you to build a node-like server, it's just the web frameworks and view engines are currently lacking so you might find yourself having to write more frameworks/libraries than you would otherwise on node (which is a lot more mature atm).
I'm hoping after the Dart team finish the work on integrating the Dart VM into Chrome that they'll focus on the server-side of the "full stack" and provide support for App Engine, incidentally star this issue if you would like to see support for this sooner: https://code.google.com/p/googleappengine/issues/detail?id=6...
Assembly language is untyped. Dynamic typing is not the same thing.
Unfortunately the term "type" is also used to refer to the tags dynamic languages put on data to prevent illegal operations. Confusion inevitably results.
It's like the kind of JSDoc annotations you need for the Closure Compiler.
The difference is that it's baked into the language, which enables a very terse syntax and, since it's standardized, it can be used by all of your tools.
You only need those annotations at the API boundaries (arguments and return values) to get most of the tooling benefits like call-tips, auto-complete, direct & inferred static checks, runtime checks, generated documentation, and things like that.
So even if you type-annotate everything, you will never get compile-type type errors? That makes the whole thing seem completely pointless.
Seems pretty odd to me.
Groovy 2.x, with compile-time typing, only came out a year ago.
And the most important part; it looks boring. the articles about it look also are very boring.
Dart has a js-interop library for the times that you want to reuse some code written in JavaScript. This video gives a good introduction to it: http://www.youtube.com/watch?v=QFuCFUd2Zsw
And the most important part; it looks boring.
That's was a big design goal when they created the language. It's designed so that, for the most part, it looks and behaves like other languages that you're used to. You can pick it up in an hour or so and be productive right away. The Dart team didn't want to create some esoteric language with all sorts of crazy features, they set out to create a real language that people would feel comfortable using.
It is too bad that it doesn't run on many browsers but that isn't going to change.
What is the point of using Dart other than to join Google's garden of ugly walls?
Dart brings improvements to the language and tools that are worthwhile regardless of the VM being available in the user's client. dart2js is the primary method of deploying Dart code, and there's nothing bad about that.
If they can design a new language that's worth switching to and embed the VM in their browser, the other vendors will be more likely to implement it than when it was the little-browser-that-could. It's not a slam dunk (part of the reason Blink splintered off from WebKit was the pain of supporting two VMs), but the weather is changing quickly for Dart's chances to be a first-class language.
Throw in the extra performance (2x?) over Javascript and I'm ready to at least give it a try.
The Dart VM is 2X faster than V8 on a few benchmarks already. Check out https://www.dartlang.org/performance We've still got a bunch of work to do, but the initial results are encouraging.
As of May 2013, Microsoft Internet Explorer, Mozilla Firefox, Opera Software's Opera browser, and Apple Safari have no plan to embed a separate Dart VM [1].
What would it take to get these vendors to add support?
1: http://en.wikipedia.org/wiki/Dart_%28programming_language%29...
Generating minified Dart code is one line and compiling to minified JS is also just one line. If you do one in your build script, you can also do the other. It's a no-brainer, really.
Because Dart compiles to JavaScript (which can even perform better than handwritten JavaScript to perform the same actions[1]), it runs everywhere. You don't need the Dart VM built into a browser for your Dart application to work; it already works today.
What would it take to get these vendors to add support?
I think that likely they would want to see more applications written in Dart. If a big company (like Facebook, for example) wrote a large application in Dart, other browser vendors would see both that big name developers are using Dart for their applications and they'd see the performance boost that browsers with the Dart VM built in take advantage of[2]. This would make it more compelling for them to include a Dart VM in their browser.
[1]: http://news.dartlang.org/2013/03/why-dart2js-produces-faster...
It's really too bad there isn't an equivalent of play.golang.org for Dart. I would've given it a try right now if the barrier of entry were lower, and perhaps I'd be pleasantly surprised enough to keep using it.
Also, is it possible to generate and execute Dart code within Dart (the way it is in dynamic languages like JS) without recompiling?
There is.
Anyhow, the barrier is actually pretty low. The editor zip is about 140MB in size and contains everything you need: the SDK, the editor, and Dartium (Chromium + Dart VM).
Now can Google use it to do something big and important? Please? We want to see that it works for you. Invest in it by building products with it and show us we should do the same.
Can the Dart package management tool fetch/install packages which are not hosted at pub.dartlang.org? Can it install packages straight from a github repo?
Functional programming goes far beyond that. It encourages things such as immutability, referential transparency, powerful pattern matching, the heavy use of recursion, and robust type systems.
JavaScript either does not support such techniques and concepts, or it makes them difficult to use. Thus it is improper to consider JavaScript a "functional" programming language.
The same goes for JavaScript's so-called support for OO. Prototype-based OO is one of the least-useful approaches to begin with, for real-world software development, and JavaScript even manages to implement it quite badly compared to other languages offering prototype-based OO. JavaScript's complete lack of class-based OO (although, we may see this change with future revisions of the language) further suggests that it's wrong to call it an "object-oriented" language.
I'm not sure we can even make this comparison. JavaScript is, at best, an imperative language that has tried, rather poorly, to partially incorporate concepts from more advanced programming language paradigms. It's hard to imagine Dart, or any other language, supporting more advanced concepts any worse than JavaScript already has.
Languages such as Java and C# have a distinction between objects and primitives such as int and bool. In Dart all types are objects - even null! This is why Dart is pureOO.
Dart has some of the classic higher order functions in it's core library - i.e. map, reduce etc. But it's not a functional language like Haskell.
I am reminded of the folks who optimized .kkrieger, which is a 95 kB first-person shooter. See "Metaprogramming for Madmen":
http://fgiesen.wordpress.com/2012/04/08/metaprogramming-for-...
Some highlights: during the test run, the player never pressed the up arrow key in the menu, so that functionality was removed by their tools. Enemies at the beginning never hit the player, so the code which handles damage was compiled out. And the system used a certain brand of graphics card, so code necessary for other graphics cards was compiled out.
The lesson is: don't let tools change code semantics based only on black-box testing.
You are right from a theoretical standpoint, but I'm not so sure this fits with how web applications are known to run and the patterns development usually follows.
Developers who shove an object of one type in an instance or temporary variable one time, and a different one another time are usually doing something bad, even in dynamic environments -- unless there is a specific interface involved. Just because "duck typing" is fast, doesn't mean that it has to be loose.
The point, actually, is to discover where types are being misused as much as to discover what the types are.
> The lesson is: don't let tools change code semantics based only on black-box testing.
I'm also advocating this. However, it seems like you're mainly familiar with dealing with types in statically typed environments. In dynamic environments, the developers still need to know the types. Often, there are hard and fast rules only enforced by convention. This is indeed a source of errors, but by and large, programmers are very good at managing this. In other words, very often, the programmers will know. I see environments like Dart as a way to eliminate such conventions, but still enable very fast prototyping in the beginning. (Ultimately, static types are better for maintenance.)
It's the most open language I know, fully OSS'ed with an extended license to include any implicit patents (removing Patent FUD), developed out in the open and accepting 3rd party contributions and inviting feedback to influence language design.
Lars Bak also mentioned at Google I/O that they're in the process of trying to get it standardized, not sure what's left to do to make it any more "open" and inviting.
http://code.google.com/p/dart/source/list
http://code.google.com/p/closure-compiler/source/list
http://code.google.com/p/closure-library/source/list
Their development is very much insular. That's not to say it's a poor idea to depend on these products, but they don't compare to projects like Python with formal processes for revisions (PEP) or at least some discussion.
It would be nice if Google maintained mirrors on Github and accepted pull requests and such, but I don't see that ever happening.
You said "product", but you should say "project".
If you want to assess the openness of the development process, look at the process itself:
https://code.google.com/p/dart/wiki/Contributing https://groups.google.com/a/dartlang.org/forum/?fromgroups#!...
If code reviews are happening in the open and there's a process to bring new contributors on board, that's a great start. This early in the game, you can't expect random members of the open source community to start contributing more than a dedicated team at Google.
> It would be nice if Google maintained mirrors on Github and accepted pull requests and such, but I don't see that ever happening.
Oh? http://github.com/google https://github.com/dart-lang
Also, FWIW on the Go project we have more than 300 non-Google contributors and a solid core of dedicated committers. https://code.google.com/p/go/source/list
I have to wonder what agenda drives people to claim that this is not "in any way" an open development process.
Actually, external contributors John Evans and Ladislav Thon submitted and landed patches via github.
https://chromiumcodereview.appspot.com//10168022 https://chromiumcodereview.appspot.com//10166019
Not all of the code is on github but many libraries are. Web ui is developed via github. See here for a full list:
Direction coming from a company that has a goal for the language can be a good thing. Java was an amazing language for a number of years until Sun decided to let it languish.
Dart is under a very open license that anyone can take any part of the language and use it for their own. The website, spec, vm, analyzer, compiler, and editor are all under open and free licenses. If people get fed up with Google's handling of Dart, they can fork it.
I think Java is a great example of why corporate programming languages are a bad thing. Do you remember the first wave of Java adoption? Do you remember how it was adopted in all sorts of places it had no business being because Sun rammed it down everyone's throats through their sales force? The core of Java and the engineering behind the VM are thanks to Gosling, not Sun.
I'm not criticizing Sun here, either. That's just how it was done back then. Sun was positively benevolent compared to the likes of Cincom.
https://groups.google.com/a/dartlang.org/forum/#!topic/compi...
TypeScript is good that you can transition gradually. I've been using it for the past week and it almost feels like working with Dart with the advantage that's it's just JavaScript. TypeScript interfaces to hundreds of JavaScript libs and jQuery plugins have already been written.
I imagine I'll settle on Dart for some things and TypeScript for others and maybe eventually get them working together.