4 ms·

The last time I used Dart, it felt like the worst parts of C# + Java put together somehow. The type system was verbose yet relatively weak in comparison to som

The last time I used Dart, it felt like the worst parts of C# + Java put together somehow. The type system was verbose yet relatively weak in comparison to something like Typescript, it'd already been rewritten once (which isn't a bad thing), and it was almost unusable outside the platform (I remember trying to write tests for something using sqlite.dart and then realizing that you just... couldn't). Flutter is an amazing technical achievement, and to some extent so is Dart (there's a great talk from strangeloop about it) but I just... want to be able to use anything but Dart in there. Being able to use Typescript with Flutter would be heaven (JS compatibility was something in early versions of Dart that was removed).

kennytilton 4y ago
I think you have made the case for ClojureDart. Clojure does not do the Typescript strong typing thing, but it meets the "Not Dart" requirement pretty well. And my specific contrib, Matrix, handles state management and the whole reactive thing pretty well, one area where I see a bit of thrashing in the Flutter community. Check out the examples and esp. the TodoMVC demo, they cover quite a bit of ground.
satvikpendem 4y ago
Dart is at least adding new features relatively quickly (just recently they started working on immutable record data structures with pattern matching, which even TypeScript doesn't have yet) and soon they'll have static metaprogramming meaning you can have Lisp like macros to create your own syntax, including algebraic data types as in any functional language. That is really what people are looking forward to. Another thing is Dart is JITed, AOT compiled as well as compiling to JS and WASM. Very few languages can do all 4. JVM ones can't, so no Kotlin (we'll see how well Kotlin Native works), and V8 isn't AOT so no JS or TS either. Only alternative I can think of is Lua.
- kaba0 4y ago
  It is easy to iterate fast on language design when you don’t care about backwards compatibility. > Very few languages can do all 4. JVM ones can't Java can (JIT is trivial, for AOT there is among others Graal, for JS and WASM there is TeaVM (which works on class files, so now that I think about it, pretty much every JVM language can do all platforms), but also the very great Closure compiler (j2cl) which has no relation to cloJure, made and used heavily by google)
  - satvikpendem 4y ago
    Backwards compatibility is overrated, sticking to it too hard is how we get stuff like JS or C++ that have ten different ways of doing the same thing. I'd much rather a language be improved and break sometimes than to convolve around keeping strict BC. Anyway, they have good BC support since Dart 2 released several years ago so I'm not worried. With your Java example, that's exactly what I mean, you don't need 4 different tools in Dart to achieve the 4 types of compilation, they're all included in the standard Dart compiler/SDK. Sure, if we go by your definition, probably any language has some level of support for each via various random compilers but I'm talking about something first-class, built-in.
    - kaba0 4y ago
      > Backwards compatibility is overrated, sticking to it too hard While there is surely a very delicate balance of slowly deprecating a few things, remember that the only significant productivity booster is relying on existing code (as per Brooks). I’m fairly sure there are orders of magnitude more Java code transpiled to JS running at Google than all of their Dart codebases combined, so not sure “random compilers” are a fair description.
moonchrome 4y ago
I can confirm the experience and I've used dart on multi month projects twice now : first time when it was the JS replacement and using AngularDart back in the angular 2 beta days - it was ahead of the curve at the time with tooling (compared to JS world), but it went nowhere because of poor design choices. Then they decided to salvage the team and made flutter with it - the technical reasons of chosing it over JS sound extremely unconvincing. And the language is as you say the worst of both worlds - verbose and weak type system (I remember getting runtime type exceptions because compiler couldn't catch a type mismatch in a ternary) and none of JS dynamism, no reflection - just boilerplate on top of boilerplate. Worst part is the react like architecture of flutter lends itself really well to immutable state management practices but the language is so weak that any immutable library involves a ton of ugly boilerplate - and they refuse to add stuff like records to the language to ameliorate the problem. The reason it gets me so riled up to rant is that the framework itself and the idea behind it (custom native rendering framework) has potential - but dart makes using it horrible.
- hardwaresofton 4y ago
  Oh this totally reminds me of the BLoC pattern[0][1] that everyone kind of... really gritted their teeth through. It just wasn't at all an appealing way to structure data flow and I was kind of surprised that it was the architectural choice that was being pushed. 90% of the time, it felt like simple IoC plus an app-wide singletons would have been enough for most apps-- trying to get everyone to aadopt BLoC was painful and kinda meh. It's probably just that I never developed a sufficiently big app at scale with lots of devs to see why BLoC was the best way. That said, I'm also reminded of the Boring Flutter Development Show[2], quite possibly the best produced resource I've ever seen as an intro and ongoing guide to a piece of tech. It is excellent. [0]: https://www.dbestech.com/tutorials/flutter-bloc-pattern-examples https://www.dbestech.com/tutorials/flutter-bloc-pattern-exam... [1]: https://www.flutterclutter.dev/flutter/basics/what-is-the-bloc-pattern/2021/2084/ https://www.flutterclutter.dev/flutter/basics/what-is-the-bl... [2]: https://www.youtube.com/watch?v=yr8F2S3Amas&list=PLOU2XLYxmsIK0r_D-zWcmJ1plIcDNnRkK https://www.youtube.com/watch?v=yr8F2S3Amas&list=PLOU2XLYxms...
  - 4y ago

