Hacker News Reader

Comment by onion2k | Hacker News Reader

Porting something to a language you don't know doesn't seem very helpful to me. You've locked yourself out of doing useful work except with continued application of more AI. Without the ability to verify it, except with even more AI maybe, you're starting on a slippy slope to slop.

If the experiment was "spend 400 bucks to see if it'll work" then that's awesome, and fun, and a cool use of AI. It's impressive that AI can do that.

If it was to make something useful ... has it?

View on HN

You are correct, that this is not the best Rust learning material.

$400 are subsidized into the subscription, and this was mainly an experiment to prove the theory about data conversion step. I call it a success and I use rune editor daily.

To me, running multiple agents is not very different from managing multiple teams — I won't be able to keep up with the changes by reading the code.

I may make certain architectural decision, and I need to act based on some signals.

The simplest example is clusters of bugs are signaling that certain modules are dirty. Sometimes I read a plan and understand that the agent is trying to workaround some auwful engineering.

I work on a C++ codebase. I frequently prototype in c and then have the ai model slopify it back to c++. Nice b/c I am faster at reading c, but hard b/c you miss some of the features/nuances of c++.

I would be afraid to do this with C++.

My friend once sent me a snippet, maybe 10 lines of C+++, asking "can you spot the UB?".

So I'm staring at these 10 lines, I KNOW there is an UB. I wasn't able to find it without a hint.

Was it the one with the elided null check?

I don't remember the details, roughly it was unexpected invocation of move semantic, causing use after free in a loop.

My all-time favourite example is (again, my memory, I may be a bit wrong):

    for (int i = 0; i < (size_t)limit; ++i) {
    }

at some point limit could potentially become greater than INT_MAX, the compiler decided that i<limit could never be true because that would cause signed int overflow which is UB, so it "optimized" the loop into

   while(true)

signed unsigned mismatch makes me shiver

The compiler cannot optimize that into `while(true)` because the original code does not encounter undefined behavior when `limit` is small enough to fit into `int`. What it can do: infer that `limit <= INT_MAX` and use that to optimize the code following after the loop (and in some cases, even the code before the loop).

This isn't complete example. I don't remember the details unfortunately.

But somehow compiler has decided that i <= limit is always true.

interesting, c -> c++ transition should be smooth though

Reply on news.ycombinator.com