im a java guy, but it simply takes too long to start up and uses too much memory to be a reasonable language for ai agent development.

However, the cause it not really Java as such, but massive frameworks and tooling (e.g. Maven). Maybe AI will bring some fresh air to Java, because old truths might no longer be valid. But it will be hard to get rid of old habits because it manifested in AI training data.

"AI guys" use Claude CLI that renders to a terminal via freakin' react.

Come on, java starts up fast enough and the memory usage can be set (better throughput vs less memory, it's a classic tradeoff. Go just defaults to worse throughput).

Really, without some fat framework doing all kinds of initialization stuff, java code starts up practically instantly.

Java takes flags for min/initial/max memory that, as a strict law of nature, are always wrong the first time you try. And it holds onto unused memory unless you pass another flag. Idk exactly why there's no reasonable default for that, but probably cause it's in a VM. No other language has this problem.

It does give back memory nowadays.

And it's not really a VM in that sense of the word. It's a runtime, Go also has such a runtime it's just bundled.

The Java "compiled" code isn't a native binary like in Go, it really does run in a VM. I honestly don't know if that's why they handle memory differently though.

> Come on, java starts up fast enough and the memory usage can be set

Yeah it can be adjusted, on the other hand you have a language that just works. Starts instantly and memory usage is bounded by usage, not guesstimate of how much the JVM will need.

> Really, without some fat framework doing all kinds of initialization stuff, java code starts up practically instantly

Have you many java projects that didn't use some fat framework? Good for you if you did, but 100% of java project I had the displeasure of touching were huge mess with deprecated frameworks on ancient java versions.

is your job to write code or develop software that works?

have fun keeping a job doing 1/3 the work of people getting paid the same as you :)

I’m from Europe, so I’ll do just that. Thankfully labor laws are strong enough here to withstand this absurdity.

why does every AI skeptic assume that everyone is lying to them. theres millions of developers using AI to be more productive and you just keep plugging your ears and screaming, claiming its only dumb managers, meanwhile Linus Torvalds is vibe coding stuff.

Who said anything about that? The argument was "if you're not using AI RIGHT NOW, you will fall behind forever"

This is the nonsense management and CTOs are pushing. Use it now if you want, I do. Wait for things to cool down if you want. You'll be fine either way. The comical view that it'll be a "winner takes all" subset of developers who some how would have figured out secret AI techniques that make them 10Kx more productive and every other developer will be SOL is laughable.

knowing how to properly use AI is a skill, there are new tools, new patterns, new primitives etc. you will be unpracticed.

i agree, and its strange that this failure mode continually gets lumped onto AI. The whole point of longer term software engineering was to make it so that the context within a particular persons head should not impact the ability of a new employee to contribute to a codebase. turns out everything we do to make sure that is the case for a human also works for an agent.

As far as i can tell, the only reason AI agents currently fail is because they dont have access to the undocumented context inside of peoples heads and if we can just properly put that in text somehwere there will be no problems.

The failure mode is getting lumped into AI because AI is a lot more likely to fail.

We've done this with Neural Networks v1, Expert Systems, Neural Networks v2, SVM, etc, etc. only a matter of time before we figured it out with deep neural networks. Clearly getting closer with every cycle, but no telling how many cycles we have left because there is no sound theoretical framework.

At the same time, we have spent a large part of the existence of civilisation figuring out organisational structures and methods to create resilient processes using unreliable humans, and it turns out a lot of those methods also work on agents. People just often seem miffed that they have to apply them on computers too.

yeah, thats why people just use Teams

> This is entirely too charitable. Basically all this proves is that the agent could run in a loop for a week or so, did anyone doubt that?

yes, every AI skeptic publicly doubted that right up until they started doing it.

so 99% of all software?

Exactly. That's why you see so many people say it works great. And the rest of us are like "am I the crazy one?" No, you just don't build CRUD apps.

youre verifying std lib function call counts in unit tests? lmao.

i know you could do it, im asking why on earth you would feel its vital to verify stream.filter() was called twice in a function

You're not verifying the observable behavior of your application? lmao

How would you suggest tests around:

    void func() {
        printEvens(someCall().stream().filter(n -> n % 2 == 0).toList());
    }

    void printEvens(List<Integer> nums) {
        nums.stream().filter(n -> n % 2 == 0).forEach(n -> System.out.println(n));
    }

The first filter is redundant in this example. Duplicate code checkers are checking for exactly matching lines.

I am unaware of any linter or static analyzer that would flag this.

What's more, unit tests to test the code for printEvens (there exists one) pass because they're working properly... and the unit test that calls the calling function passes because it is working properly too.

Alternatively, write the failing test for this code.

Idk how exactly to do it in cpp becasue I'm not familiar with the tooling

You could write a test that makes sure the output of someCall is passed directly to printeven without being modified.

The example as you wrote is hard to test in general. It's probably not something you would write if your serious about testing.

In C++, the code would look like:

    #include <vector>
    #include <iostream>
    #include <algorithm>

    std::vector<int> someCall()
    {
        return {1, 2, 3, 4, 5, 6, 7, 8, 9, 10};
    }

    void printEvens(const std::vector<int>& nums)
    {
        std::ranges::for_each(nums, [](int n)
        {
            if (n % 2 == 0)
            {
                std::cout << n << '\n';
            }
        });
    }

    int main()
    {
        std::vector<int> data = someCall();
        std::vector<int> tmp;

        std::ranges::copy_if(data,
                             std::back_inserter(tmp),
                             [](int n) { return n % 2 == 0; }
        );
    
        printEvens(tmp);
        return 0;
    }

---

Nothing in there is wrong. There is no test that would fail short of going through the hassle of creating a new type that does some sort of introspection of its call stack to verify which function its being called in.

Likewise, identify if a linter or other static analysis tool could catch this issue.

Yes, this is a contrived example and it likely isn't idiomatic C++ (C++ isn't my 'native' language). The actual code in Java was more complex and had a lot more going on in other parts of the files. However, it should serve to show that there isn't a test for printEvens or someCall that would fail because it was filtered twice. Additionally, it should show that a linter or other static analysis wouldn't catch the problem (I would be rather impressed with one that did).

From ChatGPT a code review of the code: https://chatgpt.com/share/69780ce6-03e0-8011-a488-e9f3f8173f...

> You could write a test that makes sure the output of someCall is passed directly to printeven without being modified.

But why would anyone ever do that? There's nothing incorrect about the code, it's just less efficient than it should be. There's no reason to limit calls to printEven to accept only output from someCall.

A redundant filter() isn't observable (except in execution time).

You could pick it up if you were to explicitly track whether it's being called redundantly but it'd be very hard and by the time you'd thought of doing that you'd certainly have already manually checked the code for it.

what happened to not testing implementation details?