5 ms·

The author is one of the lead developers for Dart, which has evolved over time into a pretty nice language.

throwaway032023 2y ago
I think Dart is underappreciated. Almost the entire compiler is written in Dart. It has a VM, AOT compiler, FFI/Native, and first class Javascript interop with ability to compile to javascript. It has first class WASM support. Null sound safety. They have experimental support for macros. Pretty impressive.
- cageface 2y ago
  I completely agree. I was lukewarm on Dart but decided to do my new app in Flutter and it's turned out to be a great experience. Kotlin and Swift may look better on paper but Dart is very productive. The tooling is really solid and the fast compile times and hot reload really help for rapid iteration. I've also had no performance issues.
munificent 2y ago
I should clarify that I've been an engineer on the Dart team for a long time, but I wasn't one of the original designers of the language. (If I had been, the language would be pretty different.) I am on the language team now, but I'm just one of the team members and not a lead. The Dart team is really fantastic. Every day I'm grateful I get to work with such a good group of people.
- cageface 2y ago
  Thanks to you and the rest of the team for all your great work! It really is a very nice language. I've been working almost exclusively in Dart for the last 6 months and it really is a very pragmatic and productive language. I'm looking forward to macros and more fully featured record types.
- tashmahalic 2y ago
  How might Dart be different if you were an original designer?
  - munificent 2y ago
    It's hard to separate out what I know now that neither I nor the initial designers knew back then from what I thought we should have done even then. For example, optional types ended up not working out, but I don't think I knew that then either. But even before we released, I did tell the language team that I thought it would be good to do: * Non-nullable types. We got there eventually with a ton of engineering effort and migration cost, but this could have been a really strong selling point at launch. * Types on the right. Think `var x: int` instead of `int x`. It's a little more verbose in some cases, but it makes the language easier to parse and makes it easier to have complex syntax for type annotations like function types, union types, etc. * Extension members. We added them years later, which is good, but was too late to affect the design of the core libraries. I suggested that it we had them in 1.0, then the core libraries and collection types could be designed around them. * `val` instead of `final` for single-assignment variables. It's a small thing, but it means that the syntax for single-assignment variables isn't longer then mutable ones, which is good because it doesn't punish users for doing the "right" thing. * No semicolons. Again, another small thing, but it does help the language feel cleaner and more modern. It's really hard to do this later when the syntax wasn't designed for it. * Coroutines instead of futures and async/await. Coroutines are definitely hard to compile to JS, so there is a good argument that I'm just wrong. But I really hate what async does to API design (https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/ https://journal.stuffwithstuff.com/2015/02/01/what-color-is-...).
    - cageface 2y ago
      That’s very close to my list. It’s only a few characters but “final” takes up too much space. And I agree types on the right are easier to read. Other than that I’m mainly looking for the reasons code generation is required today to go away.

throwaway032023 2y ago

I think Dart is underappreciated. Almost the entire compiler is written in Dart. It has a VM, AOT compiler, FFI/Native, and first class Javascript interop with ability to compile to javascript. It has first class WASM support. Null sound safety. They have experimental support for macros. Pretty impressive.

cageface 2y ago
I completely agree. I was lukewarm on Dart but decided to do my new app in Flutter and it's turned out to be a great experience. Kotlin and Swift may look better on paper but Dart is very productive. The tooling is really solid and the fast compile times and hot reload really help for rapid iteration. I've also had no performance issues.

munificent 2y ago

I should clarify that I've been an engineer on the Dart team for a long time, but I wasn't one of the original designers of the language. (If I had been, the language would be pretty different.) I am on the language team now, but I'm just one of the team members and not a lead. The Dart team is really fantastic. Every day I'm grateful I get to work with such a good group of people.

cageface 2y ago
Thanks to you and the rest of the team for all your great work! It really is a very nice language. I've been working almost exclusively in Dart for the last 6 months and it really is a very pragmatic and productive language. I'm looking forward to macros and more fully featured record types.
tashmahalic 2y ago
How might Dart be different if you were an original designer?
- munificent 2y ago
  It's hard to separate out what I know now that neither I nor the initial designers knew back then from what I thought we should have done even then. For example, optional types ended up not working out, but I don't think I knew that then either. But even before we released, I did tell the language team that I thought it would be good to do: * Non-nullable types. We got there eventually with a ton of engineering effort and migration cost, but this could have been a really strong selling point at launch. * Types on the right. Think `var x: int` instead of `int x`. It's a little more verbose in some cases, but it makes the language easier to parse and makes it easier to have complex syntax for type annotations like function types, union types, etc. * Extension members. We added them years later, which is good, but was too late to affect the design of the core libraries. I suggested that it we had them in 1.0, then the core libraries and collection types could be designed around them. * `val` instead of `final` for single-assignment variables. It's a small thing, but it means that the syntax for single-assignment variables isn't longer then mutable ones, which is good because it doesn't punish users for doing the "right" thing. * No semicolons. Again, another small thing, but it does help the language feel cleaner and more modern. It's really hard to do this later when the syntax wasn't designed for it. * Coroutines instead of futures and async/await. Coroutines are definitely hard to compile to JS, so there is a good argument that I'm just wrong. But I really hate what async does to API design (https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/ https://journal.stuffwithstuff.com/2015/02/01/what-color-is-...).
  - cageface 2y ago
    That’s very close to my list. It’s only a few characters but “final” takes up too much space. And I agree types on the right are easier to read. Other than that I’m mainly looking for the reasons code generation is required today to go away.