> even just getting a camera feed on Flutter isn't a built-in Why should it be built-in? That's such a C++ (or C) mindset: that using dependencies is bad, whic

> even just getting a camera feed on Flutter isn't a built-in Why should it be built-in? That's such a C++ (or C) mindset: that using dependencies is bad, which stems from the difficulty of adding and updating dependencies in the C++ world. In a language with a rock solid package manager, it's better to have a small core and then pull in what you need. Each of these out-of-core dependencies can have separate lifecycles, which makes it a lot easier for them to be developed and updated, making them higher quality. If breaking changes need to be made, that can easily be done in out-of-core libraries, since existing projects can continue depending on their SemVer-defined compatible version of the dependency ad infinitum, and the project maintainers can continue releasing updates to any SemVer series of the package if they need to backport changes to older versions. When something is in the core, it's very hard to update it while maintaining complete compatibility, and people can only depend on one version of your core library at a time, so there's no room to be flexible. This constricts growth, since the core needs to meet everyone's needs, but it doesn't have the flexibility to do that as the world changes, so it often meets no one's needs. I don't know how good Dart's package manager is, since I haven't really touched Dart since the very earliest days of the language after it became public, but Rust's package manager is excellent, and having most things out-of-std has been great for the community. Futures and async have flourished out-of-std and gone through several very different approaches to gain real world experience. Some very small pieces of that ecosystem will be stabilized into the core language soon, but only the most bare minimum features to add the "await" keyword to the language. As much as possible will still remain in outside libraries. In general, things go to stdlib to die.[0] The main exception I've seen with this over the years is Go, where they have done a really great job of maintaining and extending their huge batteries-included stdlib to the point that most people almost always recommend starting with the stdlib before reaching for a third-party package. [0]: http://www.leancrew.com/all-this/2012/04/where-modules-go-to-die/ http://www.leancrew.com/all-this/2012/04/where-modules-go-to...