`haskell-distributed` is awesome, but the reason Unison is a new language is exactly to avoid the limitations of such frameworks, namely that they _can't_ send arbitrary code and data around like Unison can.
You should totally write up a tutorial demoing the development of the same application using each. Folks would love that.
> but the reason Unison is a new language is exactly to avoid the limitations of such frameworks
by introducing another set of limitations that Unison docs don't state upfront, because it will affect their progression as the business.
> namely that they _can't_ send arbitrary code and data around like Unison can.
> You should totally write up a tutorial demoing the development of the same application using each. Folks would love that.
You should add "out of the box", and that "like Unison can" isn't the only way to implement a distributed runtime. This leads to another logical question: why should I "totally write up" the Unison way of things? At this point I'm not even sure that 99.999% of workloads need distributed runtimes of any kind, let alone the Unison one.
There's an algorithm for it. The thing that actually gets assigned a hash IS a mutually recursive cycle of functions. Most cycles are size 1 in practice, but some are 2+ like in your question, and that's also fine.
Does that algorithm detects arbitrary subgraphs with a cyclic component, or just regular cycles? (Not that it would matter in practice, I don't think many people write convoluted mutually recursive mess because it would be a maintenance nightmare, just curious on the algorithmic side of things).
I don’t totally understand the question (what’s a regular cycle?), but the only sort of cycle that matters is a strongly connected component (SCC) in the dependency graph, and these are what get hashed as a single unit. Each distinct element within the component gets a subindex identifier. It does the thing you would want :)
That depends. What are you wanting to accomplish more broadly with the integration?
I'll mention a couple things that might be relevant - you could have the git repo reference a branch or an immutable namespace hash on Unison Share. And as part of your git repo's CI, pull the Unison code and compile and/or deploy it or whatever you need to do.
There's support for webhooks on Unison Share as well, so you can do things like "open a PR to bump the dependency on the git repo whenever a new commit is pushed to branch XYZ on Unison Share".
Basically, with webhooks on GH and/or Unison Share and a bit of scripting you can set up whatever workflow you want.
Feel free to come by the Discord https://unison-lang.org/discord if you're wanting to try out Unison but not sure how best to integrate with an existing git repo.
It's open source, you can create a free account with GitHub OAuth, and you can push projects there and collaborate on them, open PRs, publish releases, etc. It's very quick to pick up if you're already familiar with GitHub.
> There aren’t enough swear words in the English language to adequately describe how frustrating computers and programming can be, but we have at least always been able to count on them for precision: to perform exactly as instructed through programming.
This is so true. That feeling when you're debugging an issue in your code, only to rule out all the possibilities and have to expand your search to include not-your-code: the tooling, the libraries, the operating system, the hardware. This is the worst feeling in debugging, when the problem and the solution /might/ be outside of your control. With LLM/GenAI, the primary problem solving surface is nondeterministic by design, very much out of your control, and you will likely be gaslit into believing that you're just not hitting it right. Like a tube tv that has to be slapped just the right way to restore proper reception. (Sorry, bots, no offense intended.)
> What’s next, TPS reports?
I bet LLMs are really good at producing TPS reports w/ cover sheet.
You should totally write up a tutorial demoing the development of the same application using each. Folks would love that.