6 ms·

I think they are making a mistake that's common in this sort of project: trying too many new things at once! They already have a very innovative way of managin

by brabel 4y ago

I think they are making a mistake that's common in this sort of project: trying too many new things at once! They already have a very innovative way of managing source code, with a database of definitions that keeps the hash of the syntax tree instead of actual source. That's a very neat idea that solves many problems (read their docs to understand why). But instead of developing that well enough so that it works with source control tools, IDEs, can be deployed easily and painlessly on existing infrastructure... no, they decided to ALSO solve distributed computing, a really, really complex space with a pretty crowded space of solutions... and seem to be focusing on that now instead of the "original" ideas. Looks like a huge issue with scope creep to me... unless they are kind of pivoting to distributed computing now only because the original ideas were not attractive enough for people to embrace it, but I have not heard of anything like that, everyone seems to be pretty vibed by those things.

dack 4y ago
To be fair, for a while they were ALSO working on their own graphical source editor that allowed for type-correct transformations and assisted refactorings. They put that on the back burner specifically because they are trying to focus on fewer things :) I think the distributed computing problem is pretty related once you have "content-addressable" source code. Agreed that it's a lot of work but I hope it pans out!
- renox 4y ago
  I disagree, there's no real relationship between 'content addressable' source code and distributed computing. Also I don't think that you need to create a new language to have 'content addressable' source code distribution.. Creating yet another language ensure that this will get nowhere, too bad.
  - nerdponx 4y ago
    My impression is that the original use case was distributed computing, and the content-addressable stuff took on a life of its own after that.
    - ghc 4y ago
      This is completely correct. Unison was always a distributed computing project, even when it was just an idea.
  - zawodnaya 4y ago
    Well, there is a relationship. The relationship is specifically that Unison nodes can communicate code with one another unambiguously by exchanging hashes.
    - pharmakom 4y ago
      Would this not work just as well with a lisp or even JS?
      - klabb3 4y ago
        How about wasm? Interop de lux
        zawodnaya 4y ago
        An issue with exchanging WASM is you'll have to do either dynamic or static linking of dependencies. Unison works around this by having all definitions share a global address space (and the address of any given code in that space is the hash of its syntax tree), so there is no linking step. Or rather, the linking is done trivially by the hashing.
      - Quekid5 4y ago
        The key idea is that Unison code is in a sort of "normal form", such that e.g. what names you give things doesn't matter at all.
      - zawodnaya 4y ago
        Well, it could be done in JS or Lisp. You'd have to replace all the references to dependencies in every function with a hash of the implementation of the referenced function and use some kind of global lookup table (which would need to be a distributed hash table or something). But this would be slow, so you'd need a compiler or some kind of processor to inline stuff and do CPS transforms, and by that time you've basically implemented a janky version of Unison.
        actionfromafar 4y ago
  - klabb3 4y ago
    > Creating yet another language ensure that this will get nowhere, too bad. What has happened before, consistently, is that research or proof of concept- style languages pave the way for bigger players to take the ideas and incorporate them into existing or future mainstream languages.
xwowsersx 4y ago
I thought that was sort of Paul's goal, to explore a bunch of new ideas and paradigms. I doubt he's under any illusions that this language, qua this language, is going to see wide adoption or need to have all of its features really ironed out with a fixed/stable API. But I could be wrong!
- jrumbut 4y ago
  Then that flips it back to being very cool that he is putting his energy into carrying a few batons far enough for others to pick them up.
  - xwowsersx 4y ago
    Agreed, I think it's great to have really cutting-edge, highly experimental sort of research languages that explore new paradigms. Doesn't mean you have to like the language, but I think it's good that some people are doing this kind of work as a going concern and not just some repo that was pushed up once somewhere and languishes. He's got some interesting ideas in there related to effects system, etc.
  - xwowsersx 4y ago
    > carrying a few batons far enough for others to pick them up. I love that metaphor btw. Gonna use that.
- IshKebab 4y ago
  > I doubt he's under any illusions that this language, qua this language, is going to see wide adoption or need to have all of its features really ironed out with a fixed/stable API. But I could be wrong! They have VC funding and employees. I presume he's told investors that it will see at least fairly wide adoption!
  - xwowsersx 4y ago
    Ha! Did not know that. Not necessarily dispositive though. Also, I believe they are a public benefit corporation so that would also cut in favor of my point...I think
