# Languages and limits > The five languages you can solve in, the time and memory your code gets, why Java starts with less of the budget, and the one thing TypeScript does differently. Source: https://www.revquix.com/docs/practice/languages-and-limits Last verified: 2026-09-04 --- Five languages: **Java**, **C++**, **Python**, **JavaScript** and **TypeScript**. Which of them a given problem offers is up to its author - the picker lists only the ones with a working stub and a verified reference solution. > **Note** - The picker shows the language, not the version > > There is one place a version number lives, and it is the runner itself. A picker saying "Java 21" > while the sandbox ran something else would be worse than one that just says "Java". ## Time **A whole submission gets five seconds**, and that is a hard ceiling on the sandbox rather than a per-problem setting anyone can raise. Every test case in the submission runs inside that one budget, in a single process - which is why a problem with forty cases is not forty times slower to judge than one with two. Compilation is timed separately and more generously. > **Warning** - Java spends part of the budget before your code runs > > Starting a JVM costs roughly a second, every time. So a Java submission has around four seconds of > _your_ code inside the five, where C++ and Python have very nearly all of it. > > Problems are checked against this at publish time - the reference solution has to finish comfortably > inside the budget in the slowest language offered - so a correct, reasonably efficient solution is > not going to be squeezed out by JVM startup. But it is why a solution that is borderline in Java may > be comfortable in C++. ## Memory Each language gets its own ceiling, sized to what it actually needs: Java and TypeScript get the most, C++ and Python less, because they need less to do the same work. This is also why **"beats X% on memory" is never compared across languages**. Java reports around 48 MB where C++ reports 7 MB for identical work, so a cross-language ranking would tell every Java user they are in the bottom decile forever for writing correct code. ## Size - **Your source** is capped at 64 KB. No solution to a practice problem approaches this. - **Output** is capped, per attempt. A program that prints inside a hot loop gets cut off, and a very loud one is stopped with **Too much output**. - **Custom input** you type into the Testcase pane is capped too, well above any hand-typed value. ## Deep recursion works A recursive depth-first search over a large tree is ordinary, correct code, and on default settings it overflows the stack in both Java and C++. Both get a large stack here specifically so that it does not - hundreds of thousands of frames are fine. If you hit **Runtime error** with a stack overflow, treat it as a real depth problem rather than a sandbox limit you cannot do anything about. ## Per-language notes ### Java Your file is `Solution.java`. The code that calls it is a separate file, so compiler errors report lines in your editor and nothing else. The JVM startup cost described above is the only thing to keep in mind. Prefer `StringBuilder` over repeated string concatenation in a loop, as you would anywhere. ### C++ C++17. Your code is compiled into one translation unit together with the driver, so you do not need - and must not write - a `main`. Compilation is unoptimised, which is worth knowing if you are comparing runtimes against a local build with `-O2`. ### Python Your file is `solution.py`. Import what you need from the standard library as normal. Python has no compile step, so the whole budget is available to your code - but the interpreter is slower per operation, so an algorithm that is asymptotically wrong will run out of time sooner here than in C++. ### JavaScript Your file is `solution.js`. Write `class Solution { ... }` - there is no need to export anything, and the driver does not `require` your file. A thrown error reports `solution.js:4:18` - your own line and column. ### TypeScript **Your TypeScript is genuinely type-checked**, at ES2020, with real library types - `Map`, `Set` and `for...of` over an iterable all work. That is worth stating because it is not free: the sandbox's own TypeScript package compiles at ES5, where none of those work. The judge does the compilation itself instead, at a modern target, so the language you get is the one you expected. A type error comes back as a **Compile error** in the compiler's own format - `solution.ts(3,15): error TS2322: ...` - pointing at your line and column. A runtime throw reports `solution.ts:4:18`. ## What the sandbox does not have **No network.** Your solution cannot make an HTTP request, read a URL or reach anything outside its own process. Everything a problem needs is in its arguments. **No filesystem to speak of, and nothing persists.** Each attempt starts clean. ## Related - [Verdicts and test cases](https://www.revquix.com/docs/practice/verdicts-and-test-cases) - What Time limit exceeded is actually telling you. - [How fast is my solution](https://www.revquix.com/docs/practice/how-fast-is-my-solution) - Measuring your solution rather than guessing.