Pith. sign in

REVIEW 4 major objections 6 minor 1 cited by

Scalable, Validated Code Translation of Entire Projects using Large Language Models

T0 review · 4 major / 6 minor · reviewed 2026-08-11 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read This paper claims that LLM translation scales to whole projects when fragments are translated in dependency order, guided by feature-mapping rules and signature-level type-compatibility checks.

desk verdict A real advance in whole-project LLM translation with a clear architecture, but the 73% validation rate is uninterpretable without knowing how many functions are mocks. read the letter →

arxiv 2412.08035 v1 pith:R4DZSVMT submitted 2024-12-11 cs.PL cs.SE

Hanliang Zhang , Cristina David , Meng Wang , Brandon Paulsen , Daniel Kroening This is my paper · ORCID
classification cs.PLcs.SE
keywords codetranslationlargelanguagemodelsGotoRustI/Oequivalencetypecompatibilityfeaturemappingmodularprogramrepair
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

The paper claims that LLM-based translation of entire software projects, not just small snippets, can be made reliable by cutting the project into small fragments, translating them in dependency order, and checking each fragment locally before moving on. To make those local checks effective, it introduces feature mapping, which pairs the LLM with predefined translation rules and static checks for language features that do not map directly, and type-compatibility, which verifies at function-signature level that every value the original program can actually produce can cross into the translated type and back. Applied to seven Go projects translated to Rust, the largest at 6,600 lines and 369 functions, the approach compiles about 99% of the translated code and validates I/O equivalence for an average of 73% of functions on input-output examples drawn from the original test suite. If correct, this means whole-repository translation with LLMs can be practical and mostly verified, rather than a source of compilable but semantically broken code.

What carries the argument

The carrying mechanism is a post-order traversal over a dependency graph of code fragments, where each fragment must pass feature-mapping checks and a type-compatibility check before the next fragment is translated. Feature-mapping rules are triples: a syntactic pattern that detects when a rule applies, a natural-language instruction given to the LLM, and static checks that the generated code uses the expected Rust construct. Type-compatibility is checked by serializing execution-snapshot values to JSON and requiring lossless round-trips through the target type, with function signatures checked the same way. This makes errors detectable at the place they are introduced, before they contaminate downstream fragments.

What would settle it

Take a function the pipeline reports as I/O-equivalent and run it on inputs outside the collected test-suite snapshots, for example randomly generated values of the same types or mutations of recorded inputs, then compare Go and Rust outputs; a divergence on any such input would show the validation is restricted to covered behavior rather than full equivalence.

Watch

Extended reading notes

Core claim

The central claim is that the two obstacles to scaling LLM translation—unreliable mappings of source-language features and errors that cascade through interdependent fragments—can be handled by combining a small set of human-written translation rules with signature-level type-compatibility checks. The paper defines type-compatibility through execution snapshots: feasible values of a Go type are those observed when the project's own unit tests run, and a Rust type is compatible if each such value can be serialized to JSON, deserialized into the Rust type, serialized back, and deserialized into the original Go value unchanged. On top of this, feature-mapping rules tell the LLM how to render specific Go constructs such as global initialization, error returns, and structural interfaces in Rust, and the rules are enforced by static checks on the generated code. After a type-driven phase produces a compiling, type-compatible project, a semantics-driven phase checks each function for I/O equivalence on the same snapshots, mocking callees so failures are local. The reported outcome is that almost all source lines compile and, on average, 73% of functions are I/O-equivalent, with every failing test an assertion failure rather than a crash.

Load-bearing premise

The argument treats the input-output examples captured by the project's unit tests as defining the feasible values for type-compatibility and the universe for I/O equivalence; if those examples miss important inputs, a function counted as equivalent can still be wrong.

Editorial extensions

If this is right

  • Whole-repository translation becomes a viable strategy: the largest case has 6,600 lines and 369 functions, far beyond the roughly 100-line ceiling reported for direct LLM translation.
  • Because type-compatibility is checked before semantics, translation can proceed even when a function cannot be made to compile: it is mocked by calling the original Go function through a boundary, so the rest of the project is not blocked.
  • The same pipeline yields a regression test suite for the translated code, since every I/O-equivalent function has concrete input-output examples that can be replayed as Rust unit tests.
  • Failing unit tests in the translated projects are assertion failures rather than crashes, which lets the pipeline attribute each failure to a specific function and keep repairs local.
  • The approach is described as agnostic to the language pair, so the feature-mapping and type-compatibility machinery could be instantiated for other source and target languages, not only Go-to-Rust.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • One implication the paper leaves implicit is that the equivalence rate is measured only on snapshots from the original test suite, so the 73% figure should be read as validated on covered behavior; the paper itself counts uncovered functions as automatically failing, and statement coverage ranges from 43.2% to 100%.
  • A natural strengthening would be to add differential fuzzing after the pipeline: the same JSON round-trip harness used for type-compatibility could feed random or mutated inputs to both versions, turning validation from example-based into property-based.
  • Because the tool logs LLM inputs and outputs and supports replaying them, the pipeline is deterministic for a fixed log, which makes the evaluation reproducible and makes future LLM improvements directly comparable on the same benchmarks.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

