[binary132]

ISTM that packing all that goodness (?) into the compiler stack itself is moving away from what I want where the compiler is a plain-Jane source transform and its inputs and outputs are very well specified and predictable. That’s where the ecosystem of tools comes in, and when done right I think tools should be very easy and straightforward to use and create. I often feel modern languages get this wrong by “including” too many “batteries” instead of specifying and documenting their build / dependency semantics clearly and providing good tools or libraries for working with and composing those elements of build.

Far too few language ecosystems provide any kind of libraries for it whatsoever, even for working with syntax / AST. I really can only think of Clang and Go, and Go’s tool libraries aren’t very accessible IMO.

[sp33der89]

This is a good point, and deserves a lot more discussion about it.

I personally don't mind that my code is somewhere else than in a text file, because as it now I have to ductape a huge array of tools to make it to production in languages like TypeScript and Elixir(languages we use at $WORK). I don't want to deal with that anymore than I need to.

I hope modern languages get to the level of swiftness like Unison, but until then I'm really happy with Unison, because code-in-database is only one of the several aspects I like about it(no dependency conflicts being another huge part of it!).

Clang is a good example I know, and Scala(https://www.chris-kipp.io/blog/an-intro-to-the-scala-present...) also has some nifty stuff. But even in Scala things aren't as seamless as in Unison.

Unison does things very differently, and it might not be everybody's cup of tea. But I do hope that popular languages take the good bits and help programmers do less chores and more fun stuff.

> I often feel modern languages get this wrong by “including” too many “batteries” instead of specifying and documenting their build / dependency semantics clearly

Do you have some examples? Nix somewhat aims to solve this, but it has its own drawbacks. A lot of people these days _expect_ a battery included environment: package manager, build tooling, linting, formatting, a language server, documentation generators. Unison solves a lot of these in one go because of the way it handles code, I think that's elegant and worth exploring.

[binary132]

I’m not sure there is really more to say here. A lot of people don’t seem to like strong type systems very much either, but that doesn’t mean they’re not wrong. ;)

That said, it clearly has some interesting ideas! I’m just not sure I understand why the database needs to be the compiler. It seems like an awful lot of design decisions baked into the stack instead of offered as APIs or protocols. And it’s obvious that we can consider the filesystem itself to be a sort of database — Git famously is implemented entirely in filesystem semantics, for example, so it’s also not clear to me why this content addressing can’t simply be done in a cache dir, or some such, the way many build systems do for their compilation units.

[sp33der89]

> I’m not sure there is really more to say here.

I'm sure that there can be some very interesting discussions about code-in-database and interop with tooling!

> I’m just not sure I understand why the database needs to be the compiler.

I'm not entirely sure if these two are tightly bound. For example `ucm` uses a SQLite database, but Share(their Github equivalent) uses PostgreSQL afaik.

I believe a previous iteration used Git as the backing store but they didn't go through with it. I'm not sure about this tho.