Dart 1.8: library improvements and experimental support for enums | Hacker News Reader

Dart 1.8: library improvements and experimental support for enums

news.dartlang.org

57 pointsPharohbot14 comments

Out of the myriad new languages the crop out almost daily, Dart stands out as clean, modern, fast and ready to roll with a large standard library. The team is strong and stacked with experts in the field.

On the flip side, algebraic data types have been invented in the 70es and are fundamental to the logic of programming. I don't understand the process through which an otherwise informed team ships half-baked sum types in 2014 in the guise of enums.

Sum types and subclasses cover much of the same problem space just with different trade-offs. Sum types give you exhaustiveness checking, while subclasses give you open-ended extensibility.

Given that Dart already has subclasses and they're the natural way for people to solve most problems where you'd reach for a sum type in other languages, I don't think there's as much need for enums to be larger and feature-rich. Instead, the language team focused them on the narrow use cases of wanting just an exhaustively checked numeric subrange, similar to enums in C#.

I do personally wish you could add methods and fields to them (á la Java but without case-specific methods and fields), but I think the language team wanted something easier to compile to a bare number in JS. Maybe they'll get added later.

Unless I'm missing something, enums are closed, thus overlap with sum types for the use-cases. Subclasses are an implementation detail in this context. Here is an example that uses subclasses to implement generalized enums, aka sum types:

  enum List {
    Cons(head, tail) {...}
    Nil {...}

    int length() {
      switch (this) {
        case Cons(head, tail): return 1 + length(tail) 
        case Nil: return 0
      }
    }
  }

Mind you, this is syntactic sugar and you can do it by hand with enums + sublcasses. But the whole point of clean languages is to remove unnecessary boilerplate :)

Haxe has another example of this: http://haxe.org/manual/types-enum-instance.html

Note that enums in Haxe are pure data types, and can't have member functions and/or values. However, since enums are public by nature, it's possible to achieve this easily with "using": http://try.haxe.org/#87bF5

They're experts alright but it would appear that although you can take the person out of the Smalltalk, you can't quite take all the Smalltalk out of the person (not a bad thing in my opinion).

I'm from C# background and I can't imagine doing large client apps in JS anymore - maybe I'm too old but Dart IDE and integrated debugger is something I can't live without.

Dart is single best client side tech for me.

Pretty much an identical background for me, and I recently had to write a fairly non-trivial client side application (some drag-and-drop, quartz-composer like interface) and I chose Dart. It worked really well. I find that sometimes it's hard for people to reconcile their idealistic vs. pragmatic sensibilities when it comes to new programming languages. Dart makes it incredibly easy to get up and running ... it's pragmatic.

Since you're already invested in the MS stack Did you try TypeScript ?

If yes how does it compare to Dart ?

I left MS stack (not a big fan of Windows), so having really cross platform IDE is a big win for me.

Can't say anything on TS - but AFAIK it's mostly syntactic sugar on JS, no first class IDE on non-Windows, no pub (dedicated Dart package manager), no native VM (I'm also doing server side on Dart recently) and still it's possible shot your foot just like in JS - saying all that - I will have to really try it out.

Any news on Dart VM in chrome? I was planning to make a 3D game that uses SIMD but realized JS doesn't support it yet. Are they waiting for ES7?

Its really, really slow, but it may come up.

1.8 already? Wow. Yet enums are only now being added (the proposal was from 2013)

This puts me off Dart - for now - for two reasons.

Firstly, the language appears to have been rushed. Yes, great tooling, but was the language rushed out the door by corporate Google? Will they ditch Dart just as quickly if it doesn't gain traction? Lots of risk in learning Dart.

Second, if it wasn't rushed out the door, then the language designers made a mistake. It's nice they can admit that but it also shows a lack of conviction and belief in the language they have created. So what makes Dart unique? If I want Java, I use Java. Contrast with Golang and the reasons the team give for not having generics.

From what I see Dart was definitely not rushed. On the contrary. The team puts a lot of thought into what goes into the language and what doesn't (from a language, implementation and tooling pov).

With languages it is easy to add stuff but hard (often impossible) to remove it so it is important to understand the change and make sure it fits well with what is in the language and what might be added later.

It obviously helps to have a great team that has done exactly that many times over for many many other languages used in production.

Dart is a very clean language and I guess it made sense to postpone non-essential stuff like Enums & Async/Await. This doesn't mean those aren't awesome and great to have, it just means those things like other things better aren't rushed into the language but well thought through.

Dart only looks like java (this was a deliberate design choice to increase familiarity and ease learning/adoption), but it works a lot more like ruby and go.

Reply on news.ycombinator.com