4 major / 6 minor

Summary. The paper presents Oxidizer, a tool for translating entire Go projects to Rust using LLMs. The approach partitions a project into fragments (functions, types, globals), orders them by a dependency graph, and translates each fragment with the help of (i) hand-written feature mapping rules that constrain the LLM's handling of Go/Rust language differences, and (ii) type-compatibility checks that compare function and type signatures against execution snapshots collected from the project's own unit tests. A second phase checks I/O equivalence on those snapshots and repairs failing functions while freezing signatures. The evaluation on seven open-source Go projects reports that, on average, 99% of the code compiles and 73% of functions are validated as I/O equivalent, with ablation experiments suggesting that feature mapping is essential for progress and that type-compatibility improves equivalence rates.

Significance. If the reported numbers are taken at face value, this is a strong result for whole-project LLM-based translation: it substantially exceeds the equivalence rates reported by parallel work and, unlike earlier snippet-level approaches, it scales to a 6.6K-line / 369-function project. The two proposed mechanisms, feature mapping and type-compatibility, are clearly described and the ablation supports their importance. The paper also ships concrete reproducibility aids: it logs LLM inputs and outputs and can replay translation runs deterministically, and the feature mapping rules are specified enough to be re-implemented. The main value is in showing that a hybrid of symbolic rules, type-level checks, and modular LLM translation can make whole-project translation practical. The evaluation is honest about the V-relative nature of the validation in the body of the paper, but the abstract and headline metrics are easy to over-read as semantic equivalence on all inputs, and the reported rates do not separate mocked functions from genuinely translated ones.

major comments (4)
  1. The I/O equivalence relation is defined 'with respect to V', where V is the set of input/output/error tuples collected by running the source project's unit tests, and the paper states that functions without collected examples receive an automatically failing unit test. Consequently, the headline '% Equivalent' is a pass rate on the project's own test-suite inputs, not a statement of semantic equivalence on all inputs. A function can be wrong on any input outside V and still be counted as validated. The abstract's phrase 'reliable Rust translations' is therefore stronger than what the validation establishes. Please either qualify the abstract and conclusion to state that validation is on test-suite-derived examples, or add a held-out evaluation (e.g., differential fuzzing or a second test set) to show that the 73% rate generalizes. In addition, Table 1's statement coverage ranges from 43.2% to 100%, so per-benchmark and per-function snapshot counts should be reported so the reader can see how many examples underpin each function's validation.
  2. The reported '% Compiled' and '% Equivalent' figures do not disclose how many functions in each benchmark ended up as mocks, i.e., functions whose bodies are replaced by a call to the original Go function through the Go-Rust boundary. A mocked function compiles by construction and is trivially I/O equivalent to the original, so including mocks in both metrics inflates the headline numbers and conflates 'translated and validated' with 'not actually translated'. The text admits that the output 'may have some function/method bodies replaced with mocks' (§7.1.1), but Table 2 gives no mock counts. Please report for each benchmark the number of functions that were mocked, and give the % Equivalent computed both including and excluding mocks. Without this breakdown, the central claim that 73% of functions were successfully translated and validated cannot be assessed.
  3. The I/O equivalence check for functions compares serialized return values and errors, but the definition overloads the output y' to be 'an extension of the actual output that accounts for possible side-effects'. The paper never specifies how side effects are collected in the execution snapshots or how they are compared between Go and Rust. If side effects (mutations to receiver fields, global variables, I/O, or other observable state) are not captured in the snapshots, then two functions that differ only in such state will be incorrectly reported as equivalent. Please provide the concrete collection mechanism for side effects, or explicitly state that the validity of the equivalence check is limited to return values and errors, and adjust the claims accordingly.
  4. The benchmark selection is restricted to projects that 'only make use of Go standard libraries', and the paper notes that third-party libraries were deliberately excluded from the evaluation. This limits the generalizability of the claim that Oxidizer translates 'real-world Go codebases': a substantial fraction of real Go projects depend on third-party packages, and the authors even acknowledge that their approach supports such dependencies (§5.1) but do not demonstrate it. Please state explicitly that the reported results are for a curated subset of Go projects without third-party dependencies, and discuss what additional validation would be needed to support the broader 'entire project' claim.
