Personal opinion time:

Lars and Kasper, the original leads and creators of the language came out very confidently with this mission to get Dart natively supported in the browser based on the assumption that the language was so good and the VM would be so fast that users would clamor it.

They had the best of intentions — they really did want to make a delightful, productive, fast language. They intended to move the entire web forward the same way V8 had when it first launched, and they believed deeply that Dart would enable that.

But I think they really underestimated how vastly different designing and marketing a language is from simply implementing an already-successful one.

It's not enough to just have a good product. The way you present it is often more important. And you don't even have the luxury of defining "good product" — you must be mercenary in letting your users' needs override your personal preferences. All of that was a real struggle for them.

For what it's worth, there's been a lot of staff changes over the years since Dart first launched. Lars and Kasper have left to try the startup thing again (which I think is a better fit for their skills and desires than evolving a big open source language). The team we have now, I believe, is much better aligned with what you're saying.

It sucks that we do have this baggage, but I hope we can improve our reputation over time. I'm hopeful we can — it took Java several tries before it found its footing.

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.

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

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

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.

I don't understand why this myth is still around.

C++ never had a killer app to start its momentum.

Neither did Javascript. Nor Java really (or maybe applets, back in the days?).

Languages can succeed on technical merits alone if they come out at the right time and fix real problems that programmers experience on current mainstream languages.

1. Extreme compatibility with the current entrenched language so you can incrementally migrate. C++ from C. CoffeeScript and TypeScript from JavaScript. Kotlin from Java.

2. A killer app (well, framework). Rails for Ruby. WinForms for C#. Applets and J2EE for Java (later Android).

3. A new platform where you must use the language to target it. C for UNIX. Objective-C for iOS. JavaScript for the browser.

There are a few exceptions here and there, but the above are the typical well-trod paths to success for a language.

What was Python's killer app?

What is Rust's killer app?

Go's?

Kotlin's?

Java is a counter example to your claim #3 since it not only does it run on all OS'es but you can also develop it on all OS'es.

Not a killer app, but the fact you have so many ML frameworks

> What is Rust's killer app?

That's clearly Servo.

> Go?

It was docker which really made Go take off, it was their first big platform.

> Kotlin's?

Android compatibility, before that it was a niche language not being picked up much.

C++ was immediately adopted by all major C compiler vendors as it came from AT&T as well.

Microsoft C/C++ 7.0 for MS-DOS was the very last one to adopt C++ on the toolchain.

It was the lingua franca of all major desktop OS GUI frameworks, leaving C just for their lower layers, MS-DOS (Turbo Vision), OS/2 (C/Set++), Windows (OWL, VCL, MFC), Mac OS (PowerPlant, MacApp), BeOS, Symbian.

If you were doing plain C GUI programming you were doing it wrong.

> Neither did Javascript.

JavaScript owns the browser, there is hardly any other alternative regarding "browser systems programming".

> or Java really (or maybe applets, back in the days?).

Java's portability was a gift compared with C compilers still in the middle of migrating from K&R C to ANSI C, C++ compilers which were silos with their GUI frameworks and a standard still a couple of years away to be fully defined.

More than today?

https://de.indeed.com/viewjob?jk=6c49a2deeb389df8&q=rust&tk=...

https://de.indeed.com/viewjob?jk=6823f26122417b2d&q=rust&tk=...

I beat the Reversi app on first try. I'm guessing it's not very strong. :)

Haha yes I weakened the AI somewhat compared to the original version created by RedBrogdon. It's not fun to be constantly thrashed by an opponent who takes 0.2 seconds per move! Despite my changes I still lose about 3 out of every 4 games :(

https://github.com/google/flutter-desktop-embedding

The language itself is very well designed and pleasurable to write code in.

None of which invalidates Dart, but I know I was less than excited when Dart was announced as it seemed more Browser Wars crap rather than an improvement. Nowadays I'm more inclined to hold Google's history of not supporting products consistently (or at all, in most cases) against Dart than anything about the language specifically,

That was never the case. Ever. Google was the first company to really take JavaScript seriously and launched the client-side JavaScript revolution with Maps and Gmail.

This criticism was leveled at Dart because as I argued, when Dart was launched some people (purposely) found certain parts of the syntax superficially resembled Java. It was also a time when front-end web devs haven't rediscovered the benefits of compile-time type checking (there was a time, believe it or not, when static typing was disparaged by frontend web-devs)

The irony is that Dart is a better language than JavaScript and the world would have benefitted had Dart become a browser standard (though Apple, Microsoft and Mozilla were never going to just accept a language designed by Google - so that was a pipe dream).

True! Google Maps was a revolutionary use of AJAX. However, that is totally orthogonal to if JS was being written like JS, or like something else.

> This criticism was leveled at Dart because as I argued

