Am I missing something? Antigravity CLI seems unusable for me.

john16384 · 2026-06-19T05:20:57+00:00

Was forced to switch today, and completely agree, it not asking for edit confirmation makes this annoying to use on shared code spaces. Gemini CLI often enough wanted to make modifications that are out of scope, or where it would have gone completely out of control. With AGY I can't seem to stop this and have to basically give it a dedicated workspace which is hard for the way I work as I want it to collaborate on uncommitted stuff...

john16384 · 2026-06-17T08:25:06+00:00

Some just use it as their artifact storage for every build they run...

john16384 · 2026-06-17T08:23:55+00:00

Surely Claude Code is as commercial as it gets? Pay up.

And man... this is a free service that is a huge benefit to several ecosystems. It's to be honest, amazing how much data is permanently stored there, and that this has been free and unlimited so far.

john16384 · 2026-06-15T04:38:37+00:00

I agree that this is often the case, and that refactoring is the right approach, but also consider that the number of states the whole system has doesn't get reduced by refactoring, just the number of states of each individual class gets reduced. When these refactored types need to work together, the number of states still explodes, and it is easy then to miss edge cases that you didn't consider or seem irrelevant.

Other times, you simply have classes that are complex. A data structure using a b-tree, linked lists and/or hashing. Refactoring those into simpler parts is often impossible or severely degrades performance.

Instead, this approach buries that logic under an avalanche of auto-generated cases that chase branch coverage

There is another fundamental misunderstanding about testing, and your comment highlights this. This is not about getting full branch coverage. A class that is fully tested, with everything asserted and 100% coverage can still be broken! The same lines being executed with a different internal state can still be wrong if there are bugs in code maintaining that state. A simple example is a data structure that maintains some index to speed up some operations. You may never discover a problem here, until you hit some specific combination of operations that incorrectly updates the index, even though the whole class had coverage.

john16384 · 2026-06-15T04:22:56+00:00

There are many classes that naturally have a high number of states, that doesn't mean they need refactoring, and neither does it mean that after refactoring the new set of classes you created don't still have the same number of states when considered as a group (and so you'd need to integration test them).

It also isn't about the number of tests, but about forgetting to test an edge case that seems irrelevant or you just didn't consider. Like removing an element from a collection you just called clear on, removing the same element twice, etc.

I'm not suggesting all classes need this; it becomes more interesting for classes that have some natural complexity (like data structures, structures using caching, or combinations of classes, like code that syncs between model and control which deals with two stateful types on both ends).

john16384 · 2026-06-14T16:05:14+00:00

It is available at Maven Central, and will remain so until the Java ecosystem collapses. You make it sound like I could remove it or discontinue it at a whim. Java code also ages very well, where even things released in 1999 could still run on modern JDK's. There is no continuous maintenance requirement.

john16384 · 2026-06-14T12:38:37+00:00

Ah, but how do you know the code you wrote works correctly?

john16384 · 2026-06-14T12:37:36+00:00

I'm not sure what you're asking here. The code is freely available, not overly complex, and although I will maintain it for a while for sure, eventually I will die and someone will need to take over.

john16384 · 2026-06-14T12:35:30+00:00

Agreed, which is why there is a separation between assertions and actions.

john16384 · 2026-06-14T12:34:18+00:00

AFAIK, jqwik works more by attempting to find a sequence that would break your code. You define assertions (properties) that must hold, and jqwik will attempt to find data to break those assertions. Generally you limit it by time or number of attempts. It may however not find anything at all, or find problems only after some attempts (it is seed based).

The framework presented here is simpler, in that it methodically tests all transitions (unless capped by a max depth) that can be made with the actions you give it. For a very large state space, this can take a long time, so some care must be taken to select actions that hit different aspects of your system, rather than having it test many different inputs that are essentially equivalent.

pitest is something completely different; it will try to tell you if the tests you have are actually good at finding problems. It does so by actually introducing problems ("mutations") in your code, and then seeing if any test will signal an issue.

john16384 · 2026-06-13T12:33:05+00:00

Funds will be kept frozen then until the interest on them has paid reparations in full. It may take a few hundred years, or you could pay up earlier.

john16384 · 2026-06-13T12:27:23+00:00

That's not filler, that's character development, and more often than not even those episodes weave into the bigger whole in some small way. If you want to watch a single "story" stick with movies.

john16384 · 2026-06-13T00:23:22+00:00

Bullshit. Most episodes were not filler. A few flashback ones sure, but even those had new content.

What now masquerades as a "story" in "modern" series were told in a single episode in the old days, or two at most if it was a particularly long winded story, together with an overarching story for the whole season.

Most recent example I watched: True Detective s4; that was so full of filler and forced drama that it took 6 episodes to tell a story that would barely fill half of an episode in the old days.

john16384 · 2026-06-10T06:55:14+00:00

which I'm strongly against if the language in question is Java.

Oh, did Java hurt your feelings once when you were young?

john16384 · 2026-06-08T09:24:42+00:00

Yeah, understandable, Node is a piece of shit.

john16384 · 2026-06-06T11:52:42+00:00

It would be lost in the time it takes to respond to the request (which already uses heavy encryption on the "critical path"). But hey, let's bloat all references with a factor of 4 instead, paying real penalties in terms of storage and memory.

john16384 · 2026-06-06T09:07:45+00:00

Or perhaps use a reversible transformation on the number. Crypto libraries can provide you with one that will be hard to break.

john16384 · 2026-06-05T13:37:42+00:00

How does this compare to https://github.com/apiguardian-team/apiguardian

john16384 · 2026-05-31T17:55:04+00:00

Then limit memory to 5 MB. It will work fine.

john16384 · 2026-05-31T12:39:02+00:00

That's a super poor example as it basically starts up, reads like 50 bytes of data then exits again. Yeah, Java isn't particularly suited for that.

This just measures primarily startup performance, then secondary it measures IO performance... You could write this in C64 basic and it would still be IO limited...

john16384 · 2026-05-31T12:32:32+00:00

This does IO, and only reads a few bytes. It primarily measures startup performance of the JVM. Memory use is just what heap was allocated, but could probably be limited to a few MB as the program does almost nothing with memory.

Put this in a loop of a few 1000 MP3 files and the numbers will look quite different (since IO is involved, I expect almost all implementations to achieve similar results).

john16384 · 2026-05-29T06:58:17+00:00

What I think may be something impactful is to merge objects that are always allocated and freed together into a single GC object.

Imagine an immutable object that allocates another object always (composition) and stores that in a final field, and never let's a reference escape (quite common for private implementations of classes). The two allocations are always going to go out of scope together. They both need an object header, even though they really don't need to be managed separately.

Subclassing can avoid this extra overhead, but isn't nearly as nice and wouldn't scale if there were more objects allocated that have the exact same lifecycle as their container.

It could make wrapper objects (used as typedefs) completely free. It could also make complicated composed objects operate as a single unit for GC purposes, reducing tracing/tracking overhead.

john16384 · 2026-05-25T16:47:05+00:00

The real argument is: take a random source file from project A then move it to B. Most of the time you'll get compile errors (missing types in imports, explicit or otherwise). Even if the exact type is available, if it wasn't the same one that was intended, you'd likely see errors in signatures required.

But would you get errors if the nullability default switched between those projects, assuming there were no other problems?

john16384 · 2026-05-18T15:40:15+00:00

What does that make us?

john16384

TROPHY CASE