101–110 of 158 posts
Edit: Shorter: do you have type classes
I know there's only so many names in the world but this is going to completely ruin searches for the Unison file synchronizer: https://github.com/bcpierce00/unison
Unison looks like a neat functional language. Do abilities subsume the role of type classes also (without any "effects")? If so, would there be a loss of efficiency for using pure abilities in this way (since a "handler" needs to interpret the ops)? Sorry I've only had a brief look so I'm not sure this makes sense. Edit: Shorter: do you have type classes
(In a less jokey way: Abilities should be thought of as capabilities, and capabilities are what enable you to do I/O, read from a DB, etc. So they are 'effects' in the Pure FP sense.)
Not sure about the type classes thing.
It looks like to use this product, I have to learn an entirely new programming language (which appears to be a weird mashup of Python and Haskell), a whole set of entirely new API's, I can only host my stuff on their for-pay cloud infrastructure, and I can't use source control? That's a lot of very high hurdles to clear. Even if this magically solved all my scaling and distributed system problems forever, I'm not sur…
It is very experimental as well. An interesting language, but say good by to tried and true tooling since the code exists as records in database, not files. This could lead some huge advantages, and new obstacles. I played with the language for about a week and found it intriguing. And it seems to approach tackling Joe Armstrong's question "Why do we need modules at all?" -> https://erlang.org/pipermail/erlang-questi…
Earlier quoted context omitted.
It definitely is ambitious! A multi-year effort. This post https://www.unison.cloud/our-approach/ talks more about why such radical changes were necessary to achieve what we wanted. (In particular check out the "3 requirements of the dream" section, which walks through what the programming language needs to support to be able to do things like "deploy with a function call.") My general take on "when and where to inno…
Not trying to pour cold water, but the "3 requirements" post seems to address straw man problems. There are existing solutions to each problem. 1. "Deployment should be like calling a function" isn't that the mantra of serverless? e.g. GCP Cloud Run or AWS Lambda? This is also becoming much more streamlined with server-side WASM e.g. wasmCloud. 2. "Calling services should be easy" this is what protobuf is for; cross-…
Unison looks like a neat functional language. Do abilities subsume the role of type classes also (without any "effects")? If so, would there be a loss of efficiency for using pure abilities in this way (since a "handler" needs to interpret the ops)? Sorry I've only had a brief look so I'm not sure this makes sense. Edit: Shorter: do you have type classes
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.
Unison looks like a neat functional language. Do abilities subsume the role of type classes also (without any "effects")? If so, would there be a loss of efficiency for using pure abilities in this way (since a "handler" needs to interpret the ops)? Sorry I've only had a brief look so I'm not sure this makes sense. Edit: Shorter: do you have type classes
Earlier quoted context omitted.
At the point when you've written a term which is incidentally equivalent to another, the Unison codebase manager tool tells you that you're adding a term that is identical and lists its name. You can still technically perform the addition if you really want at that point, but most folks don't want two aliases for the same function floating around. If you do end up adding it, updating A would also update B. Think of t…
Is the term merely the hash of its contents, or does it also include the module space? If it's just the hash of its contents, how do you deal with functions which have the same implementation now but shouldn't always - e. g.: serviceA.requiredHeaders key = Dictionary.of "X-API-KEY" key serviceB.apiKeyHeader apiKey = Dictionary.of "X-API-KEY" apiKey If they hash to the same thing and I update `serviceA.requiredHeaders…
type UserName = UserName Text type Password = Password Text
since the entire point in introducing types here is to actually declare them as different from one another.
But for other it might actually be beneficial to recognize that they are the same type, for example:
type Optional a = None | Some a type Maybe a = Nothing | Just a
To allow for both, you can prefix type with either "structural" or "unique" depending on what behavior you want (unique is the default). We have tossed around the idea of also introducing unique terms which would let you terms like yours as unique terms that should be salted, and let the current behavior of "structural"? terms be the default. The reality is that this hasn't been such a big problem that it has made it to the top of our list yet ;)
It looks like to use this product, I have to learn an entirely new programming language (which appears to be a weird mashup of Python and Haskell), a whole set of entirely new API's, I can only host my stuff on their for-pay cloud infrastructure, and I can't use source control? That's a lot of very high hurdles to clear. Even if this magically solved all my scaling and distributed system problems forever, I'm not sur…
It definitely is ambitious! A multi-year effort. This post https://www.unison.cloud/our-approach/ talks more about why such radical changes were necessary to achieve what we wanted. (In particular check out the "3 requirements of the dream" section, which walks through what the programming language needs to support to be able to do things like "deploy with a function call.") My general take on "when and where to inno…
So… ccache?
I feel like my alter ego wrote this same comment a year ago, but if there's any Nix users that are also Unison users, I'd love to hear your thoughts. This feels like some of the tough-but-oh-so-good nature of Nix, applied to general programming. But I haven't had a chance to try Unison much.
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/ https://github.com/ceedubs/unison-nix-snake/