Meta-issue for upcoming work about unison HOT 3 CLOSED

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. :)

from unison.

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.

1. Are you planning to implement some space-saving heuristics (to save memory and hard drives space) for all the caches each Unison node is using? Currently these caches have add-only semantics, but considering IoT space limits and long-running programs, some pruning based on locality, reachability and recency will be needed.
2. Will you provide a minimal (e.g. "statically" compiled executable or as small as possible Docker image) for easy deployment for testing purposes? I'm thinking about mobile devices, IoT, personal computers, etc. (this is in sharp contrast with Haskell with GBytes of runtime). I envisage something like 3 MBytes would be fine for a MVP.
3. What are the exact goals for persistence, durability and reliability of all the data (including caches) used in Unison? I've looked at #92 , but could not extract an answer for this question.
4. How performant would be treating the persistent values as samples of a signal of the same particular type? In other words, is Unison prepared for high loads when a particular value (e.g. a number) will be requested to be rewritten 10000x per second (e.g. because of voting of milions of participants in the same second, but e.g. for few days) and there will need to be guarantee, that at any time, the last value will be available to readers and at the same time that this read value was persisted.

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 😉) standard library. We suffer though from bad presentation and unfinished documentation, so don't be surprised.

from unison.

@pchiusano any insights on this?

from unison.