Misleading marketing related to builds

[anchpop]

From the frontpage:

We simplify codebase management — Unison has no builds, no dependency conflicts, and renaming things is trivial.

"Unison has no builds" is misleading because it implies that unison is doing something fancier than it's actually doing - it's just an interpreted language so of course there's no build step. "no dependency conflicts, and renaming things" are both novel unison innovations, "no builds" being put right next to them implies it's novel too.

If the goal was to have three items for aesthetic appeal, can I suggest "Unison has no dependency conflicts, renaming things is trivial, and the same test never runs twice"?

I mean, you can kind of technically argue that even interpreted languages have builds in a way that unison doesn't, since they need to convert the text into an AST (and maybe even typecheck) before executing. And for some reason almost no statically typed languages are interpreted, so it's worth mentioning somewhere. But if I were trying to communicate the most exciting features of Unison I'd pick something else

[pchiusano]

Thanks for the feedback. The website will be getting a revamp soon. I'm not totally sure where we'll end up on the marketing bullet points. :)

I would say the reason you aren't ever waiting around for Unison to "build" your code is it has an accurate, shared compilation cache which is never invalidated. We don't compile all the way to machine code (yet) but whatever checking and AOT compilation work we do per definition doesn't need repeating over and over again by every Unison user - at the moment, that's just parsing, name resolution, and typechecking that we save on. This is significant, but Unison could also cache its bytecode and eventually machine code.

If you're coming from a language which does little to no work before running the code (but like you say, all languages do SOMETHING), then I could see how this feature wouldn't seem like a big deal. If you're coming from a statically typed language where you're often waiting for the compiler, then it probably matters more.

Another way to put it is that there's usually a tradeoff to having the compiler do more work before running your code - you get some benefits but are forced to wait around a lot for the compiler to do its thing. Having this perfect, shared compilation cache means you still get those benefits but don't need to wait around for the compiler.