Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Unison 1.0

unison-lang.org

Post reply on HN
Print view View original

61–70 of 98 posts

Re: Unison 1.0

#61

Post by aryairani »

littlestymaar wrote: post #22
aryairani wrote: post #17

Earlier quoted context omitted.

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 :)

Re: Unison 1.0

#62

Post by rlmark »

jpereira wrote: post #28
pchiusano wrote: post #2

Also, hi, I'm one of the language creators, feel free to ask any questions here!

I'm curious about how the persistence primitives (OrderedTable, Table, etc) are implemented under the hood. Is it calling out to some other database service? Is it implemented in Unison itself? Seems like a really interesting composable set of primitives, together with the Database abstraction, but having a bit of a hard time wrapping my head around it!

Hey there! Apologies for not getting to you sooner. The `Table` is a storage primitive implemented on top of DynamoDB (it's a lower-level storage building block - as you've rightfully identified; these entities were made to be composable, so other storage types can be made with them). Our `OrderedTable` docs might be of interest to you: they talk about their own implementation a bit more (BTrees); and `OrderedTable` is one of our most ergonomic storage types: https://share.unison-lang.org/@unison/cloud/code/releases/23...

The Database abstraction helps scope and namespace (potentially many) tables. It is especially important in scoping transactions, since one of the things we wanted to support with our storage primitives is transactionality across multiple storage types.

Re: Unison 1.0

#63

Post by wofo »

proglangenjoyer wrote: post #27

I have been following Unison for a veeery long time. Ever since those blog posts on Paul's personal website. It has been more than 10 years already so this is a great milestone. But I am just a bit disappointed. I love programming languages. I follow every programming language, even some you probably have never heard of. I have witnessed the rise of Rust, Go, Zig and others. At the age and level of polish that Unison…

I for one am glad there is a commercial angle to the project. Done right, it means more hours could go into making things better, in a sustainable way. Also, having paying users provides a strong incentive to keep the technology grounded / practical.

Without the commercial stuff, Unison would be just another esolang to me. Now I'm probably going to play with it in upcoming side projects.

Re: Unison 1.0

#64

Post by __MatrixMan__ »

proglangenjoyer wrote: post #27

I have been following Unison for a veeery long time. Ever since those blog posts on Paul's personal website. It has been more than 10 years already so this is a great milestone. But I am just a bit disappointed. I love programming languages. I follow every programming language, even some you probably have never heard of. I have witnessed the rise of Rust, Go, Zig and others. At the age and level of polish that Unison…

Agreed. I want to build things that collaborate locally if the internet goes away. It seems like the hash-addressed function thing would be a pretty nice way to do that: no name resolution needed, just talk in terms of hashes to whoever's in range.

But all of the resources available for learning the language are funneling me towards using cloud hosted infra that won't be available if the internet goes away. For all I know there is a Unison-y way forward for my idea, but the path is obscured by a layer of marketing haze.

Re: Unison 1.0

#65

Post by rssoconnor »

pchiusano wrote: post #2

Also, hi, I'm one of the language creators, feel free to ask any questions here!

How do you deal with "branded" types, if you know what I mean.

Edit: I mean structurally identical types that are meant to be distinct. As I recall Modula 3 used a BRANDED keyword for this.

Re: Unison 1.0

#66

Post by digdugdirk »

pchiusano wrote: post #41
imiric wrote: post #37

Earlier quoted context omitted.

Yeah, the core ideas sound great, but if the only way code can be published and imported is via their cloud platform, that would be a hard pass for me. Glancing at their docs, I see mentions of Unison Share, which is also hosted on unison-lang.org. So I would appreciate this being clarified upfront in all their marketing and documentation. Ah, I do see the BYOC option you mention. It still requires a unison.cloud acc…

Unison code is published on https://share.unison-lang.org/ which is itself open source (it's a Haskell + postgres app), as is the language and its tooling. You can use Unison like any other open source general-purpose language, and many people do that. (We ourselves did this when building Unison Cloud - we wrote Unison code and deployed that within containers running in AWS.) The cloud product is totally separate and…

Is a standalone Unison Code instance something that could be deployed in a docker container for personal use?

Re: Unison 1.0

#67

Post by evntdrvn »

pchiusano wrote: post #54
drob518 wrote: post #47

So, there are a whole bunch of interesting ideas here, but… It’s a huge, all-or-nothing proposition. You have to adopt the language, the source control, and figure out the hosting of it, all at once. If you don’t like one thing in the whole stack, you’re stuck. So, I suspect all those interesting ideas will not go anywhere (at least directly; maybe they get incorporated elsewhere).

You can gradually adopt Unison, it's not all or nothing. It's true that when programming in Unison, you use Unison's tooling (which is seriously one of the best things about it), but there are lightweight ways of integrating with existing systems and services and that is definitely the intent. We ourselves make use of this sort of thing since (for instance) Unison Cloud is implemented mostly in Unison but uses Haskel…

I think that the messaging around this is going to be pretty important in heading off gut-reaction "it's all or nothing locked in to their world" first takes. It's probably attractive marketing for things to be aimed at "look how easy it easy to use our entire ecosystem", but there's a risk to that too.