minor comments (6)
  1. The formal rule notation in Figures 7 and 10 is difficult to read because of rendering artifacts (e.g., 'D/uni∈1A6.endl→code' and the ⇓/↝ symbols appear corrupted in the PDF). Please re-set these judgments in clean LaTeX so the premises and conclusions are legible.
  2. The round-tripping property for JSON serialization is stated as an assumption, but some Go types (e.g., channels, function values, cyclic data structures, or fields with unexported components) are not naturally JSON-serializable. Please state which types are assumed to be serializable and how the presented benchmarks avoid these cases.
  3. The logging-and-replay mechanism is a strong reproducibility feature, but the paper does not point to a public artifact or repository. Please include an artifact URL or a clear statement of availability, along with the exact prompt templates and version of Claude 3 Sonnet used.
  4. The sentence 'in one case by 144%' is ambiguous: an increase from 29% to 71% can be described as a 144% relative improvement, but the reader may misread it as 144 percentage points. Please restate with the actual before/after numbers.
  5. The notation D_go(S_go(x)) is used to describe input conversion, but the serialization/deserialization functions S and D are introduced only in §5.2; a forward reference or a brief restatement would help the reader.
  6. The claim of being 'considerably higher than any existing work' is based on comparing reported numbers from parallel papers rather than running those tools on the same benchmarks. Please soften this to 'higher than previously reported' or add a direct comparison on a shared benchmark set.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity; the validation metric is explicitly test-suite-relative, which is a stated limitation, not a circular derivation.

full rationale

The paper's central quantitative claim ('an average of 73% of functions successfully validated for I/O equivalence', Abstract and §7.2/Table 2) is explicitly a pass rate on execution snapshots collected from the source project's unit tests. Section 7.1.1 states: 'A unit test passes if and only if all computed outputs match the expected outputs,' and Definition 5 defines I/O equivalence 'with respect to V', where V is the set of input/output/error tuples collected by running the unit tests. This makes the metric test-relative, and the paper itself acknowledges the consequence: functions not covered by unit tests are automatically marked as not equivalent, and Table 1 reports statement coverage as low as 43.2%. That is a limitation on generalization to untested inputs, not a circular derivation: the translated function's outputs are not forced to match by the definitions; the check is an independent empirical comparison over a specified finite set. Type-compatibility (Definition 1) also uses test-suite-derived feasible values, but it is a separate serialization-based check, and no parameter is fitted to the quantity being predicted. Feature-mapping rules are hand-authored external guidance (§4.1), not fitted outputs. The self-citations to prior work by overlapping authors ([15], [16]) support motivation and LLM choice, but they are not load-bearing for the validation result, and no uniqueness theorem or self-citation chain forces the reported outcome. Finding: no significant circularity.

Assumptions & free parameters 4 free parameters · 6 assumptions · 0 invented entities

No fitted physical parameters appear. The load-bearing choices are manually set budgets, hand-authored feature mapping rules, and the assumption that test-suite snapshots stand in for full semantics. The absence of a reported mock count makes these assumptions hard to quantify.

free parameters (4)
  • requery_budget = 10
    Requery budget for FeatureMapping; authors set it 'high enough to reach diminishing returns' in Section 7.1.4, so it is a manual tuning choice for Table 2.
  • max_tries_type_driven = 15
    Maximum attempts per fragment in Algorithm 2; chosen by hand in Section 7.1.4.
  • max_tries_semantics = 5
    Maximum attempts per fragment in Algorithm 3; chosen by hand in Section 7.1.4.
  • temperature = 0.2
    LLM sampling temperature set lower for determinism in Section 7.1.4.