jupp0r 4y ago
The two areas of managing source code and distributed computing are not as disjunct as you make them in the context of Unison. They follow from the underlying principle of addressing functions not by their name but by a hash of their normalized syntax tree (ie their code). There are a bunch of cool implications for distributed computing, namely that you can easily distribute fine grained parts of your application across servers and that you can cache the result of expensive calculations.
- msla 4y ago
  > They follow from the underlying principle of addressing functions not by their name but by a hash of their normalized syntax tree (ie their code). The first time the language or compiler changes such that the same code generates a different syntax tree they'd have to do something pretty fancy to avoid rebuilding the world. (That, plus all the usual caveats about what happens when old hash algorithms meet malicious actors from the future.)
  - stewoconnor 4y ago
    (Unison Developer here), yes we've done two such migrations this year. It has typically meant that we have an "are you ready to upgrade" message when you start up and the migration took less than a minute on my pretty large codebase. It's not a big deal
    - msla 4y ago
      It's a solved problem technically, certainly, but assuming all of the relevant source code will always be available ignores some social and legal issues.
      - jupp0r 4y ago
        It's a common approach in language design to require this though. Rust has made very similar design choices due to its (current) lack of stable ABIs. IIRC some hash of the compiler version is included in built libraries and prevents accidental linking. You need to rebuild the world for every toolchain upgrade.
AnthonBerg 4y ago
If we want to set sail on the ocean, we do not take a basket and start work to stop it from leaking. We build a boat.
waynesonfire 4y ago
> read their docs to understand why hard pass. but thanks for the suggestion. I'll start with the home page and the examples and most likely end there.
fwip 4y ago
The reason for the source code structure is because of what it enables for distributed computing. It makes it simple to transparently ship the code (not just data) around to any worker node. The point of Unison Cloud is to disappear the difference between AWS EC2 and Lambda.
daxfohl 4y ago
Sounds like `Opa!`, which was a language plus a meteor-like framework. The language itself was really nice with some interesting type-level features, but the built-in framework was the selling point. But all that ultimately got in the way for doing anything that wasn't built into it, which ended up being pretty much anything beyond toy prototypes. The language got dragged down because of it. That said, it came out around the same time CoffeeScript did, and nobody uses CoffeeScript anymore either. So probably the fate was inevitable regardless of whether the framework was included in the language or not.
ghc 4y ago
You have it backwards. The source code management (as a marketable feature) came at least one year and maybe two years after the distributed computing parts. The earliest Unison demos (circa 2016) were "build a distributed google crawler in just a few lines of code". I think the hashes were always a component, but not part of the real messaging for quite awhile.
dragonwriter 4y ago
> I think they are making a mistake that’s common in this sort of project: trying too many new things at once! The one thing identified as “the big idea” of Unison seems to me to be conceived as a solution to a distributed computing problem that incidentally also solves a number of problems that are issues outside of distributed computing (but also within distributed computing, such that fleshing out how it can solve them enhances unison as distributed computing solutions as well as providing side benefits.)

by brabel 4y ago

dack 4y ago

To be fair, for a while they were ALSO working on their own graphical source editor that allowed for type-correct transformations and assisted refactorings. They put that on the back burner specifically because they are trying to focus on fewer things :) I think the distributed computing problem is pretty related once you have "content-addressable" source code. Agreed that it's a lot of work but I hope it pans out!

renox 4y ago
I disagree, there's no real relationship between 'content addressable' source code and distributed computing. Also I don't think that you need to create a new language to have 'content addressable' source code distribution.. Creating yet another language ensure that this will get nowhere, too bad.
- nerdponx 4y ago
  My impression is that the original use case was distributed computing, and the content-addressable stuff took on a life of its own after that.
  - ghc 4y ago
    This is completely correct. Unison was always a distributed computing project, even when it was just an idea.
- zawodnaya 4y ago
  Well, there is a relationship. The relationship is specifically that Unison nodes can communicate code with one another unambiguously by exchanging hashes.
  - pharmakom 4y ago
    Would this not work just as well with a lisp or even JS?
    - klabb3 4y ago
      How about wasm? Interop de lux
      - zawodnaya 4y ago
        An issue with exchanging WASM is you'll have to do either dynamic or static linking of dependencies. Unison works around this by having all definitions share a global address space (and the address of any given code in that space is the hash of its syntax tree), so there is no linking step. Or rather, the linking is done trivially by the hashing.
    - Quekid5 4y ago
      The key idea is that Unison code is in a sort of "normal form", such that e.g. what names you give things doesn't matter at all.
    - zawodnaya 4y ago
      Well, it could be done in JS or Lisp. You'd have to replace all the references to dependencies in every function with a hash of the implementation of the referenced function and use some kind of global lookup table (which would need to be a distributed hash table or something). But this would be slow, so you'd need a compiler or some kind of processor to inline stuff and do CPS transforms, and by that time you've basically implemented a janky version of Unison.
      - actionfromafar 4y ago
