Hacker News: tonsky

New comment by tonsky in "We shouldn't have needed lockfiles"

tonsky — Wed, 06 Aug 2025 16:47:46 +0000

Maven's version resolution mechanism determines which version of a dependency to use when multiple versions are specified in a project's dependency tree. Here's how it works:

- Nearest Definition Wins: When multiple versions of the same dependency appear in the dependency tree, the version closest to your project in the tree will be used.

- First Declaration Wins: If two versions of the same dependency are at the same depth in the tree, the first one declared in the POM will be used.

New comment by tonsky in "We shouldn't have needed lockfiles"

tonsky — Wed, 06 Aug 2025 16:45:58 +0000

> I’d love to lock my library to numpy 2.3.4, but if the developers of another library pin theirs to 2.3.5 then game over.

Why? Can’t you specify which version to use?

New comment by tonsky in "We shouldn't have needed lockfiles"

tonsky — Wed, 06 Aug 2025 16:45:05 +0000

> would fail in languages like Python where dependencies are shared

And yet Java and Maven exist...

New comment by tonsky in "We shouldn't have needed lockfiles"

tonsky — Wed, 06 Aug 2025 16:41:58 +0000

I updated the post, see near the bottom

New comment by tonsky in "We shouldn't have needed lockfiles"

tonsky — Wed, 06 Aug 2025 16:41:02 +0000

Yeah but version ranges are fiction. Some says: we require libpupa 0.2.0+. Sure you can find a version in that range. But what if it doesn’t work? How can you know that your library will work with all the future libpupa releases in advance?

New comment by tonsky in "We shouldn't have needed lockfiles"

tonsky — Wed, 06 Aug 2025 16:38:04 +0000

I worked for 20 years in an ecosystem that didn’t have lockfiles and had reproducible builds before the term was invented, and now you come and tell me that it couldn’t be?

New comment by tonsky in "We shouldn't have needed lockfiles"

tonsky — Wed, 06 Aug 2025 16:23:25 +0000

> Lockfiles are essential for somewhat reproducible builds.

No they are not. Fully reproducible builds have existed without lockfiles for decades

New comment by tonsky in "We shouldn't have needed lockfiles"

tonsky — Wed, 06 Aug 2025 16:20:13 +0000

One of the versions will be picked up. If that version doesn’t work, you can try another one. The process is exactly the same

New comment by tonsky in "We shouldn't have needed lockfiles"

tonsky — Wed, 06 Aug 2025 16:17:38 +0000

It’s totally fine in Maven, no need to rebuild or repackage anything. You just override version of libinsecure in your pom.xml and it uses the version you told it to

New comment by tonsky in "Sync Engines Are the Future"

tonsky — Fri, 21 Mar 2025 11:34:10 +0000

Clojure Electric is different. It’s not really a sync, it’s more of a thin client. It relies of having fast connection to server at all times, and re-fetches everything all the time. They innovation is that they found a really, really ergonomic way to do it

New comment by tonsky in "Sync Engines Are the Future"

tonsky — Fri, 21 Mar 2025 11:24:50 +0000

If you think of an existing database, like Postgres, sure. It’s not very convenient.

What I am saying is, in a perfect world, database and server will be the one and run code _and_ data at the same time. There’s really no good reason why they are separated, and it causes a lot of inconveniences right now.

New comment by tonsky in "Sync Engines Are the Future"

tonsky — Fri, 21 Mar 2025 11:22:39 +0000

Ah, no. Not really. People sometimes think about conflict resolution as a problem that needs to be solved. But it’s not solvable, not really. It’s part of the domain, it’s not going anywhere, it’s irreducible complexity.

You _will_ have conflicts (because your app is distributed and there are concurrent writes). They will happen on semantic level, so only you (app developer) _will_ be able to solve them. Database (or any other magical tool) can’t do it for you.

Another misconception is that conflict resolution needs to be “solved” perfectly before any progress can be made. That is not true as well. You might have unhandled conflicts in your system and still have a working, useful, successful product. Conflicts might be rare, insignificant, or people (your users) will just correct for/work around them.

I am not saying “drop data on the floor”, of course, if you can help it. But try not to overthink it, either.

New comment by tonsky in "Sync Engines Are the Future"

tonsky — Fri, 21 Mar 2025 11:10:09 +0000

> There's no such thing as reliable network in the world

I’m not saying there is

New comment by tonsky in "Sync Engines Are the Future"

tonsky — Fri, 21 Mar 2025 11:09:33 +0000

- You can have many sync engines

- Sync engines might only solve small and medium scale, that would be a huge win even without large scale

New comment by tonsky in "Sync Engines Are the Future"

tonsky — Fri, 21 Mar 2025 11:06:28 +0000

It’s not as simple as you make it sound:

- Reliable communication is hard - Optimistic writes should on client are hard - Tracking subsets of data is hard (you don't want the entirety of Datomic on the client, do you?) - Permissions are hard in this model

Why didn't I implement it? Mostly comes down to free time. It's a hobby project and it's hard to find time for it. I also stopped writing web apps so immediate pressure for this went away.

New comment by tonsky in "Clojure Desktop UI Framework"

tonsky — Wed, 28 Aug 2024 08:13:55 +0000

That’s two perfect examples! Racket seems to try to use native widgets, and looks horrible as a result, at least on macOS

JavaFX uses the same approach as Humble UI: they draw all the widgets themselves and have custom cross-platform look and feel.

We aim to be better quality version of JavaFX

New comment by tonsky in "Clojure Desktop UI Framework"

tonsky — Tue, 27 Aug 2024 17:12:24 +0000

If they use native widgets, they usually look really bad If they just “imitate” look and feel, they usually fall very short of the real thing

Either way, it’s bad experience for the end user

New comment by tonsky in "Clojure Desktop UI Framework"

tonsky — Tue, 27 Aug 2024 15:41:10 +0000

It’s a tradeoff. You either make your app native but only for one platform, or you make it look “universal” and run on all three.

New comment by tonsky in "Clojure Desktop UI Framework"

tonsky — Tue, 27 Aug 2024 15:38:56 +0000

All good points, all true. But what’s also true is that current trend is to come up with arbitrary-looking controls even on apps made by Apple themselves. Nobody knows what native is supposed to look like. I’m not saying it’s good, it’s just what is happening.

New comment by tonsky in "Clojure Desktop UI Framework"

tonsky — Tue, 27 Aug 2024 15:34:45 +0000

Not yet, but in theory, sure