assumptions (6)
  • domain assumption Unit-test execution snapshots define the feasible value set V for type-compatibility (Section 5.2, Definition 1).
    All type and I/O equivalence claims depend on these snapshots; values not exercised by tests are outside the checked domain.
  • domain assumption I/O equivalence with respect to collected snapshots is treated as validation of semantic correctness (Section 6, Definition 5; Section 7.1.1).
    The headline 73% is equivalence on test inputs, not a proof of general equivalence.
  • domain assumption JSON serialization and deserialization round-trip faithfully represents Go and Rust values at the boundary (Section 5.2).
    Definition 1 assumes (D∘S)(v) equals v for both languages, and this property is used by type-compatibility, mocking, and I/O checks.
  • ad hoc to paper Hand-written feature mapping rules cover all Go-to-Rust feature differences that matter (Section 4.1).
    Rules like Lazy::new, anyhow::Error, and trait decomposition are authored by the developers, not learned or derived; correctness of the set is assumed.
  • domain assumption The chosen LLM, Claude 3 Sonnet, is representative of state-of-the-art LLMs (Section 7.1.2).
    No other LLMs are actually evaluated; generalization is inferred from prior work.
  • domain assumption The simplified FeatherweightGo grammar is sufficient to model the real benchmark projects (Section 3).
    Partitioning relies on declarations of globals, types, functions, and methods; complex features outside this model are not considered.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Scalable, Validated Code Translation of Entire Projects using Large Language Models." pith.science (2026). https://pith.science/paper/R4DZSVMT

@misc{pith2026241208035,
  author       = {Pith},
  title        = {Pith review of: Scalable, Validated Code Translation of Entire Projects using Large Language Models},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/R4DZSVMT}},
  note         = {Machine review of arXiv:2412.08035}
}
read the original abstract

Large language models (LLMs) show promise in code translation due to their ability to generate idiomatic code. However, a significant limitation when using LLMs for code translation is scalability: existing works have shown a drop in translation success rates for code exceeding around 100 lines. We overcome this limitation by developing a modular approach to translation, where we partition the code into small code fragments which can be translated independently and semantically validated (that is, checking I/O equivalence). When this approach is applied naively, we discover that LLMs are unreliable when translating features of the source language that do not have a direct mapping to the target language, and that the LLM often gets stuck in repair loops when attempting to fix errors. To address these issues, we introduce two key concepts: (1) feature mapping, which integrates predefined translation rules with LLM-based translation to guide the LLM in navigating subtle language differences and producing semantically accurate code; and (2) type-compatibility, which facilitates localized checks at the function signature level to detect errors early, thereby narrowing the scope of potential repairs. We apply our approach to translating real-world Go codebases to Rust, demonstrating that we can consistently generate reliable Rust translations for projects up to 6,600 lines of code and 369 functions, with an average of 73% of functions successfully validated for I/O equivalence, considerably higher than any existing work.

Figures

Figures reproduced from arXiv: 2412.08035 by the authors.