- klabb3 4y ago
  > Creating yet another language ensure that this will get nowhere, too bad. What has happened before, consistently, is that research or proof of concept- style languages pave the way for bigger players to take the ideas and incorporate them into existing or future mainstream languages.

xwowsersx 4y ago

I thought that was sort of Paul's goal, to explore a bunch of new ideas and paradigms. I doubt he's under any illusions that this language, qua this language, is going to see wide adoption or need to have all of its features really ironed out with a fixed/stable API. But I could be wrong!

jrumbut 4y ago
Then that flips it back to being very cool that he is putting his energy into carrying a few batons far enough for others to pick them up.
- xwowsersx 4y ago
  Agreed, I think it's great to have really cutting-edge, highly experimental sort of research languages that explore new paradigms. Doesn't mean you have to like the language, but I think it's good that some people are doing this kind of work as a going concern and not just some repo that was pushed up once somewhere and languishes. He's got some interesting ideas in there related to effects system, etc.
- xwowsersx 4y ago
  > carrying a few batons far enough for others to pick them up. I love that metaphor btw. Gonna use that.
IshKebab 4y ago
> I doubt he's under any illusions that this language, qua this language, is going to see wide adoption or need to have all of its features really ironed out with a fixed/stable API. But I could be wrong! They have VC funding and employees. I presume he's told investors that it will see at least fairly wide adoption!
- xwowsersx 4y ago
  Ha! Did not know that. Not necessarily dispositive though. Also, I believe they are a public benefit corporation so that would also cut in favor of my point...I think

jupp0r 4y ago

The two areas of managing source code and distributed computing are not as disjunct as you make them in the context of Unison. They follow from the underlying principle of addressing functions not by their name but by a hash of their normalized syntax tree (ie their code). There are a bunch of cool implications for distributed computing, namely that you can easily distribute fine grained parts of your application across servers and that you can cache the result of expensive calculations.

msla 4y ago
> They follow from the underlying principle of addressing functions not by their name but by a hash of their normalized syntax tree (ie their code). The first time the language or compiler changes such that the same code generates a different syntax tree they'd have to do something pretty fancy to avoid rebuilding the world. (That, plus all the usual caveats about what happens when old hash algorithms meet malicious actors from the future.)
- stewoconnor 4y ago
  (Unison Developer here), yes we've done two such migrations this year. It has typically meant that we have an "are you ready to upgrade" message when you start up and the migration took less than a minute on my pretty large codebase. It's not a big deal
  - msla 4y ago
    It's a solved problem technically, certainly, but assuming all of the relevant source code will always be available ignores some social and legal issues.
    - jupp0r 4y ago
      It's a common approach in language design to require this though. Rust has made very similar design choices due to its (current) lack of stable ABIs. IIRC some hash of the compiler version is included in built libraries and prevents accidental linking. You need to rebuild the world for every toolchain upgrade.

AnthonBerg 4y ago

If we want to set sail on the ocean, we do not take a basket and start work to stop it from leaking. We build a boat.

waynesonfire 4y ago

> read their docs to understand why hard pass. but thanks for the suggestion. I'll start with the home page and the examples and most likely end there.

fwip 4y ago

The reason for the source code structure is because of what it enables for distributed computing. It makes it simple to transparently ship the code (not just data) around to any worker node. The point of Unison Cloud is to disappear the difference between AWS EC2 and Lambda.

daxfohl 4y ago

Sounds like `Opa!`, which was a language plus a meteor-like framework. The language itself was really nice with some interesting type-level features, but the built-in framework was the selling point. But all that ultimately got in the way for doing anything that wasn't built into it, which ended up being pretty much anything beyond toy prototypes. The language got dragged down because of it. That said, it came out around the same time CoffeeScript did, and nobody uses CoffeeScript anymore either. So probably the fate was inevitable regardless of whether the framework was included in the language or not.

ghc 4y ago

You have it backwards. The source code management (as a marketable feature) came at least one year and maybe two years after the distributed computing parts. The earliest Unison demos (circa 2016) were "build a distributed google crawler in just a few lines of code". I think the hashes were always a component, but not part of the real messaging for quite awhile.

dragonwriter 4y ago

> I think they are making a mistake that’s common in this sort of project: trying too many new things at once! The one thing identified as “the big idea” of Unison seems to me to be conceived as a solution to a distributed computing problem that incidentally also solves a number of problems that are issues outside of distributed computing (but also within distributed computing, such that fleshing out how it can solve them enhances unison as distributed computing solutions as well as providing side benefits.)