Code Execution & DSA Engine: Multi-Language Support & SQL Runner

Part 4 of 5 in the Code Execution & DSA Engine series.

DSA Question Design & Structure covered a question's per-language ### Heading solution blocks. This page covers how those language keys become an actual language picker and a compiled/interpreted run on Judge0 — and why SQL Practice, despite living in the same code-runner family, doesn't touch Judge0 at all.

The language registry: one object, everything derives from it

src/lib/judge0.js keeps a single LANGUAGES object — Judge0 CE language id, optional compilerOptions, a CodeMirror mode, and an available flag. The language picker, submission storage, and history filters all derive from this one object; adding a future runtime is one new entry, nothing else in the app changes.

Key	Judge0 id	Notes
c	50	GCC
cpp17 / cpp20 / cpp23	54 (shared)	Same Judge0 id; standard selected via compilerOptions (-std=c++17, -std=c++2a, -std=c++2b)
python	71	CPython
pypy3 / pypy3_64	900 / 901	Custom rows, not stock Judge0 — only exist because this box is self-hosted
java	62	public class Main required, filename must be Main.java
javascript	63	Node
typescript	74	—
go	60	—
rust	73	—
kotlin	78	—

cpp23 is registered but available: false — the box's GCC predates the c++2b compiler flag entirely (added in GCC 11), so every submission would be an instant Compilation Error. It stays in the table, hidden from the picker, rather than shipping broken; flipping available: true after a GCC upgrade is the entire migration.

PyPy3 is the clearest case of self-hosting paying for itself directly: Judge0 CE does not ship PyPy in its default language table at all, on either the standard or Extra CE image. Ids 900/901 are custom rows added directly to this box's own Postgres languages table — a option that simply does not exist against a managed/public Judge0 endpoint.

A problem pins a family, not a specific standard

A question's frontmatter lists languages: [cpp17, python, java] — a family, not "cpp17 only." expandLanguages() takes that list and expands it: any C++ key implies every available C++ standard, and python implies both PyPy3 variants automatically.

// Simplified real shape of expandLanguages (judge0.js)
function expandLanguages(keys) {
  const set = new Set(keys);
  if (set.has("python")) {
    if (LANGUAGES.pypy3.available) set.add("pypy3");
    if (LANGUAGES.pypy3_64.available) set.add("pypy3_64");
  }
  if (["cpp17", "cpp20", "cpp23"].some((k) => set.has(k))) {
    for (const k of ["cpp17", "cpp20", "cpp23"]) {
      if (LANGUAGES[k].available) set.add(k);
    }
  }
  return [...set];
}

This is why all 70 questions, authored before C++20/C++23 existed as options, didn't need a single content edit when those standards were added — and why cpp23 will appear in the picker automatically the day its available flag flips, again with zero content changes.

Compiled vs. interpreted, and why it's judged fairly

C++, Java, Go, Rust, and Kotlin compile once and run the binary; Python, PyPy3, and JavaScript interpret the source directly on every run. That baseline difference is exactly why cross-language verification in the previous page marks Python tle_lenient — a correct O(n) Python solution genuinely can be slower than an equivalent C++ one for reasons that have nothing to do with the algorithm being wrong.

diagram100%

rendering diagram…

drag to pan · ctrl / ⌘ + scroll to zoom

SQL is a different runner entirely, not a Judge0 language

SQL Practice does not go through Judge0. SqlRunner.jsx runs sql.js — SQLite compiled to WebAssembly — directly in the browser: no server round trip for a query that should feel instant, no sandboxing arbitrary SQL against a real server-side database.

Grading is where SQL diverges furthest from the DSA path. There is no automatic pass/fail diff against a stored expected result set. The practice page is self-graded by design — the learner compares their own result table against the Sample output table in the Solution tab — with an optional "Get AI Feedback" button that posts the query plus grading context (statement, setup, reference query, sample output) to /grade-sql-practice for LLM commentary, only after the learner has already run something once.

// Simplified real shape of buildSqlGradePayload (sqlGrading.js)
function buildSqlGradePayload(question, answer) {
  const referenceQuery = extractSqlBlock(question.solution);
  const sampleOutput = extractFirstTable(question.solution);
  return { statement: question.body, setup: question.setup, referenceQuery, sampleOutput, answer };
}

Inside a timed OA, the same query is graded differently again: SqlExamRunner enqueues a durable Firestore grade job (gradeKind: "sql") instead of grading instantly, so a page refresh or a dropped connection mid-attempt can't lose the submission — the in-app driver or a server Worker grades it off-session. It reuses the exact same AI pipeline as the CS Fundamentals section's ai-sql grading method, forced explicitly rather than inferred from frontmatter. Three different grading experiences (self-compare, on-demand AI feedback, durable background AI grading) share one execution engine (sql.js) and one grading pipeline (the AI service) — see SQL Pipeline for how those reference solutions are authored in the first place.

Self-assessment

Word count for this page: 878 words.

---

← Previous: DSA Question Design & Structure→ Next: ediky_tools Pipeline & Empirical Analysis