Translate Code From One Language to Another
Convert code between programming languages while using idiomatic patterns in the target language.
This prompt converts a working piece of code from one programming language to another while insisting on idiomatic target-language style rather than a clumsy line-for-line port. It's the tool to reach for when migrating a script, prototyping in a new stack, or porting a library helper you don't want to rewrite from scratch. The instruction to flag library substitutions and annotate judgment calls is the important part — it surfaces exactly the places where a translation can silently change behavior.
Translate the code below from [SOURCE LANGUAGE] to [TARGET LANGUAGE]. (1) Preserve all logic and behavior exactly. (2) Use idiomatic [TARGET LANGUAGE] patterns — don't just do a literal translation. (3) Replace library calls with the closest [TARGET LANGUAGE] equivalent and note any differences. (4) Add a comment anywhere the translation required a meaningful decision. SOURCE CODE: [PASTE CODE]
What you can expect back
package config
import (
"encoding/json"
"os"
"strings"
)
// LoadConfig reads a JSON file and returns its keys lowercased.
// Note: Python dicts preserve insertion order; Go maps do not, so
// don't rely on key ordering downstream.
func LoadConfig(path string) (map[string]any, error) {
raw, err := os.ReadFile(path)
if err != nil {
return nil, err // Go returns errors explicitly instead of raising
}
var data map[string]any
if err := json.Unmarshal(raw, &data); err != nil {
return nil, err
}
out := make(map[string]any, len(data))
for k, v := range data {
out[strings.ToLower(k)] = v
}
return out, nil
}
Key differences:
- Python's implicit exceptions become explicit (error) return values.
- json.load -> json.Unmarshal, which needs the bytes read first via os.ReadFile.
- The dict comprehension becomes a plain range loop; Go has no comprehensions.Illustrative example — your results will vary by tool and inputs.
Get sharper results
- 01Include the imports and any helper functions the snippet calls, otherwise the model has to guess at the library behavior it's replacing.
- 02Name exact versions when behavior differs across them (Python 2 vs 3, Java 8 vs 21) so the model picks the right idioms and standard-library APIs.
- 03Ask it to also translate the tests, or to write target-language tests, so you can confirm behavior actually matches rather than trusting the port by eye.
- 04When the source relies on a third-party package, tell the model which target ecosystem library you prefer, or it may pick one you don't want to add as a dependency.
- 05Watch the 'meaningful decision' comments closely — things like integer division, default mutability, or null handling are where translated code most often diverges.
Adapt it for your case
Drop the idiomatic requirement and ask for the closest possible line-by-line mapping, useful when you need to diff the two versions side by side.
Add 'for each non-trivial line, briefly explain the target-language concept' to use the translation as a learning exercise in the new language.
Call out concurrency explicitly, e.g. 'map Python asyncio to Go goroutines and channels', since concurrency models rarely translate one-to-one.
Common questions
Will the translated code definitely run?
Usually it's close, but you should compile/run and test it — small differences in numeric types, error handling, or library semantics can break behavior even when the code looks correct.
Can it handle whole projects?
Translate file by file or function by function. Feeding an entire repo at once loses cross-file context and the output quality drops sharply.
What about language-specific features with no equivalent?
The model will substitute the nearest pattern and flag it in a comment; review those spots carefully, since that's where logic is most likely to shift.
You may also need
Explain Complex Code in Simple Terms
Turn confusing code into a clear, junior-friendly explanation with edge-case notes.
Generate table-driven unit tests for a function with edge cases
Produces a table-driven unit test suite covering happy paths, boundaries, and error conditions for a given function.
Explain a cryptic regex and rewrite it to be readable
Decodes a confusing regex token by token, surfaces edge cases and backtracking risk, then rewrites it readably.
Decode a stack trace and pinpoint the likely root cause
Reads a stack trace frame by frame to explain the failure and pinpoint the most likely root cause with next steps.