Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Meta-issue for upcoming work #101
Project has so far been focused on building proof-of-concepts, design exploration, and research. There's still some of that to do, but generally, would like to move focus to engineering work to get the language/libraries/runtime of Unison in a usable state for 'real' stuff. This will let us see how well the ideas that have been developed work at scale.
Milestone is having implementation in good enough shape that you could write some highly-available service for your backend in pure Unison. And if you didn't mind being on bleeding edge, this might even be something you put in production, or at least use internally.
Motivating use cases
Very high level plan:
More detailed plan
Things for the language and editor to address after that:
At this point, we now have a nice interface to a Unison codebase, a nice parser, and data types. We can add more stuff to the standard library, perhaps #114 (nontrivial distributed libraries), but there are lots of basic utilities to fill in ('obvious' stuff we take for granted from Haskell's standard libraries).
Now we have pretty much all the ingredients to try writing some seriously nontrivial stuff. We have a nice editing and refactoring tool, a standard library, the ability to define new data types, and a runtime that isn't completely terrible. So we can start writing Unison code for some of these nontrivial use cases I gave above, like the Twitter backend, the YouTube backend, etc. How awesome will that be?? :)
Upcoming design work:
Hi @pchiusano, I'm glad you didn't give up year ago with this effort. I'm already following Unison from the very beginning and I'm a huge fan of it. Thank you!
Based on your talk at Full Stack Fest 2016 and your recent switch from research & architecturing to "the boring stuff" (engineering internal, increasing efficiency, etc.), I'd like to raise few questions to get a good overview of your plans. I'm asking in this thread to not pollute the GitHub Issues page.
Btw I'm participating in the development of Dao (programming language using many functional-programming-like ideas enacted in the internals and abstractions offered to the programmer) and I'd like to mimic the interfaces you came up with for Unison in Dao (we have quite good tools for that - e.g. code sections, concrete interfaces, futures, defer, etc.). Dao is though written in C for portability and embeddability reasons. Dao is also very tiny, but has a comprehensive and pretty well-designed (compared to the current "crippled" non-Haskell world
Hey @dumblob sorry this has been on my todo list for a while...
Re 1) and 2) basically, I am not considering it top priority right now to have Unison be this minimal executable that people could literally run on a toaster oven. It's something I'm keeping in mind and would be a nice to have, but it's a big engineering constraint that I'm not trying for right now. The way I'd manage a fleet of IoT devices is not by having Unison literally running on the devices, but by having a Unison node on your network with some capabilities that let it talk to those IoT devices, which can speak whatever protocol (hopefully some widespread standard will emerge for this). So like, your house has a bunch of smart devices, and you have a Unison node on your local network that has access to those devices, and you can write Unison programs that orchestrate the actions of those devices. (I'm ignoring the potentially scary implications of having hardware that can be controlled by possibly buggy software, but this is basic idea...)
So with that as the model, optimizing for space usage and executable size is much less of a concern.
Re: 3) general goal is just to have performant, durable, typed state available to Unison programs and move away from people needing to do explicit serialization to/from the file system, database, whatever. There are some API questions around this that we'll probably continue to play with and iterate on. Not sure that answers your question.
Particular performance use cases like 4) I'm not too focused on right now. It's more important to me to just have reasonable performance for general purpose computation. When that's done, we can go from there. Particular use cases are in the back of my mind and we can improve on things iteratively - Unison's runtime can be made screaming fast, just like any other language. But I think it will be a while before Unison gets used for like HFT. :)