Well there's that, but honestly... exploratory programming with a tool that can't provide basic functionality will limit how much you can explore. I think you mean 'language design exploration'? - if so I'll stop right there, since, well, frankly... it's not my wheelhouse. :)
> package integration first is putting the cart before the horse
I'm simply saying that features like db integration bring users, users bring manpower, manpower will provide package management in a way that ensures it accounts for more use cases, but again this is moot if what you're interested in is only the language development arena. Though I'm not sure how you could prove out a language unless you can actually use it for real world work.
P.S. If you want users, then killer feature would = todo list mobile app with local db in 30 lines of code!
> exploratory programming with a tool that can't provide basic functionality will limit how much you can explore
Absolutely true, which is why I do think the Racket integration is important, so we can just wrap its many and powerful libraries in lighter-weight arc libs, and also why I think a decent package system is important. It needs to be easy to share code, and to find solutions to problems. Otherwise everyone spends too much time rebuilding the same wheels.
> features like db integration bring users
Absolutely. I think better db support in arc would be awesome to have. Especially if we can build an ecosystem where "intelligent defaults" are the norm, so that 90% of the time the exploratory developer can get a db up and running with 1-2 lines.
> todo list mobile app with local db in 30 lines of code
An admirable goal. That's actually a great idea of something we could work toward as a community project, each building pieces that eventually come together to make a decent modern app.
> Were you thinking a mobile friendly web app, or trying to run it natively on a phone?
The java/js ecosystem has the largest reach making it the easy choice. One could work on a js compiler and target pouchDB as a starting point. That said choosing js also makes Arc go further down the path Clojure has already gone putting the two closer together, and with Clojure being so far ahead in that arena then maybe it's doomed to fail. The other way to go is to do what Clojure is not great at. iOS development? maybe integration with swift? At any rate I'm not a language development guy. I can only tell you what would appeal to me. I mostly use Clojure and a really easy to use arc->iOS app development ecosystem would be really cool.