Hacker News Reader

Loading both copies of a library can be very useful to deal with the situation where one piece of code has been ported to v2 (due to bugs/features or just generally keeping up with updates) and another piece of code is hard blocked on the v1->v2 migration because it is much more costly, and its possible that v2 is actually buggier for that other use case. There's a bit of a naive idea that software always gets better for everyone and that projects have an infinite amount of spare time to drop everything to bump dependencies. That feature is actually very useful.

(Which is not to defend the rest of the append-only immutability of the rest of the language, that looks a bit whack -- but then I've seen whack stuff get wildly popular, so I have no idea -- but while having 2 versions loaded at the same time might be useful I'm not sure I want to deploy every version that has ever existed that smells way too bloated)

You are right - but choosing the correct solution imho needs to be done with human oversight - I think a semver based dependency resolution works great here, for example if bar requires foo 1.0 and baz needs 1.0.1 they will happily use the same version, but if baz used foo 1.1 they would use the separate ones.

Except 1.0.1 can fix a bug that one piece of code needs, while another piece of code can be happily bug dependent upon it.

You can scream at the developers that they've violated semver but a "bugfix" is entirely subjective (relevant xkcd, spacebar heating, etc).

And even when developers violate semver in a point release the problem still exists. They actually rarely, if ever, rollback with a 1.0.2 that is equivalent to 1.0.0 and instead usually move forwards.

And if you have a language that supports loading 1.0 and 1.1 then there's no point in being artificially constrained over which two versions can be loaded at the same time based on the label, the underlying framework shouldn't be built to care. There's no need for a multi-version library loader to care about what a bugfix is.

SemVer remains a pragmatic approach that works in vast amount of cases. It’s unclear what alternative we have here which works in more cases.

We don't have any better alternative, but lets not be naive about it when it comes to building bits of framework.

Semver would just be an artificial impediment at this level.

SemVer is an impediment only if you insist to make it so.

Go takes an alternative approach:

https://www.youtube.com/watch?v=wWApoImHuf8

That's not a new idea, I also put the version in my package name, so that you can use v1.x with v2.x etc.

It doesn't contradict SemVer.

However when you do that, it becomes a big deal to jump from one version to another even if the breaks are minor. So pros and cons.

(Mentioned xkcd: https://xkcd.com/1172/)

I think another key idea is that you're still thinking about libraries as complete packages where you kinda install two versions of the same thing. But it seems more likely in the Unison ecosystem that you'd end up with the ability to much more easily only extract the specific functions you need.

So say there is v1 and v2 of a utility lib in my dep tree, but actually only using func A from v1 and func B from v2. Then I just have the AST of v1.A and v2.B in my deps and everything works.

You still need some unit of atomicity to be able to maintain invariants. You can't combine HashMap_LinearProbe::insert with HashMap_Chains::remove, because they both depend on implementation details in order to maintain HashMap's invariants.

> Storing the AST on the disk in a million files is not necessarily the best use of the filesystem

A new codebase format just uses a sqlite database instead of a million files

> Since the language is append only, all edits look like additions in version control

Traditional methods of showing change in verson control, that is text diffs, don't make sense here anyway

> Detecting that 2 things are the same through hashing is nontrivial, can it detect that 1 + x + 1 is the same as x + 2? The ASTs are differen

It can't detect that. It if could it would be pretty cool, but I don't think it would improve the usability too much

What's the point of detecting that 1 + x + 1 is the same as x + 2 anyway? If I wrote it in one way, I meant it to be that way for a reason. Should it also be able to prove arbitrary code is semantically equivalent? Well, it can't do that for obvious reasons.

Why not use hashing with locality for similarity? That is if the two samples above "hashed" to a similar value it might be helpful to find similar code.

Hashing was created to prevent collisions and ensure small changes have big differences in result. The first requirement makes sense here, but not sure how the second helps.

Semver is an uneasy compromise at best. Rich Hickey has a nice talk that digs into the principles around changing software. Once you see this POV, you are unlikely to view Semantic Versioning as anything other than a messy hack.

I'm not saying it is worse than nothing, but sometimes ideas have a way of sticking around too long and making people comfortable.

The talk for those interested: https://youtube.com/watch?v=oyLBGkS5ICk

And the transcript: https://github.com/matthiasn/talk-transcripts/blob/master/Hi...

I think Unison paired with a strong graph database instead of the filesystem would be a powerful combo. It would very naturally represent the AST graph directly and would benefit from graph db optimizations. The cost would be the need to invest a lot in new tooling: you'd want a graph db-based source control implementation that offers similar cryptographic certainty to git; you'd have trouble using existing tooling directly like text editors that expect files on disk; etc.

The combination of the two makes me think auto/AI-generated code would be much more feasible and powerful in such an ecosystem.

Semver doesn't help in the case of transitive binary incompatibility. If lib A depends on B v2, and lib C depends on B v1, and application D depends on A and C, you cannot load a version of B that satisfies D, A, and C. Semver tells you that B 1 and B2 are incompatible, but not how to solve the issue.

Unison solves the issue - there isn't any binary incompatibility, because the transitive versions of Bv1 and Bv2 cannot be in conflict - the function references are to guaranteed unique and different versions of the art.

As for bug fixes - you can specify in your code exactly which version to use.

As for editors needing to be unison aware - they just delegate everything to the compiler via lsp and bsp.

Bug fixes are no more difficult than making the change. A new version is created, and your code can now depend on it. Old code will still run off of the old version. It's up to the code owner to decide to use the new, but fixed version.

Version control is all handled in the language itself.

As for the hard hashing problem... Runar is a particularly intelligent individual. I expect that his algorithm works pretty well.

The first argument about storing the ast is moot in an age where cached compiled typescript, Python, and .class files take up inordinate amounts of disk space.

> Solutions that dynamically discover code dependencies and automatically run tests exist for both procedural and functional languages

Eh. Piping and yarn ain't got nothing on maven and ivy and apt. But yes, dependency management isn't anything new under the sun. Dynamically resolving individual function versions in packages alongside binary incompatible functions is.

Honestly, programming without language aware tools in this day and age is very inefficient. Sure, in a pinch you can use a text editing program to edit stuff, but it wouldn't be so hard to install the standard editor in that case.