[kbd]

I think a lot of what people found off-putting about Dart is that Google already recently came out with a new language that has become very successful. Announcing another one, which at first glance looks like yet another curly brace language not that far from Java, was a step too far for people to be interested.

Nowadays, the only thing driving Dart seems to be Flutter, which again is head-scratching. Like, "Flutter sounds interesting but in addition to learning Flutter I need to learn a brand new programming language for it that's really only used for Flutter?" People only have so much bandwidth for new things and there's already so much to constantly learn in our industry.

[munificent]

I could be wrong, but I don't believe the existence of Go was much of a problem. Go and Dart are very different languages aimed for very different use cases. If anything, I think Go helped us because we could point to it as a successful language that Google hasn't cancelled.

> 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 not the most beautiful code in the world, but I do think it's a good bit simpler and cleaner than it would be in Java.

[sbjs]

The thing is, this is almost identical to well written JavaScript. In fact you could do almost all of this in JS even before ES5. So the non-Java-like features you're using here were already present, which again suggests that Dart isn't really getting past the "Good Enough" problem.

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

[munificent]

> In fact you could do almost all of this in JS even before ES5.

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

[lizmat]

Why was "except Perl of course" needed here? Do you have any data to back up that you can not write well written code in Perl? Or are you just simply venting your prejudices?

[andrewbinstock]

> I could be wrong, but I don't believe the existence of Go was much of a problem.

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.

[kbd]

Totally agree. Also, Go was refreshing. Intentionally limited, yes, but simple-yet-powerful. Then they show off Dart and it looked like yet another 90's-style curly-brace language, and I'm sure I'm not the only one who asked "why bother?".

[wmfiv]

That is nice. It's also almost indistuishable from Java 10. The string interpolation at the end is the last big syntactic nicety Java is missing - at least relative to this example.

[pjmlp]

Yes it is a little nicer than Java 11, but not so much to really make a difference, while throwing away all the Maven central goodies.

    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);
            }
        }
    }

[kbd]

> I do think it's a good bit simpler and cleaner than it would be in Java.

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

[cutler]

Java 10 only has type inference for method-scoped vars.

[pjmlp]

Java 11 is around the corner and has improved upon it.

[nailer]

I removed everything that seems redundant. Less syntax means less to break, and less for new programmers (who are 10x the volume of existing programmers) to learn:

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

    content = createContent()
    save = content.createHero("blah")

    while (true) 
    watch = Stopwatch()
    watch.start()

    # Generate a dungeon at each level.
    count = 0
    for (i = 1; i <= Option.maxDepth; i++) 
        game = Game(content, save, 1)
        for (_ 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")

[aoeusnth1]

how are the semicolons in a for loop redundant? Without them it's extremely difficult to parse what's going on.

[nailer]

Typo when removing the others. Thanks for the spot. Maybe a forEach or map might be more appropriate for all those future programmers anyway though.

[emmelaich]

While you're there, you may as well indent everything after the "while(true)"

[nailer]

Oops, I killed that during one of the edits.

[laxd]

Separating variable declaration and reassignment at a glance makes code more clear. Indenting loop bodys makes code more clear, and the curly braces won't suddenly break. Keeping lines short makes it nicer to work with in various editor setups.

[nailer]

> Separating variable declaration and reassignment at a glance makes code more clear.

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.