language

g classes. There's a sort of zen koan here where algebraic datatypes are a poor man's subclasses and subclasses are a poor man's algebraic datatypes. The way most multi-paradigm languages like Scala and Kotlin handle this is that sum types are just syntactic sugar for defining a little class hierarchy. Likewise, pattern-matching becomes syntax sugar for instanceof checks and field access. I like that sugar and hope we can add something similar to Dart, but I don't find it's omission to be a profound oversight. It makes some kinds of code nicer, but doesn't significantly affect the expressiveness or capability of the language. > Dart just feels like the same sort of OO language we've been getting since Java became popular. Yeah. The original designers of the language designed something very conservative. I think they wanted to make a VM with certain features (single dispatch, static class structure, no static initialization, etc.), and designed the safest language they could come up with to let them do that. There is a lot of benefit to familiarity. I like classes and C-family syntax, and we see very clearly that Dart is really easy for people to learn and become productive in. We've done user studies where participants have been able to write correct Dart code without knowing what language they were using. It's hard to underestimate the value of that. But there is also value in providing the modern tools people want in order to write clean, beautiful, correct, maintainable code. Dart has some catching up to do there. We're making a lot of progress. With Dart 2.0, we replaced the old unsound optional type system with a real, modern, expressive, sound static type system. It was a ton of work to do that while dealing with millions of lines of existing code. We didn't get all the type system features we wanted, but we have a foundation we can build on now. The optional type system had some nice properties, but was effectively a dead end. When your types are optional, you can't hang any language semantics off them. That takes lots of features off the table: implicit conversions, extension methods, etc. > Also the continued existence of null in new programming languages is a baffling choice to me. I have always believed [0] that not having non-nullable types was a mistake in Dart 1.0. We are fixing it now: https://github.com/dart-lang/language/blob/master/working/01... There's a lot of work to do, but I'm really excited with the design. Unlike many other languages, we have something that becomes fully sound with respect to null errors. This means that once a program is fully migrated, a compiler will be able to take advantage of non-nullable types for performance optimizations. It will be quite a while before we get to the point where we can do this, but it's cool that that's on the table. [0]: http://journal.stuffwithstuff.com/2011/10/29/a-proposal-for-...

igates how feasible this is in practice, so making your language rely on this optimization for tolerable performance is a very large gamble. This may change over time now that JS has generators and may be adding async/await syntax, but Dart was designed before either of those existed. > Also if/else not being an expression Yeah, everything being an expression is nice. I wish Dart had been designed that way. The original designers of the language believed they needed to be very conservative in order to be successful and I think they overshot that mark. > syntactic complexity (e.g. defining constructors with factory/static/const keyword combinations) Some of this is annoying, yes. It does have some practical value, though: * The restriction around initializing final fields in the constructor initialization list, which is what forces you to use factory constructors in some cases, ensures a very nice property: it means in Dart you can never observe a final field before it has been initialized. This is not true in C#, Java, or Kotlin. Now that we are working on non-nullable types for Dart [2], this will let us have sound non-nullable types, unlike those other languages. * Personally, I find const to be more of a hassle than it's worth, but const constructors do let you define real compile-time constant objects of user-defined classes, which isn't something some other languages can express. That, in turn, lets you rely on very fast identity tests for checking equality between two objects. Flutter relies on this heavily when diffing the widget tree to determine which parts have changed efficiently. > Why come up with a new language in 2011 that repeats the null mistake? Tell me about it [3]. (Note the date on that blog post.) We're working to fix it now. [1]: http://journal.stuffwithstuff.com/2015/02/01/what-color-is-y... [2]: https://github.com/dart-lang/language/issues/110 [3]: http://journal.stuffwithstuff.com/2011/10/29/a-proposal-for-...