Hacker News Reader

Comment by rokob | Hacker News Reader

I generally agree with you but the one point they make in this article that really matters for Dart is it does not have pattern matching. Dart’s nominative type system makes much of standard FP much harder than you’d imagine. I know Rust is nominal too but Rust has a lot of complexity to support these things.

It is very simple to add a Maybe and Either type to Dart (my code base has variants of these to deal with null issues) but imperative destructing is a pain. You can get most of the benefits of those techniques in user land without the language knowing about it, but I agree it still misses out on some stuff.

If Dart already had pattern matching or was willing to add it first then the ADT version could have been chosen, but without that prerequisite nullable types was the only ergonomic choice.

View on HN

I don't buy the pattern matching argument. I've been using Vavr's Option type in Java a lot lately (having banned the use of null from my code), and I don't have any issues with it. I avoid Vavr's pattern matching because I find the syntax to be clunky (not a criticism of the Vavr developers; I think what they've done is impressive within Java's syntax limitations). I do miss pattern matching in general, but I don't find using Option to be any more difficult without it. And no, I never use Option.get(); I have an ArchUnit test set up that will fail the build if anyone tries.

On the flip side, I do find Option a pain to use in Rust sometimes, which does have pattern matching. I think that's a function of the borrow checker making some things harder to express. So perhaps it's not Dart's missing pattern matching that would make Option hard to use there, but some other feature (or missing feature) of the language or type system?

That's an interesting counter point, though another comment in a different post for this same article[1] pointed out that Dart is considering adding pattern matching too.

Though I have trouble understanding how a nominal type system affects this? Does dart not have generics? That's all you need to support these patterns? I'm having trouble understanding how the type of type system plays a role here.

Also, what's 'imperative destructing'? Haven't heard that term before, is that just pulling out a property from an object like this from JS?

    const { foo } = objectWithPropertyFoo;

[1]https://news.ycombinator.com/item?id=25334283

Yes Dart has generics which is how you would implement optional types yourself. The type of type system doesn't play a role here you are right. I was thinking of the really good pattern matching I have experienced usually being present with structural subtyping.

Dart is considering adding pattern matching (and real tuples!) and I think they will eventually get there. I just think that would have had to come first to make the case of optionals over nullable types more compelling.

I would call that example destructing in the normal sense and it is basically a form of pattern matching. To do that in an imperative language without pattern matching (i.e. what I am calling imperative destructuring), you end up with code like

  if (maybeFoo.isSome) {
    final foo = maybeFoo.asValue;
    ...
  }

when you really want

  if let Some(foo) = maybeFoo {...}

You may prefer

    for foo in maybeFoo { ... }

This (AIUI) isn't valid Dart code though, but this would be:

    maybeFoo.forEach((foo) { ... })

Dart is looking at adding pattern matching and "record" types: https://github.com/dart-lang/language/tree/master/working/05...

Reply on news.ycombinator.com