[sbjs]

I think what killed Dart is that they emphasized their plans to make Dart a first-class scripting language of Chrome, so that you could use <script type="text/dart"> instead of JavaScript. This had a lot of backlash from literally everyone, I think mostly because they were bit too hard by IE doing the exact same thing just a few years before. Only after a few years the Dart team changed courses and said "never mind about that VM-inside-Chrome thing, we're just going to compile to JS like everyone else" but it was too late and nobody cared about Dart anymore and all the excitement and enthusiasm was gone. I think people don't realize just how much excitement and enthusiasm from a potential community makes or breaks a project when it's first announced.

[munificent]

I'm on the Dart team and I agree with pretty much all of this.

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.

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

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

[Daegalus]

It's a shame, I was a HUGE dart for backend proponent. I made libraries and even middleware for API servers and such. I was constantly fighting to get ANY focus on the backend standard libs. In the end, I had to give up and stopped fighting. I still maintain my uuid, base32, and otp libraries, just upgraded them for 2.0, but Its a shame because Dart could have so easily competed with Node.js and it was a major replacement for it for me.

[sbjs]

A language by itself is almost never useful, every language needs a killer app, a concrete tangible thing that that language can do better 100x better than any alternative. Like how Ruby had Rails or JS had browsers or Python has ML. That’s not to say you can’t do other things with these, just that their competitor is good enough and has momentum and mind share. It sounds like Dart now has Flutter and I think that’s going to be a huge deal moving forward.

[hota_mazi]

> A language by itself is almost never useful, every language needs a killer app,

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.

[munificent]

I think you need at least one of three things to get a new language off the ground:

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.

[hota_mazi]

I listed two clear counter examples to claim #2, C++ and Javascript. I'm even tempted to put C in that list, because C was already popular before Linux.

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.

[platinumrad]

"at least one of three"

[realusername]

> What was Python's killer app?

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.

[wild_preference]

Killer app is the wrong phrase. Rather every new language needs a competitive upside over existing languages to be successful. At which point your proposed questions have easy answers.

[pjmlp]

C++ and Javascript are definitely not counter examples as I commented.

[flukus]

Outside of the HN bubble python is the only one of those that got off the ground so far.

[pjmlp]

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

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.

[sbjs]

These days it's mostly about apps, because apps are the main thing that facilitate the transfer of $$$. In the 80s and 90s, enterprises were full of $$$ and needed fast and safe languages for writing all their software. C++ came out to solve this need, and Java came out saying it could do it better. Today enterprises are moving many of their internal tools to the web. Enterprises don't need apps per se, but they do need the tech needed to build internal apps and apps to bridge between them and their partners. Consumers are using desktops less, and mobile or web more. Apps are basically the current de facto software "product". But a lot more goes into making apps today than 30 years ago. An example is how most apps need ML for spam protection and recommendation algorithms, or they are instantly going to be considered outdated and behind the times.

[coldtea]

>In the 80s and 90s, enterprises were full of $$$

More than today?

[sbjs]

I haven't had my caffeine yet today cut me some slack :)

[coldtea]

Golang and Rust also didn't have any killer app.

[nwienert]

Rust definitely has Firefox

[cutler]

Just thought I'd remind you that there are currently 0 Rust jobs on Indeed.co.uk by title for the whole of the UK. The HN bubble is not how the world at large operates.

[coldtea]

Firefox is not the kind of app to drive adoption of the language (like Rails or Python scientific libs etc). It's just an app, people using it could not care less what it's written in.

[sbjs]

Go has Docker

[coldtea]

Yes, but it didn't have anything before it, and yet it gained adoption like crazy.

[megaman22]

Go has a bit of a niche, and Rust is trying real hard, but they aren't Javascript or Java, or C#, or Python, or Rails, or PHP, or C++, or Objective-C or... Out in the wider world, they are very much playing catchup, and have a very far way to go.

[billchristian]

Javascript had the web. And, Java had the JVM. A killer 'app' is not necessarily singular & discrete.

[pier25]

