4 ms·

> not usable in any other context I'm using Dart for the web and on server side. Really loving the language. > seems like Google is foisting this on us arbitr

> not usable in any other context I'm using Dart for the web and on server side. Really loving the language. > seems like Google is foisting this on us arbitrarily It's been in the works for at least 2 years now. > There better be something special about Dart A good article on why Dart's a good fit for Flutter: https://hackernoon.com/why-flutter-uses-dart-dd635a054ebf https://hackernoon.com/why-flutter-uses-dart-dd635a054ebf > no-community language I think there's room to critique Dart with regard to how it's very much Google-driven vs community-driven. They mostly make decisions based on Google's internal customers. That's a problem if it wants to grow.

riku_iki 9y ago
> I think there's room to critique Dart with regard to how it's very much Google-driven vs community-driven. They mostly make decisions based on Google's internal customers. That's a problem if it wants to grow. From another hand you have language driven by needs of mature and complex products/company/engineers, and not by random people who decided to use dart today for some hobby project or soon-to-die startup, and then will switch to another hotness next month.
munificent 9y ago
> I think there's room to critique Dart with regard to how it's very much Google-driven vs community-driven. They mostly make decisions based on Google's internal customers. That's a problem if it wants to grow. I'm on the Dart team, and I agree. We have been pretty internally-focused the past year or two. As someone who cares a lot about open source, that makes me kind of sad. But, also, the reality is we had pretty good internal adoption and not great external adoption. If we're going to get to a million happy users someday, we need to first have thousands of really happy users — we need to fit our product really well to a customer base and then grow from there. If you look around, you'll notice that almost all successful open source projects start with a pretty solid base — often developed entirely privately inside an organization — before they grow to a larger ecosystem. Our internal users have been a great set of users to focus on for a while. They give us great feedback, have very large projects to work on, and, well, they pay the bills. I also think almost everything they deal with is relevant to external users too. (Except for some minor stuff around build systems and versioning where Google's monorepo system is quite different from the outside world.) I believe by working to make our internal users really happy, we've focused Dart into a product that will ultimately be much better for external users too. If you were to see the stuff they complained about and that we fixed, odds are you'd be right on board with them. Years ago, I felt like Dart was trying to be all things to all people with not enough coherent focus. The past couple of years (and some org changes) have helped improve that, I believe. Once Dart 2.0 is out the door, my hope is that we'll get back to working like a normal visible open source project. But we need to have a solid foundation we can build on before that makes sense. Communities are great for incrementally evolving a project, but not as much for answering fundamental existential questions about what the project is, like "Are types good?"
- wokwokwok 9y ago
  I hear what you're saying, and it's true to some extent with projects, like say, opencv. > Communities are great for incrementally evolving a project, but not as much for answering fundamental existential questions about what the project is, like "Are types good?" However, kotlin, rust and go all offer counter points to your argument with regard to languages. That simply isn't the case; the community is full of people who have things to say about this... if you're prepared to listen. ...this just sounds like an excuse to avoid engaging with the community, and a flip off to the very smart people out there who have meaningful things to say about this stuff. > The past couple of years (and some org changes) have helped improve that, I believe. Well, if it has, you have some serious work to do to communicate that to community, because it doesn't feel like it to me. This kind of comment from the Dart team (aka. community has nothing to offer us) is extremely irritating, and just makes me, personally, not want to even bother to try what you've built.
  - munificent 9y ago
    > However, kotlin, rust and go all offer counter points to your argument with regard to languages. I don't think that's true. Kotlin was pretty well baked when first publicly launched. Most of the syntax, semantics, non-nullable types, etc. was all there on day one. There have been lots of changes since then, of course, but Kotlin is still roughly the same language it was before. It's not like it's turned into a Lisp or something. Rust has made more significant changes since they launched, but most of the foundational questions have the same answers that they did on day one: maximize safety and performance and be willing to accept complexity and strict compile errors to get it. > This kind of comment from the Dart team (aka. community has nothing to offer us) I'm sorry, but I think that's a very uncharitable reading of what I wrote.

riku_iki 9y ago

> I think there's room to critique Dart with regard to how it's very much Google-driven vs community-driven. They mostly make decisions based on Google's internal customers. That's a problem if it wants to grow. From another hand you have language driven by needs of mature and complex products/company/engineers, and not by random people who decided to use dart today for some hobby project or soon-to-die startup, and then will switch to another hotness next month.

munificent 9y ago

> I think there's room to critique Dart with regard to how it's very much Google-driven vs community-driven. They mostly make decisions based on Google's internal customers. That's a problem if it wants to grow. I'm on the Dart team, and I agree. We have been pretty internally-focused the past year or two. As someone who cares a lot about open source, that makes me kind of sad. But, also, the reality is we had pretty good internal adoption and not great external adoption. If we're going to get to a million happy users someday, we need to first have thousands of really happy users — we need to fit our product really well to a customer base and then grow from there. If you look around, you'll notice that almost all successful open source projects start with a pretty solid base — often developed entirely privately inside an organization — before they grow to a larger ecosystem. Our internal users have been a great set of users to focus on for a while. They give us great feedback, have very large projects to work on, and, well, they pay the bills. I also think almost everything they deal with is relevant to external users too. (Except for some minor stuff around build systems and versioning where Google's monorepo system is quite different from the outside world.) I believe by working to make our internal users really happy, we've focused Dart into a product that will ultimately be much better for external users too. If you were to see the stuff they complained about and that we fixed, odds are you'd be right on board with them. Years ago, I felt like Dart was trying to be all things to all people with not enough coherent focus. The past couple of years (and some org changes) have helped improve that, I believe. Once Dart 2.0 is out the door, my hope is that we'll get back to working like a normal visible open source project. But we need to have a solid foundation we can build on before that makes sense. Communities are great for incrementally evolving a project, but not as much for answering fundamental existential questions about what the project is, like "Are types good?"

wokwokwok 9y ago
I hear what you're saying, and it's true to some extent with projects, like say, opencv. > Communities are great for incrementally evolving a project, but not as much for answering fundamental existential questions about what the project is, like "Are types good?" However, kotlin, rust and go all offer counter points to your argument with regard to languages. That simply isn't the case; the community is full of people who have things to say about this... if you're prepared to listen. ...this just sounds like an excuse to avoid engaging with the community, and a flip off to the very smart people out there who have meaningful things to say about this stuff. > The past couple of years (and some org changes) have helped improve that, I believe. Well, if it has, you have some serious work to do to communicate that to community, because it doesn't feel like it to me. This kind of comment from the Dart team (aka. community has nothing to offer us) is extremely irritating, and just makes me, personally, not want to even bother to try what you've built.
- munificent 9y ago
  > However, kotlin, rust and go all offer counter points to your argument with regard to languages. I don't think that's true. Kotlin was pretty well baked when first publicly launched. Most of the syntax, semantics, non-nullable types, etc. was all there on day one. There have been lots of changes since then, of course, but Kotlin is still roughly the same language it was before. It's not like it's turned into a Lisp or something. Rust has made more significant changes since they launched, but most of the foundational questions have the same answers that they did on day one: maximize safety and performance and be willing to accept complexity and strict compile errors to get it. > This kind of comment from the Dart team (aka. community has nothing to offer us) I'm sorry, but I think that's a very uncharitable reading of what I wrote.