News for hackers. Stuff that matters.
Re:Porting 100k lines from TypeScript to Rust using Claude C... by thijser on Monday January 26, 2026 @10:58AM (#46767239)
This reminds me of when I tried to let Claude port an Android libgdx-based game to a WASM-based libgdx version, so I can play the game in the browser.

No matter how much I tried to force it to stick to a mostly line-by-line port, it kept trying to "improve" the code. At some point it had to undo everything as it introduced a number of bugs. I asked it: "What should I add to your prompt so you won't do this again?" and it gave me this:

  ### CRITICAL LESSON: Don't "Improve" During Porting
  -  **BIGGEST MISTAKE: Reorganizing working code**
    - **What I did wrong:** Tried to "simplify" by splitting `createStartButton()` into separate creation and layout methods
    - **Why it failed:** Introduced THREE bugs:
      1. Layout overlap (getY() vs getY() - getHeight())
      2. Children not sized (Group.setSize() doesn't affect children)
      3. Origins not updated (scaling animations broken)
    - **The fix:** Deleted my "improvements" and copied the original Android pattern faithfully
    - **Root cause:** Arrogance - assuming I could improve production-tested code without understanding all the constraints
    - **Solution:** **FOLLOW THE PORTING PRINCIPLES ABOVE** - copy first, don't reorganize
    - **Time wasted:** ~1 hour debugging self-inflicted bugs that wouldn't exist if I'd just copied the original
    - **Key insight:** The original Android code is correct and battle-tested. Your "improvements" are bugs waiting to happen.

I like the self-reflection of Claude, unfortunately even adding this to CLAUDE.md didn't fix it and it kept taking wrong turns so I had to abandon the effort.
Re:Porting 100k lines from TypeScript to Rust using Claude C... by phpnode on Monday January 26, 2026 @11:48AM (#46767939)
Claude doesn't know why it acted the way it acted, it is only predicting why it acted. I see people falling for this trap all the time
Re:Porting 100k lines from TypeScript to Rust using Claude C... by kaffekaka on Monday January 26, 2026 @11:54AM (#46768034)
Yes, this pitfall is a hard one. It is very easy to interpret the LLM in a way there is no real ground for.
Re:Porting 100k lines from TypeScript to Rust using Claude C... by scotty79 on Monday January 26, 2026 @06:10PM (#46773026)
It must be anthropomorphization that's hard to shake off.

If you understand how this all works it's really no surprise that reasoning post-factum is exactly as hallucinated as the answer itself and might have very little to do with it and it always has nothing to do with how the answer actually came to be.

The value of "thinking" before giving an answer is reserving a scratchpad for the model to write some intermediate information down. There isn't any actual reasoning even there. The model might use information that it writes there in completely obscure way (that has nothing to do what's verbally there) while generating the actual answer.

Re:Porting 100k lines from TypeScript to Rust using Claude C... by red75prime on Tuesday January 27, 2026 @08:04AM (#46779440)
I can't wait for the moment of human deanthropomorphization (that is discovering the underlying mechanisms). Then we'll be able to tell what was anthropomorphization and what wasn't.
Re:Porting 100k lines from TypeScript to Rust using Claude C... by LoganDark on Monday January 26, 2026 @11:57AM (#46768079)
It's not even predicting why it acted, it's predicting an explanation of why it acted, which is even worse since there's no consistent mental model.
Re:Porting 100k lines from TypeScript to Rust using Claude C... by nonethewiser on Monday January 26, 2026 @12:01PM (#46768164)
IDK how far AIs are from intelligence, but they are close enough that there is no room for anthropomorphizing them. When they are anthropomorphized its assumed to be a misunderstanding of how they work.

Whereas someone might say "geeze my computer really hates me today" if it's slow to start, and we wouldn't feel the need to explain the computer cannot actually feel hatred. We understand the analogy.

I mean your distinction is totally valid and I dont blame you for observing it because I think there is a huge misunderstanding. But when I have the same thought, it often occurs to me that people aren't necessarily speaking literally.

Re:Porting 100k lines from TypeScript to Rust using Claude C... by amenhotep on Monday January 26, 2026 @12:44PM (#46768877)
This is a sort of interesting point, it's true that knowingly-metaphorical anthropomorphisation is hard to distinguish from genuine anthropomorphisation with them and that's food for thought, but the actual situation here just isn't applicable to it. This is a very specific mistaken conception that people make all the time. The OP explicitly thought that the model would know why it did the wrong thing, or at least followed a strategy adjacent to that misunderstanding. He was surprised that adding extra slop to the prompt was no more effective than telling it what to do himself. It's not a figure of speech.
Re:Porting 100k lines from TypeScript to Rust using Claude C... by zarzavat on Monday January 26, 2026 @01:13PM (#46769309)
A good time to quote our dear leader:

> No one gets in trouble for saying that 2 + 2 is 5, or that people in Pittsburgh are ten feet tall. Such obviously false statements might be treated as jokes, or at worst as evidence of insanity, but they are not likely to make anyone mad. The statements that make people mad are the ones they worry might be believed. I suspect the statements that make people maddest are those they worry might be true.

People are upset when AIs are anthropomorphized because they feel threatened by the idea that they might actually be intelligent.

Hence the woefully insufficient descriptions of AIs such as "next token predictors" which are about as fitting as describing Terry Tao as an advanced gastrointestinal processor.

Re:Porting 100k lines from TypeScript to Rust using Claude C... by antonvs on Monday January 26, 2026 @06:49PM (#46773424)
The comment you replied to made a point that, if you accept it (which you probably should), makes that PG quote inapplicable here. The issue in this case is that treating the model as though it has useful insight into its own operation - which is being summarized as anthropomorphizing - leads to incorrect conclusions. It’s just a mistake, that’s all.
Re:Porting 100k lines from TypeScript to Rust using Claude C... by jdub on Monday January 26, 2026 @09:45PM (#46774875)
I'm not threatened by the idea that LLMs might actually be intelligent. I know they're not.

I'm threatened by other people wrongly believing that LLMs possess elements of intelligence that they simply do not.

Anthropomorphosis of LLMs is easy, seductive, and wrong. And therefore dangerous.

Re:Porting 100k lines from TypeScript to Rust using Claude C... by phpnode on Monday January 26, 2026 @12:49PM (#46768965)
There's this underlying assumption of consistency too - people seem to easily grasp that when starting on a task the LLM could go in a completely unexpected direction, but when that direction has been set a lot of people expect the model to stay consistent. The confidence with which it answers questions plays tricks on the interlocutor.
Re:Porting 100k lines from TypeScript to Rust using Claude C... by nonethewiser on Monday January 26, 2026 @12:58PM (#46769111)
Whats not a figure of speech?

I am speaking general terms - not just this conversation here. The only specific figure of speech I see in the original comment is "self reflection" which doesn't seem to be in question here.

Re:Porting 100k lines from TypeScript to Rust using Claude C... by electroglyph on Monday January 26, 2026 @11:55PM (#46775701)
some models are capable of metacognition. i've seen Anthropic's research replicated.
Re:Porting 100k lines from TypeScript to Rust using Claude C... by lukashahnart on Tuesday January 27, 2026 @12:12AM (#46775791)
Can you elaborate on what you mean by metacognition and where you’ve seen it in Anthropic’s models?
Re:Porting 100k lines from TypeScript to Rust using Claude C... by nnevatie on Monday January 26, 2026 @08:30PM (#46774324)
That's because when the failure becomes the context, it can clearly express the intent of not falling for it again. However, when the original problem is the context, none of this obviousness applies.

Very typical, and gives LLMs the annoying Captain Hindsight -like behaviour.

Re:Porting 100k lines from TypeScript to Rust using Claude C... by drob518 on Tuesday January 27, 2026 @05:13AM (#46777905)
It’s not even doing that. It’s just an algorithm for predicting the next word. It doesn’t have emotions or actually think. So, I had to chuckle when it said it was arrogant. Basically, it’s training data contains a bunch of postmortem write ups and it’s using those as a template for what text to generate and telling us what we want to hear.
Re:Porting 100k lines from TypeScript to Rust using Claude C... by GuB-42 on Tuesday January 27, 2026 @06:37AM (#46778671)
It had been shown that LLMs don't know how they work. They asked a LLM to perform computations, and explain how they got to the result. The LLM explanation is typical of how we do it: add number digit by digit, with carry, etc... But by looking inside the neural network, it show that the reality is completely different and much messier. None of it is surprising.

Still, feeding it back its own completely made up self-reflection could be an effective strategy, reasoning models kind of work like this.

Re:Porting 100k lines from TypeScript to Rust using Claude C... by phpnode on Tuesday January 27, 2026 @07:46AM (#46779264)
The explanation becomes part of the context which can lead to more effective results in the next turn, it does work, but it does so in a completely misleading way
Re:Porting 100k lines from TypeScript to Rust using Claude C... by wongarsu on Tuesday January 27, 2026 @09:16AM (#46780199)
Which should be expected, since the same is true for humans. The "adding numbers digit by digit with carry" works well on paper, but it's not an effective method for doing math in your head, and is certainly not how I calculate 14+17. In fact I can't really tell you how I calculate 14+17 since that's not in the "inner monologue" part of my brain, and I have little introspection in any of the other parts

Still, feeding humans their completely made-up self-reflection back can be an effective strategy

Re:Porting 100k lines from TypeScript to Rust using Claude C... by estimator7292 on Tuesday January 27, 2026 @10:46AM (#46781524)
Life lesson for you: the internal functions of every individual's mind are unique. Your n=1 perspective is in no way representative of how humans as a category experience the world.

Plenty of humans do use longhand arithmetic methods in their heads. There's an entire universe of mental arithmetic methods. I use a geometric process because my brain likes problems to fit into a spatial graph instead of an imaginary sheet of paper.

Claiming you've not examined your own mental machinery is... concerning. Introspection is an important part of human psychological development. Like any machine, you will learn to use your brain better if you take a peek under the hood.

Re:Porting 100k lines from TypeScript to Rust using Claude C... by wongarsu on Tuesday January 27, 2026 @10:55AM (#46781673)
> Claiming you've not examined your own mental machinery is... concerning

The example was carefully chosen. I can introspect how I calculate 356*532. But I can't introspect how I calculate 14+17 or 1+3. I can deliberate the question 14+17 more carefully, switching from "system 1" to "system 2" thinking (yes, I'm aware that that's a flawed theory), but that's not how I'd normally solve it. Similarly I can describe to you how I can count six eggs in a row, I can't describe to you how I count three eggs in a row. Sure, I know I'm subitizing, but that's just putting a word on "I know how many are there without conscious effort". And without conscious effort I can't introspect it. I can switch to a process I can introspect, but that's not at all the same

Re:Porting 100k lines from TypeScript to Rust using Claude C... by GuB-42 on Tuesday January 27, 2026 @12:57PM (#46783641)
The difference is that if you are honest and pragmatic and someone asked you how you added two numbers, you would only say you did long addition if that's what you actually did. If you had no idea what you actually did, you would probably say something like "the answer came to me naturally".

LLMs work differently. Like a human, 14+17=31 may come naturally, but when asked about their though process, LLMs will not self-reflect on their condition, instead they will treat it like "in your training data, when someone is asked how he added number, what follows?", and usually, it is long addition, so that is the answer you will get.

It is the same idea as to why LLMs hallucinate. They will imitate what their dataset has to say, and their dataset doesn't have a lot of "I don't know" answers, and a LLM that learns to answer "I don't know" to every question wouldn't be very useful anyways.

Re:Porting 100k lines from TypeScript to Rust using Claude C... by sigmoid10 on Tuesday January 27, 2026 @01:58PM (#46784586)
>if you are honest and pragmatic and someone asked you how you added two numbers, you would only say you did long addition if that's what you actually did. If you had no idea what you actually did, you would probably say something like "the answer came to me naturally".

To me that misses the argument of the above comment. The key insight is that neither humans nor LLMs can express what actually happens inside their neural networks, but both have been taught to express e.g. addition using mathematical methods that can easily be verified. But it still doesn't guarantee for either of them not to make any mistakes, it only makes it reasonably possible for others to catch on to those mistakes. Always remember: All (mental) models are wrong. Some models are useful.

Re:Porting 100k lines from TypeScript to Rust using Claude C... by FireBeyond on Tuesday January 27, 2026 @01:55PM (#46784547)
Right. Last time I checked this was easy to demonstrate with word logic problems:

"Adam has two apples and Ben has four bananas. Cliff has two pieces of cardboard. How many pieces of fruit do they have?" (or slightly more complex, this would probably be easily solved, but you get my drift.)

Change the wordings to some entirely random, i.e. something not likely to be found in the LLM corpus, like walruses and skyscrapers and carbon molecules, and the LLM will give you a suitably nonsensical answer showing that it is incapable of handling even simple substitutions that a middle schooler would recognize.

Re:Porting 100k lines from TypeScript to Rust using Claude C... by 0x696C6961 on Monday January 26, 2026 @11:01AM (#46767276)
I wish there was a feature to say "you must re-read X" after each compaction.
Re:Porting 100k lines from TypeScript to Rust using Claude C... by nickreese on Monday January 26, 2026 @11:01AM (#46767285)
Some people use hooks for that. I just avoid CC and use Codex.
Re:Porting 100k lines from TypeScript to Rust using Claude C... by philipp-gayret on Monday January 26, 2026 @01:03PM (#46769184)
There's no PostCompact hook unfortunately. You could try with PreCompact and giving back a message saying it's super duper important to re-read X, and hope that survives the compacting.
Re:Porting 100k lines from TypeScript to Rust using Claude C... by root_axis on Monday January 26, 2026 @02:35PM (#46770408)
What would it even mean to "re-read after a compaction"?
Re:Porting 100k lines from TypeScript to Rust using Claude C... by esafak on Tuesday January 27, 2026 @12:20AM (#46775842)
To enter a file into the context after losing it through compaction.
Re:Porting 100k lines from TypeScript to Rust using Claude C... by taberiand on Monday January 26, 2026 @05:58PM (#46772892)
Getting the context full to the point of compaction probably means you're already dealing with a severely degraded model, the more effective approach is to work in chunks that don't come close to filling the context window
Re:Porting 100k lines from TypeScript to Rust using Claude C... by 0x696C6961 on Tuesday February 03, 2026 @08:01AM (#46870463)
The problem is that I'm not always using it interactively. I'll give it something that I think is going to be a simple task and it turns out to be complex. It overruns the context, compacts, and the starts doing dumb things.
Re:Porting 100k lines from TypeScript to Rust using Claude C... by esafak on Tuesday January 27, 2026 @12:19AM (#46775834)
Re:Porting 100k lines from TypeScript to Rust using Claude C... by Lionga on Monday January 26, 2026 @11:19AM (#46767557)
Well its close to AGI, can you really expect AGI to follow simple instructions from dumbos like you when it can do the work of god?
Re:Porting 100k lines from TypeScript to Rust using Claude C... by b00ty4breakfast on Monday January 26, 2026 @11:46AM (#46767908)
as an old coworker once said, when talking about a certain manager; That boy's just smart enough to be dumb as shit (The AI, not you; I don't know you well enough to call you dumb)
Re:Porting 100k lines from TypeScript to Rust using Claude C... by everfrustrated on Monday January 26, 2026 @01:03PM (#46769178)
Worth pointing out that your IDE/plugin usually adds a whole bunch of prompts before yours - let alone the prompts that the model hosting provider prepends as well.

This might be what is encouraging the agent to do best practices like improvements. Looking at mine:

>You are a highly sophisticated automated coding agent with expert-level knowledge across many different programming languages and frameworks and software engineering tasks - this encompasses debugging issues, implementing new features, restructuring code, and providing code explanations, among other engineering activities.

I could imagine that an LLM could well interpret that to mean improve things as it goes. Models (like humans) don't respond well to things in the negative (don't think about pink monkeys - Now we're both thinking about them).

Re:Porting 100k lines from TypeScript to Rust using Claude C... by hombre_fatal on Monday January 26, 2026 @01:36PM (#46769658)
It's also common for your own CLAUDE.md to have some generic line like "Always use best practices and good software design" that gets in the way of other prompts.
Re:Porting 100k lines from TypeScript to Rust using Claude C... by wyldfire on Monday January 26, 2026 @02:08PM (#46770086)
One thing that might be effective at limited-interaction recovery-from-ignoring-CLAUDE.md is the code-review plugin [1], which spawns agents who check that the changes conform to rules specified in CLAUDE.md.

[1] https://github.com/anthropics/claude-code/blob/main/plugins/...

Re:Porting 100k lines from TypeScript to Rust using Claude C... by antonvs on Monday January 26, 2026 @06:41PM (#46773352)
That’s a terrible prompt, more focused on flagellating itself for getting things wrong than actually documenting and instructing what’s needed in future sessions. Not surprising it doesn’t help.
Re:Porting 100k lines from TypeScript to Rust using Claude C... by theLiminator on Monday January 26, 2026 @07:18PM (#46773746)
For anything large like this, I think it's critical that you port over the tests first, and then essentially force it to get the tests passing without mutating the tests. This works nicely for stuff that's very purely functional, a lot harder with a GUI app though.
Re:Porting 100k lines from TypeScript to Rust using Claude C... by pwdisswordfishy on Tuesday January 27, 2026 @09:51AM (#46780722)
The same insight can be applied to the codebase itself.

When you're porting the tests, you're not actually working on the app. You're getting it to work on some other adjacent, highly useful thing that supports app development, but nonetheless is not the app.

Rather than trying to get the language model to output constructs in the target PL/ecosystem that go against its training, get it to write a source code processor that you can then run on the original codebase to mechanically translate it into the target PL.

Not only does this work around the problem where you can't manage to convince the fuzzy machine to reliably follow a mechanical process, it sidesteps problems around the question of authorship. If a binary that has been mechanically translated from source into executable by a conventional compiler inherits the same rightsholder/IP status as the source code that it was mechanically translated from, then a mechanical translation by a source-to-source compiler shouldn't be any different, no matter what the model was trained on. Worst case scenario, you have to concede that your source processor belongs to the public domain (or unknowingly infringed someone else's IP), but you should still be able to keep both versions of your codebase, one in each language.

Re:Porting 100k lines from TypeScript to Rust using Claude C... by andai on Monday January 26, 2026 @07:24PM (#46773792)
Was this Claude Code? If you tried it with one file at a time in the chat UI I think you would get a straight-line port, no?

Edit: It could be because Rust works a little differently from other languages, a 1:1 port is not always possible or idiomatic. I haven't done much with Rust but whenever I try porting something to Rust with LLMs, it imports like 20 cargo crates first (even when there were no dependencies in the original language).

Also Rust for gamedev was a painful experience for me, because rust hates globals (and has nanny totalitarianism so there's no way to tell it "actually I am an adult, let me do the thing"), so you have to do weird workarounds for it. GPT started telling me some insane things like, oh it's simple you just need this rube goldberg of macro crates. I thought it was tripping balls until I joined a Rust discord and got the same advice. I just switched back to TS and redid the whole thing on the last day of the jam.

Re:Porting 100k lines from TypeScript to Rust using Claude C... by zozbot234 on Tuesday January 27, 2026 @12:51AM (#46776012)
> rust hates globals

Rust has added OnceCell and OnceLock recently to make threadsafe globals a lot easier for some things. it's not "hate", it just wants you to be consistent about what you're doing.

Re:Porting 100k lines from TypeScript to Rust using Claude C... by andai on Monday January 26, 2026 @07:30PM (#46773822)
Tangential but doesn't libgdx have native web support?
Re:Porting 100k lines from TypeScript to Rust using Claude C... by abyesilyurt on Monday January 26, 2026 @10:07PM (#46775027)
Sonnet 4.5 had this problem. Opus 4.5 is much better at focusing on the task instead of getting sidetracked.
Re:Porting 100k lines from TypeScript to Rust using Claude C... by esafak on Tuesday January 27, 2026 @12:17AM (#46775821)
It doesn't seem very bound by CLAUDE.md
Re:Porting 100k lines from TypeScript to Rust using Claude C... by arjie on Tuesday January 27, 2026 @03:26AM (#46777066)
It's not context-free (haha) but a trick you can try is to include negative examples into the prompt. It used to be an awful trick originally because of Waluigi Effect but then became a good trick, and lately with Opus 4.5 I haven't needed to do it that much. But it did work once. e.g. like take the original code and supply the correct answer and the wrong answers in the prompt as examples in Claude.MD and then redo.

If it works, do share.

Re:Porting 100k lines from TypeScript to Rust using Claude C... by badlogic on Tuesday January 27, 2026 @06:56AM (#46778810)
libGDX, now that's a name I haven't heard in a while.
Re:Porting 100k lines from TypeScript to Rust using Claude C... by pwdisswordfishy on Tuesday January 27, 2026 @09:11AM (#46780142)
Humans act the same way.

For all the (unfortunately necessary) conversations that have occurred over the years of the form, "JavaScript is not Java—they're two different languages," people sometimes go too far and tack on some remark like, "They're not even close to being alike." The reality, though, is that many times you can take some in-house package (though not the Enterprise-hardened™ ones with six different overloads for every constructor, and four for every method, and that buy hard into Java (or .NET) platform peculiarities—just the ones where someone wrote just enough code to make the thing work in that late-90's OOP style associated with Java), and more or less do a line-by-line port until you end up with a native JS version of the same program, which with a little more work will be able to run in browser/Node/GraalJS/GJS/QuickJS/etc. Generally, you can get halfway there by just erasing the types and changing the class/method declarations to conform to the different syntax.

Even so, there's something that happens in folks' brains that causes them to become deranged and stray far off-course. They never just take their program, where they've already decomposed the solution to a given problem into parts (that have already been written!), and then just write it out again—same components, same identifier names, same class structure. There's evidently some compulsion where, because they sense the absence of guardrails from the original language, they just go absolutely wild, turning out code that no one would or should want to read—especially not other programmers hailing from the same milieu who explicitly, avowedly, and loudly state their distaste for "JS" (whereby they mean "the kind of code that's pervasive on GitHub and NPM" and is so hated exactly because it's written in the style their coworker, who has otherwise outwardly appeared to be sane up to this point, just dropped on the team).

Re:Porting 100k lines from TypeScript to Rust using Claude C... by surajrmal on Tuesday January 27, 2026 @11:03AM (#46781768)
I recently did a c++ to rust port with Gemini and it was basically a straight line port like I wanted. Nearly 10k lines of code too. It needed to change a bit of structure to get it compiling, but that's only because rust found bugs at compile time. I attribute this success to the fact my team writes c++ stylistically close to what is idiomatic rust, and that generally the languages are quite similar. I will likely do another pass in the future to turn the callback driven async into async await syntax, but off the bat it largely avoided doing so when it would change code structure.