kennytilton 4y ago

I think you have made the case for ClojureDart. Clojure does not do the Typescript strong typing thing, but it meets the "Not Dart" requirement pretty well. And my specific contrib, Matrix, handles state management and the whole reactive thing pretty well, one area where I see a bit of thrashing in the Flutter community. Check out the examples and esp. the TodoMVC demo, they cover quite a bit of ground.

satvikpendem 4y ago

Dart is at least adding new features relatively quickly (just recently they started working on immutable record data structures with pattern matching, which even TypeScript doesn't have yet) and soon they'll have static metaprogramming meaning you can have Lisp like macros to create your own syntax, including algebraic data types as in any functional language. That is really what people are looking forward to. Another thing is Dart is JITed, AOT compiled as well as compiling to JS and WASM. Very few languages can do all 4. JVM ones can't, so no Kotlin (we'll see how well Kotlin Native works), and V8 isn't AOT so no JS or TS either. Only alternative I can think of is Lua.

kaba0 4y ago
It is easy to iterate fast on language design when you don’t care about backwards compatibility. > Very few languages can do all 4. JVM ones can't Java can (JIT is trivial, for AOT there is among others Graal, for JS and WASM there is TeaVM (which works on class files, so now that I think about it, pretty much every JVM language can do all platforms), but also the very great Closure compiler (j2cl) which has no relation to cloJure, made and used heavily by google)
- satvikpendem 4y ago
  Backwards compatibility is overrated, sticking to it too hard is how we get stuff like JS or C++ that have ten different ways of doing the same thing. I'd much rather a language be improved and break sometimes than to convolve around keeping strict BC. Anyway, they have good BC support since Dart 2 released several years ago so I'm not worried. With your Java example, that's exactly what I mean, you don't need 4 different tools in Dart to achieve the 4 types of compilation, they're all included in the standard Dart compiler/SDK. Sure, if we go by your definition, probably any language has some level of support for each via various random compilers but I'm talking about something first-class, built-in.
  - kaba0 4y ago
    > Backwards compatibility is overrated, sticking to it too hard While there is surely a very delicate balance of slowly deprecating a few things, remember that the only significant productivity booster is relying on existing code (as per Brooks). I’m fairly sure there are orders of magnitude more Java code transpiled to JS running at Google than all of their Dart codebases combined, so not sure “random compilers” are a fair description.

moonchrome 4y ago

I can confirm the experience and I've used dart on multi month projects twice now : first time when it was the JS replacement and using AngularDart back in the angular 2 beta days - it was ahead of the curve at the time with tooling (compared to JS world), but it went nowhere because of poor design choices. Then they decided to salvage the team and made flutter with it - the technical reasons of chosing it over JS sound extremely unconvincing. And the language is as you say the worst of both worlds - verbose and weak type system (I remember getting runtime type exceptions because compiler couldn't catch a type mismatch in a ternary) and none of JS dynamism, no reflection - just boilerplate on top of boilerplate. Worst part is the react like architecture of flutter lends itself really well to immutable state management practices but the language is so weak that any immutable library involves a ton of ugly boilerplate - and they refuse to add stuff like records to the language to ameliorate the problem. The reason it gets me so riled up to rant is that the framework itself and the idea behind it (custom native rendering framework) has potential - but dart makes using it horrible.

hardwaresofton 4y ago
Oh this totally reminds me of the BLoC pattern[0][1] that everyone kind of... really gritted their teeth through. It just wasn't at all an appealing way to structure data flow and I was kind of surprised that it was the architectural choice that was being pushed. 90% of the time, it felt like simple IoC plus an app-wide singletons would have been enough for most apps-- trying to get everyone to aadopt BLoC was painful and kinda meh. It's probably just that I never developed a sufficiently big app at scale with lots of devs to see why BLoC was the best way. That said, I'm also reminded of the Boring Flutter Development Show[2], quite possibly the best produced resource I've ever seen as an intro and ongoing guide to a piece of tech. It is excellent. [0]: https://www.dbestech.com/tutorials/flutter-bloc-pattern-examples https://www.dbestech.com/tutorials/flutter-bloc-pattern-exam... [1]: https://www.flutterclutter.dev/flutter/basics/what-is-the-bloc-pattern/2021/2084/ https://www.flutterclutter.dev/flutter/basics/what-is-the-bl... [2]: https://www.youtube.com/watch?v=yr8F2S3Amas&list=PLOU2XLYxmsIK0r_D-zWcmJ1plIcDNnRkK https://www.youtube.com/watch?v=yr8F2S3Amas&list=PLOU2XLYxms...
- 4y ago