Re: Unison 1.0

#68

Post by stewoconnor »

digdugdirk wrote: post #66
pchiusano wrote: post #41

Earlier quoted context omitted.

Unison code is published on https://share.unison-lang.org/ which is itself open source (it's a Haskell + postgres app), as is the language and its tooling. You can use Unison like any other open source general-purpose language, and many people do that. (We ourselves did this when building Unison Cloud - we wrote Unison code and deployed that within containers running in AWS.) The cloud product is totally separate and…

Is a standalone Unison Code instance something that could be deployed in a docker container for personal use?

https://www.unison-lang.org/docs/usage-topics/docker/

Re: Unison 1.0

#69

Post by Nathanba »

Ok I tried it out. So I run ucm.cmd and it tells me: "I created a new codebase for you at C:\Users\myuser" but there is nothing there except a .unison folder. I didn't look too closely at first but maybe this all works by storing the code in the sqlite file inside that folder? Dot folders aren't usually relevant for project files. Because then even after the cli had me create a new project called happy-porcupine which is pretty unique on my computer I can't find any file or folder anywhere with that name on my machine. So then the getting started guide for unison tells me to create a scratch.u file and put the hello world instructions in there. But where am I supposed to put that scratch.u file? Ok so in desperation I put it right next to the ucm.cmd and just do "run helloWorld" on the cli even though I don't see why this would work but it does. Apparently I'm supposed to just dump my code directly into the downloaded compiler/folder? So then what is the C:\Users\myuser project folder for if I have to put all my .u files directly next to ucm.cmd anyway? And another weird thing is that everytime I make a change to the scratch.u file the cli tells me "Run `update` to apply these changes to your codebase." but even if I don't do that then rerunning "run helloWorld" still runs the new code.

I tried the unison vscode extension btw and despite ucm being on the path now it says: "Unison: Language server failed to connect, is there a UCM running? (version M4a or later)". I also seem to be required to close my ucm cli in order to run vscode because it says that the database is locked otherwise. And I guess there is no debugger yet? It just seems weird that I don't really know where my "project" even is or what this project model conceptually is. It seems like I just put all my unison code somewhere next to the compiler, it loads everything by default into the compiler and I merely do db updates into some kind of more permanent sqlite storage perhaps but then why do I even do that, wouldn't I still just put the .u files into a git repository? There is also no mention of how this language runtime works or performs, I'm assuming fully memory managed but perhaps slow because I'm seeing an interpreter mentioned?

I think you also really need a web based playground where you show off some of these benefits of unison in small self contained snippets because just reading through some examples is pretty hard, it's a very different language and I can't tell what I'm looking at as a lifelong C/Java/etc. tier programmer. Sure you explain the concepts but I'm looking for a far more hands on: "run this ability code, look: here is why this is cool because you are prevented from making mistakes thanks to ..." or "this cannot possibly error because thanks to abilities ..." instead of so much conceptual explanation: https://www.unison-lang.org/docs/fundamentals/abilities/usin...

Re: Unison 1.0

#70

Post by stewoconnor »

infogulch wrote: post #38
pchiusano wrote: post #2

Also, hi, I'm one of the language creators, feel free to ask any questions here!

I've been following Unison for a long time, congrats on the release! Unison is among the first languages to ship algebraic effects (aka Abilities [1]) as a major feature. In early talks and blog posts, as I recall, you were still a bit unsure about how it would land. So how did it turn out? Are you happy with how effects interact with the rest of the language? Do you like the syntax? Can you share any interesting det…

> congrats on the release

Thank you!

> Unison is among the first languages to ship algebraic effects (aka Abilities [1]) as a major feature. In early talks and blog posts, as I recall, you were still a bit unsure about how it would land. So how did it turn out?

No regrets! This Abilities system is really straightforward and flexible. You find yourself saying that you don't miss monads, if you were already of the FP affiliation. But were glad that it means that you don't have to understand why a monad is like a burrito to do FP.

> Do you like the syntax?

So this one is very loaded. Yes we LOVE the syntax and it is very natural to us, but that is because most of us that are working on the language had either already been fluent in haskell, or at least had gotten to at least a basic understanding to the point of of "I need to be able to read these slides". However we recognize that the current syntax of the language is NOT natural to the bulk of who we would like to be our audience.

But here's the super cool thing about our language! Since we don't store your code in a text/source code representation, and instead as a typechecked AST, we have the freedom to change the surface syntax of the language very easily, which is something we've done several times in the past. We have this unique possibility that other languages don't have, in that we could have more than one "surface syntax" for the language. We could have our current syntax, but also a javascript-like syntax, or a python-like syntax.

And so we have had lots of serious discussions recently about changing the surface syntax to something that would be less "weird" to newcomers. The most obvious one being changing function application from the haskell style "function arg1 arg2" style to the more familier "c?" like style of "function(arg1, arg2)". The difficulties for us will be trying to figure out how to map some of our more unique features like "what abilities are available during function application" onto a more familiar syntax.

So changing the syntax is something that we are seriously considering, but don't yet have a short term plan for.

Post reply on HN