Off topic but... are there any plans to adapt Flutter for desktop apps?

[MarkMc]

I'm the lead dev on just such a project: https://feather-apps.com/

[pier25]

Looks great!

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

[MarkMc]

Thanks :)

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 :(

[kyrra]

There is an unofficial implementation for it.

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

[macspoofing]

I agree. In addition because Dart shared some superficial similarities with Java, some people just assumed it's Java and criticized the language for it. For example Dart variable declaration is of the form "String a" vs "var s:string" - the former syntax looks like Java so Dart must be Java. It certainly felt like people were willing to 'pile-on' criticism because they felt that JS ecosystem was threatened.

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

[ergothus]

I think your points about Dart being treated unfairly are legit. OTOH, Google certainly invited criticism - early Google efforts on the web were VERY "let's make JavaScript into Java", and as the JS community matured this attitude was viewed with less and less favor. I think it's notable that the community that DID end up having strong influence in the JS world (Node & npm) had much more of a Ruby background than Java.

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,

[macspoofing]

>early Google efforts on the web were VERY "let's make JavaScript into Java"

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

[ergothus]

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

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.

[dragonwriter]

> There's a reason JS has spread so far

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.

[macspoofing]

>I'm talking about Google efforts in general at the time.

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.

[ergothus]

> But regardless, the whole "Google is trying to replace JavaScript with Java

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.

[leshow]

It's more than superficial, I struggle to see how using Dart would be at all different from how you would architect an app in Java. It's an OO language with an almost identical set of type system features besides the fact that it has inference. It's not as if it borrows much from the ML lineage; I don't see any examples of pattern matching and currying in the Dart docs. It's all class based polymorphism.

[dragonwriter]

> I struggle to see how using Dart would be at all different from how you would architect an app in Java.

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.

[macspoofing]

So to you OO means Java?

[pcwalton]

> I think mostly because they were bit too hard by IE doing the exact same thing just a few years before.

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.

[sbjs]

I think Dart started internal development around the same time CoffeeScript gained major popularity and brought attention to JS's desperate need to evolve, but they released at a bad time: when JS finally did start to evolve (as Harmony) which was a reaction to CoffeeScript in the first place. So CoffeeScript served its purpose of pushing JS forward, and most other compile-to-JS languages had no more purpose. I say most because some serve a different purpose than just being a slightly nicer JS, like how Elm piggy-backs on the familiarity of Haskell and provides a niche no-mutation environment, and TypeScript adds type-checking for those of us who can't write code as confidently without it. But the rest served their purpose, and Dart's dream of having its own VM inside Chrome was probably what killed it so quickly.

[nailer]

If Google had paved some cowpaths:

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

[munificent]

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

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.

[nailer]

> We'd probably really be regretting that choice since CoffeeScript use is dwindling

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.

[billchristian]

Lars (and company) approach to implement a Dart VM in Chrome was just ahead of its time. WASM is an attempt to accomplish a similar goal and implement a common VM. Perhaps, in the near future, Dart can be a syntax to compile to WASM and accomplish Lars' intentions.

[cutler]

Don't forget Clojurescript which heavily influenced the development of React. Clojure is unique in the landscape of modern programming languages.

[Joboman555]

What I don’t understand is why people are excited about the new features of JavaScript. The problem with JavaScript has never been that it doesn’t have enough features or syntactic sugar. The problem with JavaScript is that it has a rotten, unsafe core. Its very nature is antithetical to writing robust software, yet we need it to create dynamic UI applications.

[wild_preference]

I’m not convinced Javascript boils down to anything worse than other dynamically-typed languages.

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.

[pcwalton]

> What I don’t understand is why people are excited about the new features of JavaScript.

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

[drb91]

> I think what killed Dart is that they emphasized their plans to make Dart a first-class scripting language of Chrome, so that you could use <script type="text/dart"> instead of JavaScript.

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.

[bradleyjg]

For me it was that google had burned all their credibility with me on GWT. I’m not taking any more career risks on their projects. Too much corporate ADD over there.