fpdart VS language

Really cool, might import it and give it a shot!

https://github.com/SandroMaglione/fpdart/blob/main/examples/...

use a 3rd party package like fpdart, which offers ergonomic APIs like Either and TaskEither

By the way, I highly recommend checking out fpdart. It has most stuff that dartz has but also provides docstrings and is well-tested

If you use something like fpdart, you have the more functional Either type (called Result in Rust).

https://pub.dev/packages/fpdart#eitherlibsrceitherdart

I’ve been using Either and friends from fpdart and very happy with the way it helps clean up the code.

You can get a lot of this by mixing in some uses of https://pub.dev/packages/fpdart. It's not whole-ly integrated, but the boundaries aren't too intolerable.

I find https://pub.dev/packages/fpdart to be a better documented and tested and modernly maintained functional implementation, and includes tools to connect futures with either or option.

Use fpdart instead have better support.

I noticed that I can enable inline-class as an experiment to play with Extension Types. You need to also add sdk: ^3.3.0-0 to your pubspec.yaml.

Current syntax is not all that bad if you are going to do OO and add various helper methods on `Message` and its subclasses, but if you just want to define your data and no behavior / helpers - then it is exceedingly verbose.

[1]: https://github.com/dart-lang/language/issues/3021

Reference

A future version of Dart will probably support macros which should make this all a bit easier to use, similar to how Swift 5.9 works which makes already fantastic use of its new macro capabilities by integrating mobx (or solidjs) like reactivity into SwiftUI by a harmlessly looking @Obervable annotation.

Coming from a Dart context here where that team is also looking at adding Macros to the language. It was really interesting to compare and contrast some of the approaches https://github.com/dart-lang/language/blob/main/working/macr...

Yes, that needs a bit of boilerplate for the constructor declaration and the extra build method, but I personally don't mind and with implicit constructors this will become much easier. Also, you get a performant UI as Flutter knows to not redraw widgets that didn't change.

I know that it would be nice not to use the generator at all, but we have to wait until static metaprogramming is implemented in dart. https://github.com/dart-lang/language/issues/1482

I implemented a prototype version of the algorithm in that paper when exploring exhaustiveness checking for pattern matching in Dart.

I found it pretty easy to understand, but also really easy to get it to generate huge combinatorially large spaces. Some careful memoization and deduplication helped, but even so I never got the performance to a state I considered acceptable.

Instead, I went with Luc Maranget's classic approach and figured out a way to adapt it to a language with subtyping (with a ton of work from Johnni Winther to figure out all of the hard complex cases around generics):

https://github.com/dart-lang/language/blob/main/accepted/fut...

The performance (in the prototype!) was dramatically better. You can always make pattern matching go combinatorial, but I haven't seen any real-world switches get particularly slow with our approach yet, and we have some fairly large tests of matching on tuples of enums.