I work on Dart, and I'm glad you like it. I always like getting feedback from users. If there was something you could change about Dart, what would you pick? What would you keep just as it is?
i will start by saying i love dart. i learned it solely so i could make flutter apps. but now, three or four years later, i can say for certain that i love dart a lot more than i love flutter, which i have mixed feelings about.
i've learned at least a half a dozen languages over the years, and dart is now my favorite. so much so that i am converting existing projects to it. for example, i have a series of scripts i wrote, in python, to automate away the boring parts of my job, which i am now converting to dart. at this point, for me, trying to get anything done in python is like wading through molasses. (like, why does almost any change to a python implementation file cause you to also have to revisit the imports section? ugh, i hate that so much.)
my number one change would be to add configuration options to the formatting tool you wrote. i can see why consistency is a virtue for large projects, but for me, it is strictly a hindrance. programming is thinking, and i really don't like you dictating the way i ought to think. (yeah, i know you won't do it, but that's my big one.)
my second big change would be to allow me to implement a big dart class in two or more implementation files. the business logic in the flagship flutter app i maintain is getting unbelievably complicated, and large chunks of it cannot be moved out of the one object it is in, due to inheritance reasons.
> my number one change would be to add configuration options to the formatting tool you wrote. i can see why consistency is a virtue for large projects, but for me, it is strictly a hindrance.
Yeah, I get that. In personal projects, there's something to be said for just Having It Your Way. But the formatter is focused on ecosystem level improvements where configurability is an anti-feature.
> my second big change would be to allow me to implement a big dart class in two or more implementation files.
You can sometimes accomplish that by moving chunks of methods out into seperate mixins and mixing them into your class. I think mixins are generally underused in Dart. But if that doesn't work, the proposal for augmentation libraries would probably help:
the syntax is similar to C/java/C++ so the out-of-box experience was great, please keep it. I do hope there is a `dart build`(similar to `dart run`) to run pub-get-then-compile-exe as that's what Go and rust have, it's nothing major, just handy.
I use dart for scripting as well, which works really well.
For deployment I wonder if Dart can be made a little like Go (or C/C++): to build into a single static executable instead of depending on system C shared libraries.
I gave up on Go and embraced Dart, so the `dart build` and `static binary` are kind of what I missed from Golang when started with Dart.
> I do hope there is a `dart build`(similar to `dart run`) to run pub-get-then-compile-exe as that's what Go and rust have, it's nothing major, just handy.
It's "dart compile":
$ dart compile --help
Compile Dart to various formats.
Usage: dart compile <subcommand> [arguments]
-h, --help Print this usage information.
Available subcommands:
aot-snapshot Compile Dart to an AOT snapshot.
exe Compile Dart to a self-contained executable.
jit-snapshot Compile Dart to a JIT snapshot.
js Compile Dart to JavaScript.
kernel Compile Dart to a kernel snapshot.
not really, dart-compile does not do pub-get automatically, while dart-run does. dart-build is basically a (pub-get + dart-compile) to be "consistent" with other modern languages such as 'cargo build' or 'go build'
