Unison: A Friendly Programming Language from the Future Part 1
summary
Unison stores every definition as a cryptographic hash so code becomes a content-addressed immutable data structure where names are just annotations, documentation and examples live as executable, cached definitions, and the CLI codebase manager can list dependents, types and run cached evaluations. Builds disappear because references use hashes, so tests and typechecks run once per hash and need not be repeated. Dependency conflicts convert to ordinary type errors. Language and IDE remain alpha but the prototype tooling already works end to end.
AI-written summary · about
chapters (7)
- 0:00Introduction
- 1:21What is Unison?
- 7:37Code is content-addressed
- 9:19The codebase is an immutable data structure
- 12:23Names don't matter
- 14:31No builds
- 16:55No dependency conflicts
related talks
41mIntroduction to the Unison programming language
32mUnison, and why the codebase of the future is a purely functional...
20mInteractive Haskell Type Inference Exploration (Extended Abstract)
42mMonoidal Parsing
56mFunctional Programming on .NET - The Best of Both Worlds
32mFunctional Programming with Serialized Data
46mSimple Functional Effects with Tag Unions
58mKeynote: Why Functional Programming Matters