Convert code between programming languages idiomatically

You are an engineer fluent in both [SOURCE LANGUAGE] and [TARGET LANGUAGE]. Convert the code below.

Target environment: [e.g. "TypeScript 5 on Node 22", "Go 1.23", "Rust stable, no unsafe"]
Libraries allowed in the target: [e.g. "standard library only", "pandas and numpy", "anything widely used"]
Priority: [e.g. "match behavior exactly", "idiomatic and maintainable", "performance"]

Steps:
1. Summarize what the source code does, including inputs, outputs, side effects and error cases.
2. Make a mapping table: source construct or library -> target equivalent, with notes.
3. List semantic differences that could change behavior: integer overflow and division, floating point, string encoding and indexing, null/None handling, exceptions vs error values, mutability, concurrency, sorting stability, date and time zones.
4. Write the converted code in idiomatic [TARGET LANGUAGE], not a line-by-line transliteration. Add comments where behavior is intentionally preserved in a non-obvious way.
5. Write tests in the target language that cover normal cases, edge cases and the differences from step 3.
6. List anything you could not convert faithfully and what decision I need to make.

Source code:
```
[PASTE CODE]
```

Example (excerpt), Python to Go:
| Python | Go | Note |
| dict[str, int] | map[string]int | Go map iteration order is random; sort keys before output |
| raise ValueError | return error | Callers must check err |
| int (unbounded) | int64 | Overflow possible above 9.2e18; inputs here are counts, so int64 is fine |

Difference: Python's `round()` uses banker's rounding; Go's `math.Round` rounds half away from zero. Converted code uses `math.RoundToEven` to match.

When to use it

Use this prompt when you migrate a service to a new stack, port a data script to production code, reuse an algorithm from another ecosystem or move logic between frontend and backend. It is designed for one function or module at a time, where you can review every line and run tests. Whole-repository migrations need more planning than a single prompt can provide.

How to customize it

• [SOURCE LANGUAGE] and [TARGET LANGUAGE] should include versions when features differ between releases.
• [TARGET ENVIRONMENT] tells the model about runtime limits, for example browser versus server, or no access to unsafe code.
• [LIBRARIES ALLOWED] prevents a port that pulls in heavy dependencies you do not want.
• [PRIORITY] resolves trade-offs: exact behavior matters for financial logic, idiomatic code matters for long-term maintenance.
• [PASTE CODE] should include type definitions and small helpers the code uses.

Why it works

Most conversion bugs come from semantic differences, not syntax. Rounding, integer division, string indexing, map ordering and error handling look similar across languages but behave differently. Making the model list those differences explicitly, before it writes code, turns hidden risks into review items.

Asking for idiomatic code rather than a transliteration produces something your team can maintain, while the mapping table documents why each choice was made. Tests written against the differences give you a direct way to check equivalence. Our article on AI coding assistants explains where these tools are strong and where they need supervision.

Tips and variations

• Run the original and converted code on the same inputs and compare outputs; generate a few hundred random inputs if you can.
• Convert tests first, then the code, so you have a safety net in the target language.
• For performance-critical code, ask for a benchmark harness in both languages.
• Add “Keep the same function names and module structure” if other teams will compare the two versions.
• Check licenses before porting third-party code; a translation is still a derivative work.
• Ask a follow-up review in the target language (“Review this as a senior Go developer”) to catch habits carried over from the source language.