> not that far from Java

This is something that hurt us, I think. You can write Dart code that looks a lot like Java, and many of our early public examples did. To make matters worse, for no good reason, Dart 1.0 didn't do any type inference, so even though you could use "var" for local variables, doing so would give you a worse user experience.

But you don't have to write Java in Dart. You can write really elegant, clean code in Dart in a way that Java doesn't enable. You don't have to stuff everything inside classes. We've always had nice terse lambdas, higher-order functions, collection literals, etc.

Here's a random little program of mine:

    import 'package:hauberk/src/engine.dart';
    import 'package:hauberk/src/content.dart';

    main() {
      var content = createContent();
      var save = content.createHero("blah");

      while (true) {
        var watch = Stopwatch();
        watch.start();

        // Generate a dungeon at each level.
        var count = 0;
        for (var i = 1; i <= Option.maxDepth; i++) {
          var game = Game(content, save, 1);
          for (var _ in game.generate());

          // Read some bit of game data so the JIT doesn't optimize the whole
          // program away as dead code.
          if (game.hero.pos.x >= -1) count++;
        }

        watch.stop();
        print("Generated $count dungeons in ${watch.elapsedMilliseconds}ms");
      }
    }

It's also something you could do in Java, with the exception of having to wrap main with the obligatory EntryPoint class.

I think this just goes to show that good code can be written in almost any language (except Perl of course) because writing good code almost always just means writing obvious code, which necessitates avoiding cleverness and obscure features (literally all of Scala), twisting control flow (I'm looking at you State monads and call/cc), or adding too many indirections due to limitations of the language (Java).

Well you do get static type checking if you write it in Dart, but I see your point. :)

It wasn't so much Go per se, but the fact that Google was pushing two new languages at the same time. It created the perception, for me at least, that Google was pushing out new languages to see which ones stuck and kill those that didn't. Google had/has the reputation for killing off projects that it lost interest in. And I wasn't willing to learn new a new language and its ecosystem only to be marooned there a few years later.

So, while I was definitely interested in alternatives to JS, there was no way I'd pick up on Dart.

    import engine.*;
    import static content;

    import static java.lang.System.out;

    public class Demo {
        public void main(String args[]) {
            var content = createContent();
            var save = content.createHero("blah");

            while (true) {
                var start = System.currentTimeMillis();

                // Generate a dungeon at each level.
                var count = 0;
                for (var i = 1; i <= Option.MAX_DEPTH; i++) {
                    var game = new Game(content, save, 1);
                    for (var ignored : game.generate());

                    // Read some bit of game data so the JIT doesn't optimize the whole
                    // program away as dead code.
                    if (game.hero.pos.x >= -1) count++;
                }

                var stop = System.currentTimeMillis();
                var elapsedMilliseconds = start - stop;
                out.printf("Generated %d dungeons in %dms\n", count, elapsedMilliseconds);
            }
        }
    }

Is it really? My Java is rusty, but now that Java has type inference it looks nearly exactly like what you'd type in Java (minus `public static void`, `new`, etc.)

Hrm, maybe. Python does well not using them - if you reassign something, it's being reassigned. Maybe, since declaration is more common, make declaration the default and reassignment explicit?

> Indenting loop bodys makes code more clear

Glad you agree.

> curly braces won't suddenly break

They do all the time, everytime indentation (how people read coe) gets out of sync with braces. Hence avoiding redundancy.

> Keeping lines short makes it nicer to work with in various editor setups.

Displaying code to match the screen is the editors job. Sometimes your screen is 30 characters, sometimes it's a lot more.