unison-nix
unison
unison-nix | unison | |
---|---|---|
1 | 17 | |
48 | 5,564 | |
- | 1.0% | |
7.1 | 9.9 | |
6 days ago | 5 days ago | |
Nix | Haskell | |
MIT License | GNU General Public License v3.0 or later |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
unison-nix
-
Unison Cloud
I use both Unison and Nix (and I work on Unison Cloud).
The "oh-so-good" aspect that comes from content-addressed dependencies is definitely there. I've spent a lot of time debugging runtime issues on the JVM because two libraries that I depend on disagree on what version of a common dependency should be on my classpath. This is not something you ever experience with Unison. In the runtime every term and type are identified by their hashes, so there's no (realistic) way that names can collide.
Otherwise, Unison and Nix feel pretty different to me. Nix is generally a build-time language for arbitrary runtimes, while Unison is a general purpose language for a specific runtime.
Nix takes on the really ambitious goal of wrangling ancient projects built with Makefiles and ambient environments into deterministic builds. Through the heroic effort of derivation authors, they've managed to make it work. But it requires those maintainers to do lots of careful manual tracking of dependencies, pre-build source patches, overriding build steps, etc.
Unison takes a much more constrained approach: if we start with a language that is content-addressed at its core and keep running with this idea, where do we end up? One nice outcome of this is that you never need to manually track dependency versions, hashes, etc; the language does that for you.
The "tough" part is also there, but feels different. To me the Nix expression language is straightforward, but I find it difficult to wrap my head around nontrivial derivations. To answer questions like "what attributes and build steps can/should I override" I feel like I have to dig through the layers of the implementation. In Unison a powerful static type system and UIs (both local and Unison Share) that support clicking through to any term/type make it easier for me to digest code. The "tough" parts of Unison generally stem from the young ecosystem: fewer existing libraries, a codebase manager that is under active development and not nearly as stable as git, etc.
If nothing else Unison is worth a try just because it is so different than most other languages/ecosystems.
PS if you are interested in usin Nix to install the Unison codebase manager or to package a program written in Unison these repos might be useful (disclaimer I'm ceedubs):
https://github.com/ceedubs/unison-nix/
unison
- Unison Programming Language
-
Unison Cloud
Short version: no type classes (yet)
Longer version:
Building upon what Quekid5 mentioned, Unison abilities are an implementation of what is referred to as algebraic effects in programming language literature. They represent capabilities like IO, state, exceptions, etc. They aren't really a replacement for type classes, though in some cases you can shoehorn abilities in where you might otherwise use a type class.
For someone coming from a Haskell background, I think that abilities are closer to a replacement for monad transformers. But in my opinion they are much more ergonomic.
Discusson of type classes comes up a lot. Here is a long-standing GitHub issue: https://github.com/unisonweb/unison/issues/502
For what it's worth, I've written Unison quite a lot over the past few years and while I've missed type classes at times, I think that reading unfamiliar code is easier without them. There's no implicit magic; you can see exactly what is being passed into a function. So far I've been happy with a bit more verbosity for the sake of readability.
-
Show HN: Winglang – a new Cloud-Oriented programming language
I've been following the Unison lang [1] for quite some. Wing seem to set similar goals? From the first glance Wing looks more polished, but there's "The Big Idea" behind Unison - is there something similar?
[1]: https://github.com/unisonweb/unison
- Unison Language
-
C++ evolution vs C++ successor languages. Circle's feature pragmas let you select your own "evolver language."
in haskell it looks like this, you specify the language extensions you want at the top of the source files: https://github.com/unisonweb/unison/blob/trunk/unison-core/src/Unison/ABT.hs
-
Looking for a new language to learn for Advent of Code that's unlike anything you've tried before? Check out Unison!
they adjusted my ticket to be a bug fix on their part.
-
Syntax Design
I think Unison is going in this direction. Imo this is a mistake, as a program language functions not just as specification for the machine, but also as communication between programmers. Allowing the introduction of arbitrary dialects to suit individual preferences seems like it would interfere with that communication.
- Unison
- Unison Milestone 3
- What if Git worked with Programming Languages?
What are some alternatives?
nvim-treesitter-context - Show code context
dark - Darklang main repo, including language, backend, and infra
project-m36 - Project: M36 Relational Algebra Engine
cone - Cone Programming Language
nbdime - Tools for diffing and merging of Jupyter notebooks.
structured-haskell-mode - Structured editing minor mode for Haskell in Emacs
UwUpp - The next generation esoteric language
structured-haskell-m
syntactic_versioning - What if Git worked with Programming Languages?
lawvere - A categorical programming language with effects
git-merge-driver - Example of how to configure a custom git merge driver
diffsitter - A tree-sitter based AST difftool to get meaningful semantic diffs