3 ms·

Looking at the comments it seems that this talk might be a better introduction than just skimming at the landing page. https://www.youtube.com/watch?v=gCWtkvDQ

Looking at the comments it seems that this talk might be a better introduction than just skimming at the landing page. https://www.youtube.com/watch?v=gCWtkvDQ2ZI https://www.youtube.com/watch?v=gCWtkvDQ2ZI I watched that in 2020 or so and got amazed at how much a seemingly simple idea could work it's way into the core of a language. What I recall is this, The main new idea is turning codebases into a content-addressed store, this needs some new tooling, but makes a couple of interesting things possible, * Having different versions of the "same" function. They are actually different functions anyway, so you can do things like partial library upgrades when there's breaking changes. Large migrations like python 2 to 3 wouldn't take O(10yr). * Formatting is not a thing anymore. This goes further than just having a formatter as there's really no format nor names you can't personalize locally without affecting anybody. * Similarly, renaming is free, so you can come up with better names in the future and chanting it just needs a tweak to the canonical name for the function. * Functions are serialiazable, which makes it possible to send them to remote nodes for execution without any concerns about their deus, since a function is now more of a Merkle tree, so if there's any difference the client would know and be able to ask for missing dependencies * The tool to manage your function repo might seem like a burden to some, but once you realize that having this as a first class tool that understands the language you can propose safe mass refactoring of code you don't own.

bobajeff 4y ago
This sounds almost like Dion. It would be cool to be able to feed the AST to a compiler backend like gcc/llvm and map to C's semantics. * https://dion.systems/gallery.html https://dion.systems/gallery.html
xwolfi 4y ago
I stopped reading when they cried in joy at the ability to auto infer types instead of writing them. This has always led, in my limited experience, to unreadable code after 2 weeks. Why do people want to write short leetcode, Ill never get it.
- miloignis 4y ago
  Part of the cool bit about Unison is that the code is stored in a content-addressed database and is then rendered out to files to edit at your command (including with your own set of custom names for things, I think). I imagine that Unison would allow you to work on code that has entirely specified types while perhaps a coworker of yours let them all be inferred, without irritation to either of you.
  - zawodnaya 4y ago
    Yeah, Unison doesn’t just infer the types, it will add type signatures automatically to top-level definitions.
ghusbands 4y ago
> so you can do things like partial library upgrades when there's breaking changes. Large migrations like python 2 to 3 wouldn't take O(10yr). That wouldn't quite work, though, as Python 2 and 3 have mutually-incompatible ideas of what a sequence of bytes (string/binary) is; Unison solves the problem of references to code, but apparently not what happens when identically-typed data has different meaning between versions. At least, that's not answered in the video.
- kragen 4y ago
  i'm not sure what you mean by saying that python 2 string is mutually incompatible with python 3 bytes they just have different names in early versions of python 3 the type was castrated but that got fixed in more recent versions
- mjburgess 4y ago
  The author neglects to address the semantic reason that dependencies conflict, and focuses only on the syntactical (ie., a conflict of names). We want to enforce that where, eg., `np.array` is used, universally it's a data structure with the same properties. It isnt particularly desirable to have many versions of it floating around. It's not clear, atm, whether this is a real solution to the dependency problem. It seems like it solves it by making it easier to isolate areas of a codebase where dependencies are frozen. This is already an option, and people don't do it because they want actual semantic consistency. Maybe if it were easier it would be done more often, but a priori, it's a straw man of the dependency problem.
  - dmytrish 4y ago
    While this is definitely true in general, Unison can unlock many context-specific guarantees even for data: the types are strict and expressive and it seems to have referential transparency.
agumonkey 4y ago
IIRC jonathan edwards had similar ideas in subtext (https://www.subtext-lang.org/ https://www.subtext-lang.org/) all node based, name was just a property, changing it would reflect in all instanciations

bobajeff 4y ago

This sounds almost like Dion. It would be cool to be able to feed the AST to a compiler backend like gcc/llvm and map to C's semantics. * https://dion.systems/gallery.html https://dion.systems/gallery.html

xwolfi 4y ago

I stopped reading when they cried in joy at the ability to auto infer types instead of writing them. This has always led, in my limited experience, to unreadable code after 2 weeks. Why do people want to write short leetcode, Ill never get it.

miloignis 4y ago
Part of the cool bit about Unison is that the code is stored in a content-addressed database and is then rendered out to files to edit at your command (including with your own set of custom names for things, I think). I imagine that Unison would allow you to work on code that has entirely specified types while perhaps a coworker of yours let them all be inferred, without irritation to either of you.
- zawodnaya 4y ago
  Yeah, Unison doesn’t just infer the types, it will add type signatures automatically to top-level definitions.

ghusbands 4y ago

> so you can do things like partial library upgrades when there's breaking changes. Large migrations like python 2 to 3 wouldn't take O(10yr). That wouldn't quite work, though, as Python 2 and 3 have mutually-incompatible ideas of what a sequence of bytes (string/binary) is; Unison solves the problem of references to code, but apparently not what happens when identically-typed data has different meaning between versions. At least, that's not answered in the video.

kragen 4y ago
i'm not sure what you mean by saying that python 2 string is mutually incompatible with python 3 bytes they just have different names in early versions of python 3 the type was castrated but that got fixed in more recent versions
mjburgess 4y ago
The author neglects to address the semantic reason that dependencies conflict, and focuses only on the syntactical (ie., a conflict of names). We want to enforce that where, eg., `np.array` is used, universally it's a data structure with the same properties. It isnt particularly desirable to have many versions of it floating around. It's not clear, atm, whether this is a real solution to the dependency problem. It seems like it solves it by making it easier to isolate areas of a codebase where dependencies are frozen. This is already an option, and people don't do it because they want actual semantic consistency. Maybe if it were easier it would be done more often, but a priori, it's a straw man of the dependency problem.
- dmytrish 4y ago
  While this is definitely true in general, Unison can unlock many context-specific guarantees even for data: the types are strict and expressive and it seems to have referential transparency.

agumonkey 4y ago

IIRC jonathan edwards had similar ideas in subtext (https://www.subtext-lang.org/ https://www.subtext-lang.org/) all node based, name was just a property, changing it would reflect in all instanciations