Except I wasn't leveling that criticism at Dart. I'm talking about Google efforts in general at the time. You can see it in GWT, you can see it in the first generally accepted JS styleguide (done by Google), and you can REALLY see it in the articles and efforts of Google at the time where person after person laboriously tried to make JS _behave_ like Java (so we're not talking syntax). The late 90s and early aughts were a battle between those that wanted to recreate Classical OOP in JS and those that wanted JS to be what it has ended up being.

I don't even KNOW Dart to criticize it about anything, but I knew what I was seeing from Google at the time and why I wasn't swayed that they were creating something that would be accepted by the community and other browser makers.

> (there was a time, believe it or not, when static typing was disparaged by frontend web-devs)

...and it continues to this day in many corners - the issue (generally) isn't static typing but instead the cost/benefit involved - are enough runtime errors prevented to cover the cost of me informing a type system. There's a reason JS has spread so far - the time cost of static languages is just as real as the runtime risks of dynamic, and pretending that this equation should always favor proven correctness just results in more work being done in the dynamic camps.

The large number of people who had to know it because of its status as the only reliably-available cross-browser web client language, and the focus engines got because of its web client role, mostly.

Ok, but just to be clear, at no point did Google actually try to replace JavaScript with Java.

>You can see it in GWT

Oh come on. GWT was transpilation tool with a built-in component framework. It solved a real problem for specific use-cases and was primarily adopted by enterprise developers. It was never a replacement for JavaScript.

>and you can REALLY see it in the articles and efforts of Google at the time where person after person laboriously tried to make JS _behave_ like Java

Can you provide an example of this? I have no idea what you're referring to.

>The late 90s and early aughts were a battle between those that wanted to recreate Classical OOP in JS and those that wanted JS to be what it has ended up being.

And Google was a non-factor in the development of the web technologies and standards in the late 90s and early 00s (Chrome wasn't released until 2008. Ajaxy Gmail was released in 2004). Also, nobody gave a crap about JavaScript in the 90s and early 00s (Crockford's JS:The Good Parts wasn't released until 2008). Maybe you're thinking of the development of ActionScript 3.0 which had OO constructs and was supposed to be a replacement for JavaScript before (I believe) Microsoft balked and left Adobe hanging. Which is a shame because AS3 is also superior to ECMAScript 5 and world would have been better with AS3 in the browser (and don't get me wrong, AS3 is very quirky language).

But regardless, the whole "Google is trying to replace JavaScript with Java" was pure paranoia not grounded in fact.

> the issue (generally) isn't static typing but instead the cost/benefit involved

You can build in optional typing if you really want to (AS3 had that). Having said that, I cannot see what time you lose by enforcing type constraints. And dynamic languages are not faster or more productive. At best it's a no-op. At worst you're dealing with runtime errors which are 100x painful and costly than dealing with a compile-time error.

>There's a reason JS has spread so far

It's the lingua franca of the web because it's the only language supported by major browsers. That's why it spread so far, not because it is a great language. In fact, the plethora of transpilation tools should give you a clue how shitty this language is.

A claim I didn't make. They TREATED Javascript like Java, and tried to adopt the behaviors. This generally works poorly in any language transition. I've seen Perl written like C, Python written like Java, Java written like Perl, etc, and it's always a bad thing.

> GWT was ....never a replacement for JavaScript.

I never said it was (You'll see a recurring theme in your responses here...). GWT, however, wasn't going to encourage me to trust Google's recommendations.

> Can you provide an example of this? [treating Javascript as Java] I have no idea what you're referring to

Ironically it's hard to come up with a lot of material from that time period, but generally you can see the number of libraries that would try to create Classical inheritance so we could use Java OOP conventions. Far too many books came out that would spend their first chapters creating such a library, and then use that library for all the rest of the book, meaning that if you want to write other styles or learn JS strengths and quirks, you were out of luck - instead you learned that JS does not do a good job of recreating a Java-like code structure.

> Google was a non-factor in the development of the web technologies and standards in the late 90s and early 00s

You are correct - my memory tends to forget how far away some of those experiences were. I was talking mid-aughts to 2011 ish. starting pre-Chrome, but going through Chrome, GWT, GWA). Google released the first generally used styleguide for JS, got vocal in standards discussions, etc. By the time Dart and NaCl came around (2011?) Google had established themselves as worth listening to, but also worth taking salt with (pun retroactively intended).

I mean, if someone shows up and starts saying the language is shitty and we should all be doing it differently, we're going to take whatever they say a little skeptically.

> I cannot see what time you lose by enforcing type constraints

Enforcing? Generally not much. Giving the info so the system can do it? Quite a bit. Not worth breaking down here, I'll just say that the market is clearly not convinced by your arguments, and you can dismiss them as idiots if you like, I'm just saying there are a lot of people that don't think static typing is automatically the best thing to do.

> how shitty this language is

A debate not worth having as you've clearly made up your mind. Nonetheless, to stick to the original point: Dart wasn't given a fair shake, but Google had not put themselves in a position to be considered a good source of "future of web dev languages across browsers" trust, despite their efforts to improve dynamic web apps and the browser space in general. I heard the "Replace Javascript with Java" rumors, but everyone that I respected disregarded that and instead focused on developing Javascript as Javascript. That doesn't always make their choices correct (ask me about CSS sometime!) but it does suggest that their reaction to Dart was not solely motivated out of a fear of replacing JS with Java. I myself was not a fan of JS when Dart was announced, but had no interest in picking up a Chrome-only feature, particularly when everyone focused on how it wasn't JS instead of how it would make my job easier. Not being JS is fine, but if it comes across as NIH because your bikeshed is better, I have little interest.

Again, because you're making nebulous claims it's really hard to argue against. I still don't see how Google treated JavaScript like Java. I don't know what that entails.

>Ironically it's hard to come up with a lot of material from that time period, but generally you can see the number of libraries that would try to create Classical inheritance so we could use Java OOP conventions.

You must be thinking about the Closure Compiler[1], which was a transpilation solution driven by JavaScript comments which provided type and directive decorations around raw JS source allowing compile-time checks. All it was a proto-TypeScript. Do you think TypeScript is Microsoft attempt to treat JavaScript like Java, because TypeScript provides OO constructs (like classes, inheritance, polymorphism)? Because that's what you're saying.

>Ironically it's hard to come up with a lot of material from that time period,

And my argument is, you won't find anything, because there was nothing to it. It was irrational and emotional argument.

>I mean, if someone shows up and starts saying the language is shitty and we should all be doing it differently,

And they were right. For example, people complained about NaCL/PNaCL (sometimes for good reasons, it was a proprietary solution) but WebAssembly is the spiritual successor to NaCL/PNaCL. JavaScript is still terrible for writing large amounts of code and this is why people use TypeScript to make it palatable.

>I'll just say that the market is clearly not convinced by your arguments

I would respectfully disagree. And my counter argument is the popularity and plethora of transpilation languages and pre-processing frameworks for the entire browser tech stack (HTML/JS/CSS). If you're writing 100k lines of JS code, you're not writing it in vanilla JavaScript, unless you're a sado-masochist and you like pain. Front-end devs have also come around on static typing because you really don't know pain until you start dealing with what should be trivial bugs in a large application written in a dynamic language. Compile-time checks and AOT optimizations are incredibly powerful tools.

[1] https://developers.google.com/closure/compiler/

It's not really an architectural difference, I'd agree (outside of isolates vs. threads): Dart is mostly about ergonomics compared to other class-based OO languages. Unification of class, interface, and mixin; method cascades for “free” fluent interfaces; the syntactic support for sync and async generators along with async/await, really transparent (binary, not just source-level like C#) getters and setters; named and factory constructors; the whole deep consideration of const-ness, etc., are all ergonomic features, not major changes in architecture / paradigm.

It's pretty simple, in my view: JS developers were happy with the language and didn't want a browser vendor trying to replace it. Remember that it was announced around the time that the new ES6 ("Harmony") features were generating a lot of excitement about the future of JS.

- CoffeeScript was hugely popular at the time - it was even mandatory at GitHub to make new applications in CS not JS

- Typescript was immediately well recieved. JS folk liked optional typing.

- Ruby was popular amongst the web community

Google would have done a lot better than making a new road and wondering why there's nobody on it.

We'd probably really be regretting that choice since CoffeeScript use is dwindling and the programmer ecosystem has generally turned towards static types.

> - Typescript was immediately well recieved. JS folk liked optional typing.

Dart was an optionally typed language and is actually older than TypeScript.

But, the original creators were very focused on getting a native Dart VM in browsers and were willing to sacrifice seamless JS interop to get that. There's good arguments for that since great interop often means adding ugly features to your language in order to play nice with the existing one. Dart was intended to be a bigger leap forward from JS.

If the VM wasn't part of the plan, then Dart probably would have hewed much closer to JS and been very similar to TypeScript. That probably would have been good for us then, but it might have been a limitation long-term. TypeScript is a really nice language, but it's got a lot of baggage that it inherits from JS.

Dart is, I think, a much nicer language if you don't need to reuse and interop with a big corpus of existing JS code.

> - Ruby was popular amongst the web community

Is the "was" part of that intentional? I like Ruby a lot, but it's luster seems to have faded some in the past couple of years.

I think what all of your points show is that if you pave cowpaths when doing language work, you end up optimizing for what users did several years ago. Languages take a long time to develop, so I think you have to aim for where you think users will be, otherwise you end up irrelevant by the time you launch.

BecauseJS eventually got better and everyone moved to new versions and Babel. If you'd offered an alternative, maybe they would have moved to that.

> Dart was an optionally typed language and is actually older than TypeScript.

OK.

> Is the "was" part of that intentional?

Yep, a lot of Ruby folk moved to node, now they're in Elixir or Go.

> I think you have to aim for where you think users will be, otherwise you end up irrelevant by the time you launch.

I totally agree, but I think those cowpaths give you a good idea of where the ball is moving, particularly syntactically. And it doesn't seem like Dart paid any attention to that signal at all.

Except it has features other langs don’t like async/await and async-everything.

This is why many people including myself use Javascript even on the server. For example, I’d consider Python a downgrade.

I point this out because it seems to be news to you that many people find Javascript pleasant and disdain for its “unsafe core”, whatever that means, extremely oversold.

They're excited because new features are useful to lots of people.

Funny, that's what I saw as the core attraction. The fact that they never pushed for adoption in other browsers and fell back on transpilation removed the benefit you'd get from an alternative scripting environment.

Thankfully, we now have web assembly.