Figure 1
Figure 1. Source Go code consisting of three files: globals.go [PITH_FULL_IMAGE:figures/full_fig_p004_1.png] view at source ↗
Figure 2
Figure 2. Incorrect Rust translation for the Go code in [PITH_FULL_IMAGE:figures/full_fig_p005_2.png] view at source ↗
Figure 3
Figure 3. Correct Rust translation for the Go code in [PITH_FULL_IMAGE:figures/full_fig_p005_3.png] view at source ↗
Figures from the paper (9 more)
Figure 5
Figure 5. Figure 5: Simplified Rust specification 4 Translating an Individual Code Fragment In this section, we describe the translation of an individual code fragment. In the following sections, we explain translating the entire project. The most critical aspect when translating a code f…
Figure 6
Figure 6. Figure 6: LLM prompt template Next, we compute a summary of the translations for any dependencies of D. This summary is a condensed version of the translated code fragments. It contains function/method signatures with￾out bodies, and it contains type definitions and global varia…
Figure 7
Figure 7. Figure 7: Basic feature mapping The remaining rules in [PITH_FULL_IMAGE:figures/full_fig_p009_7.png]
Figure 9
Figure 9. Figure 9: Incorrect translation to Rust is an interface type containing exactly one method: Error() string. Although custom error types can be constructed separately, they often implement this interface and are passed around as error rather than concrete types. Then, type assert…
Figure 10
Figure 10. Figure 10: Mapping error handling 4.1.3 Mapping Go interfaces to Rust traits. Go interface and Rust trait are similar abstractions in the sense that both achieve polymorphism by defining a collection of methods that get im￾plemented for different types [PITH_FULL_IMAGE:figures/…
Figure 12
Figure 12. Figure 12: Incorrect translation to Rust of individual functions: all the method implementations for an interface must be translated at the same time in order for the code to pass the compiler check. To address these challenges, we propose a target feature that decomposes a trai…
Figure 13
Figure 13. Figure 13: Correct translation of Go interface to Rust trait We follow a similar approach for Batcher, where we reuse the already generated sub-trait can￾Validate_Validate corresponding to method Validate. The main trait Batcher is bounded by the sub-traits canValidate_Validate …
Figure 15
Figure 15. Figure 15: Incorrect translation to Rust pub fn u p d a t e _ r a n k s( ranks : & mut Rank , algorithm : &dyn Algorithm ) { extern " C " { // import original Go function directly fn u p d a t e R a n k s(..) } return u p d a t e R a n k s(..) } [PITH_FULL_IMAGE:figures/full_fi…
Figure 16
Figure 16. Figure 16: Function mock C++, and it is not allowed in Rust. LLMs tend to follow the syntax of the original Go snippet and generate the Rust code in [PITH_FULL_IMAGE:figures/full_fig_p015_16.png]

Discussion (0). Continue with ORCID to comment.

Forward citations

Cited by 1 Pith paper

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score. OpenAlex reports about 2 citations worldwide. Full citation record

  1. Syzygy: Dual Code-Test C to (safe) Rust Translation using LLMs and Dynamic Analysis

    cs.SE 2024-12 conditional novelty 7.0 of 10

    A dual code-and-test generation pipeline with dynamic-analysis specifications translates the 3,000-line Zopfli C library into safe Rust, though the top-level validation compares compression ratios rather than exact outputs.

Reference graph

Works this paper leans on

60 extracted references · 52 canonical work pages · cited by 1 Pith paper

  1. [1]

    Modernization of legacy systems: A general ised roadmap,

    S. Jain and I. Chana, “Modernization of legacy systems: A general ised roadmap, ” inInternational Conference on Com- puter and Communication Technology , ICCCT ’15, p. 62–67, ACM, 2015

    work page 2015

  2. [2]

    How do professionals perceive legacy systems and software modernization?,

    R. Khadka, B. V. Batlajery, A. M. Saeidi, S. Jansen, and J. Hage, “How do professionals perceive legacy systems and software modernization?, ” inInternational Conference on Software Engineering , ICSE 2014, p. 36–47, ACM, 2014

    work page 2014

  3. [3]

    Tools to build on A WS

    “Tools to build on A WS. ” https://aws.amazon.com/developer/tools/. Accessed: 2024-11-05

    work page 2024

  4. [4]

    Cloud SDK: Libraries and command line interface

    “Cloud SDK: Libraries and command line interface. ” https://cloud.google.com/sdk/. Accessed: 2024-11-05

    work page 2024

  5. [5]

    Download Azure SDKs and tools

    “Download Azure SDKs and tools. ” https://azure.microsoft.com/en-us/downloads/. Accessed: 2024-11-05

    work page 2024

  6. [6]

    Eliminating memory safety vulnerabilities once and for all (DARPA)

    “Eliminating memory safety vulnerabilities once and for all (DARPA). ”https://www.darpa.mil/news-events/2024-07-31a

    work page 2024

  7. [7]

    C2Rust transpiler

    “C2Rust transpiler. ” https://c2rust.com/

    work page

  8. [8]

    Ownership guided C to Rust t ranslation,

    H. Zhang, C. David, Y. Yu, and M. Wang, “Ownership guided C to Rust t ranslation, ” inComputer Aided Verification (CA V), vol. 13966 of LNCS, pp. 459–482, Springer, 2023

    work page 2023

Show all 60 references
  1. [9]

    Explain-then-translate: an analysis on improving program translation with self-generated explanations,

    Z. Tang, M. Agarwal, A. Shypula, B. Wang, D. Wijaya, J. Chen, and Y. Kim, “Explain-then-translate: an analysis on improving program translation with self-generated explanations, ” in Findings of the Association for Computational Linguistics: EMNLP 2023, pp. 1741–1788, Associat...

    2023

  2. [10]

    Unsupe rvised translation of programming languages,

    B. Rozière, M. Lachaux, L. Chanussot, and G. Lample, “Unsupe rvised translation of programming languages, ” in NeurIPS, 2020

    2020

  3. [11]

    Leveraging automated unit tests for unsupervised code translation,

    B. Rozière, J. Zhang, F. Charton, M. Harman, G. Synnaeve, and G. L ample, “Leveraging automated unit tests for unsupervised code translation, ” in ICLR, OpenReview.net, 2022

    2022

  4. [12]

    Code translation with compiler representa- tions,

    M. Szafraniec, B. Roziere, H. L. F. Charton, P. Labatut, and G. Synnaeve, “Code translation with compiler representa- tions, ”ICLR, 2023

    2023

  5. [13]

    Rectifier: Code tr anslation with corrector via LLMs,

    X. Yin, C. Ni, T. N. Nguyen, S. Wang, and X. Yang, “Rectifier: Code tr anslation with corrector via LLMs, ” CoRR, vol. abs/2407.07472, 2024

    2024 arXiv

  6. [14]

    Lost in translation: A study of bugs introduced by large la nguage models while translating code,

    R. Pan, A. R. Ibrahimzada, R. Krishna, D. Sankar, L. P. Wassi, M. Merler, B. Sobolev, R. Pavuluri, S. Sinha, and R. Jab- barvand, “Lost in translation: A study of bugs introduced by large la nguage models while translating code, ” 2024

    2024

  7. [15]

    Towards translating real-world code with LLMs: A study of translating to Rust,

    H. F. Eniser, H. Zhang, C. David, M. Wang, M. Christakis, B. Pauls en, J. Dodds, and D. Kroening, “Towards translating real-world code with LLMs: A study of translating to Rust, ” 2024

    2024

  8. [16]

    VERT: Verified equivalent Rust transpilation with large language models as few-shot learners,

    A. Z. H. Yang, Y. Takashima, B. Paulsen, J. Dodds, and D. Kroening , “VERT: Verified equivalent Rust transpilation with large language models as few-shot learners, ” 2024

    2024

  9. [17]

    Repository-level compositional code translation and validation,

    A. R. Ibrahimzada, K. Ke, M. Pawagi, M. S. Abid, R. Pan, S. Sinha, and R. Jabbarvand, “Repository-level compositional code translation and validation, ” 2024

    2024

  10. [18]

    Context-aware code segmentatio n for C-to-Rust translation using large language models,

    M. Shiraishi and T. Shinagawa, “Context-aware code segmentatio n for C-to-Rust translation using large language models, ” 2024

    2024

  11. [19]

    Operational semantics for multi- language programs,

    J. Matthews and R. B. Findler, “Operational semantics for multi- language programs, ” inProceedings of the 34th Annual ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages, POPL ’07, p. 3–10, ACM, 2007

    2007

  12. [20]

    Moov ACH

    “Moov ACH. ” https://github.com/moov-io/ach

  13. [21]

    Featherweight Go,

    R. Griesemer, R. Hu, W. Kokke, J. Lange, I. L. Taylor, B. Toninh o, P. Wadler, and N. Yoshida, “Featherweight Go, ” 2020

    2020

  14. [22]

    Anyhow

    D. Tolnay, “Anyhow. ” https://github.com/dtolnay/anyhow, 2024. 22 Hanliang Zhang, Cristina David, Meng Wang, Brandon Pauls en, and Daniel Kroening

    2024

  15. [23]

    RustAssistant: Using LLMs to fix compilation errors in Rust code,

    P. Deligiannis, A. Lal, N. Mehrotra, R. Poddar, and A. Rastogi, “ RustAssistant: Using LLMs to fix compilation errors in Rust code, ” inInternational Conference on Software Engineering (ICSE) , pp. 267–279, IEEE, May 2025

    2025

  16. [24]

    Claude

    “Claude. ” https://www.anthropic.com/index/introducing-claude

  17. [25]

    GPT-4 technical report,

    J. Achiam, S. Adler, S. Agarwal, L. Ahmad, I. Akkaya, F. L. Aleman, D. Almeida, J. Altenschmidt, S. Altman, S. Anadkat, et al., “GPT-4 technical report, ”arXiv preprint arXiv:2303.08774, 2023

    2023 arXiv

  18. [26]

    Gemini

    “Gemini. ” https://blog.google/technology/ai/google-gemini-ai/

  19. [27]

    String comparison and edit distance algorithms library

    “String comparison and edit distance algorithms library. ” https://github.com/hbollon/go-edlib

  20. [28]

    Stats – Golang statistics package

    “Stats – Golang statistics package. ” https://github.com/montanaflynn/stats

  21. [29]

    Textrank implementation in golang with extendable features (s ummarization, phrase extraction) and multithreading (goroutine)

    “Textrank implementation in golang with extendable features (s ummarization, phrase extraction) and multithreading (goroutine).. ”https://github.com/DavidBelicza/TextRank/tree/master

  22. [30]

    Streaming approximate histograms in Go

    “Streaming approximate histograms in Go. ” https://github.com/VividCortex/gohistogram

  23. [31]

    Takes a full name and splits it into individual name parts

    “Takes a full name and splits it into individual name parts. ” https://github.com/polera/gonameparts

  24. [32]

    Provide check digit algorithms and calculators written in Go

    “Provide check digit algorithms and calculators written in Go. ” https://github.com/osamingo/checkdigit

  25. [33]

    Transl ating C to safer Rust,

    M. Emre, R. Schroeder, K. Dewey, and B. Hardekopf, “Transl ating C to safer Rust, ”Proceedings of the ACM on Program- ming Languages, vol. 5, no. OOPSLA, pp. 1–29, 2021

    2021

  26. [34]

    C to Go translator

    “C to Go translator. ” https://github.com/gotranspile/cxgo

  27. [35]

    Sharpen – automated Java->C# coversion

    “Sharpen – automated Java->C# coversion. ” https://github.com/mono/sharpen

  28. [36]

    On the evaluatio n of neural code translation: Taxonomy and bench- mark,

    M. Jiao, T. Yu, X. Li, G. Qiu, X. Gu, and B. Shen, “On the evaluatio n of neural code translation: Taxonomy and bench- mark, ” inAutomated Software Engineering (ASE), pp. 1529–1541, IEEE, Sept. 2023

    2023

  29. [37]

    A ttention, compilation, and solver-based symbolic analysis are all you need,

    P. Jana, P. Jha, H. Ju, G. Kishore, A. Mahajan, and V. Ganesh, “A ttention, compilation, and solver-based symbolic analysis are all you need, ” arXiv preprint arXiv:2306.06755, 2023

    2023 arXiv

  30. [38]

    CodeFuse-13B: A pretrained multi-lingual code large language model,

    P. Di, J. Li, H. Yu, W. Jiang, W. Cai, Y. Cao, C. Chen, D. Chen, H. Che n, L. Chen, G. Fan, J. Gong, Z. Gong, W. Hu, T. Guo, Z. Lei, T. Li, Z. Li, M. Liang, C. Liao, B. Liu, J. Liu, Z. Liu, S. Lu, M. Shen, G. Wang, H. Wang, Z. Wang, Z. Xu, J. Yang, Q. Ye, G. Zhang, Y. Zhang, Z...

    2024

  31. [39]

    StructCoder: Structure -aware transformer for code generation,

    S. Tipirneni, M. Zhu, and C. K. Reddy, “StructCoder: Structure -aware transformer for code generation, ” ACM Trans. Knowl. Discov. Data, vol. 18, Jan. 2024

    2024

  32. [40]

    CodeTransOcean: A comp rehensive multilingual benchmark for code translation,

    W. Yan, Y. Tian, Y. Li, Q. Chen, and W. Wang, “CodeTransOcean: A comp rehensive multilingual benchmark for code translation, ”arXiv preprint arXiv:2310.04951, 2023

    2023 arXiv

  33. [41]

    CodeNet: A large-scale AI for code dataset for learning a divers ity of coding tasks,

    R. Puri, D. S. Kung, G. Janssen, W. Zhang, G. Domeniconi, V. Zolotov , J. Dolby, J. Chen, M. Choudhury, L. Decker,et al., “CodeNet: A large-scale AI for code dataset for learning a divers ity of coding tasks, ” arXiv preprint arXiv:2105.12655, 2021

    2021 arXiv

  34. [42]

    CodeXGLUE: A machine learning benchmark dataset for code understanding and generatio n,

    S. Lu, D. Guo, S. Ren, J. Huang, A. Svyatkovskiy, A. Blanco, C. Clement, D. Drain, D. Jiang, D. Tang, G. Li, L. Zhou, L. Shou, L. Zhou, M. Tufano, M. GONG, M. Zhou, N. Duan, N. Sundaresan, S. K. Deng, S. Fu, and S. LIU, “CodeXGLUE: A machine learning benchmark dataset for code...

    2021

  35. [43]

    A V ATAR: A parallel corpus for Java-Python program translation,

    W. U. Ahmad, M. G. R. Tushar, S. Chakraborty, and K.-W. Chang, “A V ATAR: A parallel corpus for Java-Python program translation, ”arXiv preprint arXiv:2108.11590, 2021

    2021 arXiv

  36. [44]

    Is your code generated b y ChatGPT really correct? Rigorous evaluation of large language models for code generation,

    J. Liu, C. S. Xia, Y. Wang, and L. Zhang, “Is your code generated b y ChatGPT really correct? Rigorous evaluation of large language models for code generation, ” Advances in Neural Information Processing Systems , vol. 36, 2024

    2024

  37. [45]

    Evaluating large language models trained on code,

    M. Chen, J. Tworek, H. Jun, Q. Yuan, H. P. d. O. Pinto, J. Kaplan, H . Edwards, Y. Burda, N. Joseph, G. Brockman, et al., “Evaluating large language models trained on code, ” arXiv preprint arXiv:2107.03374, 2021

    2021 arXiv

  38. [46]

    Multilingual code co-e volution using large language models,

    J. Zhang, P. Nie, J. J. Li, and M. Gligoric, “Multilingual code co-e volution using large language models, ” inFoundations of Software Engineering, pp. 695–707, 2023

    2023

  39. [47]

    Automated program repair in the era of large pre-trained language models,

    C. S. Xia, Y. Wei, and L. Zhang, “Automated program repair in the era of large pre-trained language models, ” in ICSE, IEEE, 2023

    2023

  40. [48]

    Contrastrep air: Enhancing conversation-based automated program repair via contrastive test case pairs,

    J. Kong, M. Cheng, X. Xie, S. Liu, X. Du, and Q. Guo, “Contrastrep air: Enhancing conversation-based automated program repair via contrastive test case pairs, ” arXiv preprint arXiv:2403.01971, 2024

    2024

  41. [49]

    Leve raging compiler intermediate representation for multi- and cross-language verification,

    J. J. Garzella, M. Baranowski, S. He, and Z. Rakamarić, “Leve raging compiler intermediate representation for multi- and cross-language verification, ” in Verification, Model Checking, and Abstract Interpretation , pp. 90–111, Springer, 2020

    2020

  42. [50]

    Semantic s oundness for language interoperability,

    D. Patterson, N. Mushtak, A. Wagner, and A. Ahmed, “Semantic s oundness for language interoperability, ” inProgram- ming Language Design and Implementation , PLDI 2022, p. 609–624, ACM, 2022

    2022

  43. [51]

    Translation validation,

    A. Pnueli, M. Siegel, and E. Singerman, “Translation validation, ” in Tools and Algorithms for Construction and Analysis of Systems, vol. 1384 of LNCS, pp. 151–166, Springer, 1998. Scalable, Validated Code Translation of Entire Projects us ing Large Language Models 23

    1998

  44. [52]

    Translation validation for an optimizing compiler ,

    G. C. Necula, “Translation validation for an optimizing compiler , ” inProceedings of the ACM SIGPLAN 2000 conference on Programming language design and implementation , pp. 83–94, 2000

    2000

  45. [53]

    HyDiff: Hybrid differential software analysis,

    Y. Noller, C. S. Păsăreanu, M. Böhme, Y. Sun, H. L. Nguyen, and L. Grunske, “HyDiff: Hybrid differential software analysis, ” inInternational Conference on Software Engineering , pp. 1273–1285, 2020

    2020

  46. [54]

    Regres sion tests to expose change interaction errors,

    M. Böhme, B. C. d. S. Oliveira, and A. Roychoudhury, “Regres sion tests to expose change interaction errors, ” in Foun- dations of Software Engineering , pp. 334–344, 2013

    2013

  47. [55]

    Shadow of a doubt: testing for divergences between software versions,

    H. Palikareva, T. Kuchta, and C. Cadar, “Shadow of a doubt: testing for divergences between software versions, ” in Proceedings of the 38th International Conference on Softwa re Engineering, pp. 1181–1192, 2016

    2016

  48. [56]

    Directed increme ntal symbolic execution,

    S. Person, G. Yang, N. Rungta, and S. Khurshid, “Directed increme ntal symbolic execution, ” ACM Sigplan Notices , vol. 46, no. 6, pp. 504–515, 2011

    2011

  49. [57]

    DLFuzz: Differentia l fuzzing testing of deep learning systems,

    J. Guo, Y. Jiang, Y. Zhao, Q. Chen, and J. Sun, “DLFuzz: Differentia l fuzzing testing of deep learning systems, ” in European Software Engineering Conference and Symposium on the Foundations of Software Engineering , pp. 739–743, 2018

    2018

  50. [58]

    Automated behavioral regression t esting,

    W. Jin, A. Orso, and T. Xie, “Automated behavioral regression t esting, ” inInternational Conference on Software Testing, Verification and Validation, pp. 137–146, IEEE, 2010

    2010

  51. [59]

    Diffuzz: different ial fuzzing for side-channel analysis,

    S. Nilizadeh, Y. Noller, and C. S. Pasareanu, “Diffuzz: different ial fuzzing for side-channel analysis, ” in International Conference on Software Engineering (ICSE) , pp. 176–187, IEEE, 2019

    2019

  52. [60]

    N ezha: Efficient domain-independent differential testing,

    T. Petsios, A. Tang, S. Stolfo, A. D. Keromytis, and S. Jana, “N ezha: Efficient domain-independent differential testing, ” in 2017 IEEE Symposium on Security and Privacy (SP) , pp. 615–632, IEEE, 2017

    2017

Pith tools

Reviewed August 11, 2026 · model on record in the stance chip above.