Lua.CodeCompared.To/C#

Console is a class in the System namespace, and WriteLine is a static method on it. Lua's print is a plain global function, which is why it needs no qualification.

So Lua's print is closest to Console.WriteLine and Lua's io.write is closest to Console.Write. C# prints True with a capital letter, because it is calling Boolean.ToString() rather than formatting a keyword.

The third form has no Lua counterpart. A triple-slash comment is XML that the compiler extracts into a documentation file and that editors show in tooltips, so it is part of the public surface of a method rather than a note to the next reader.

The compiler still generates the class and the Main method; it just writes them for you. One consequence shows up throughout this page: type declarations must come after the loose statements in the file, because everything above them is being folded into Main.

C# has no then and no elseif — it is else if, two words. A single-statement body can drop the braces entirely, which is common for short guard clauses and is used in a few examples below.

count is an int and label is a string, permanently. var saves you typing the type, not the type itself, which is why an uninitialized var is a compile error: there would be nothing to infer from.

The payoff is that a whole class of Lua bug — a value quietly becoming the wrong kind of thing three functions away from where it was set — is reported at the line that causes it. The cost is that you now have to decide, and say, what everything is.

C# has no global variables at all. The nearest thing is a static field on a class, which you have to declare deliberately and name through its type. A misspelled variable is a compile error rather than a new global with a null value.

Notice that Lua reports both 1 and 3.14 as number while C# distinguishes Int32 from Double. Lua 5.3 does draw that line internally — math.type reports it — but it is a subtype of one number type rather than two separate types.

Lua 5.3 settled this by making / always produce a float and adding // for floor division. C# instead resolves the operator from the operand types, so you opt into float division by making one operand a float. The bug this causes looks like an averaging function that returns whole numbers.

With nullable reference types on, calling a method on person without checking it is a warning, and calling one on name needs no check at all. That is the shift: null stops being something you defend against everywhere and becomes something the type says up front.

C# has no conversion from any other type to bool, so there is no falsy set to memorize and no accidental truthiness to debug. The cost is verbosity: every check that Lua writes as if value then becomes if (value != null) or if (value.Count > 0), and you have to know which one you meant.

Lua's or replaces anything falsy, so enabled = enabled or true can never be false — a bug every Lua programmer has written. ??= replaces null and nothing else, so the same line in C# does what it looks like it does.

The Lua idiom silently returns c whenever b is false or nil, which is why enabled and false or true yields true. C#'s ?: is a real conditional expression and cannot fall through, and the compiler additionally checks that both branches produce the same type.

Both languages also intern string literals, so identical literals are usually the same object. The practical consequence is the same in both: repeated concatenation allocates, and the fix is to accumulate elsewhere and join once — see the Gotchas section.

Both languages convert the number to text automatically here. The difference to watch is that in C# "1" + 2 is the string "12" while 1 + 2 is the number 3, so the operator's meaning depends on the operands — whereas Lua's .. is always concatenation and "10" + 1 is the number 11.

word[^8..] is C# 8 range syntax: ^8 means "eight from the end" and .. takes a slice, so it reads much like word:sub(-8) once you know it. The old spelling is word.Substring(word.Length - 8), which is exactly the arithmetic Lua's negative index saves you.

The interpolated form is checked at compile time: a misspelled variable name inside the braces is an error, where %d against a string is a run-time error in Lua. After the comma comes the field width (negative for left alignment) and after the colon the format specifier, so {count,5} matches %5d and :F2 matches %.2f.

Length is a property — it looks like a field, runs like a method, and takes no parentheses. Getting that wrong is the most common first-day C# error for someone arriving from a language where everything is either a field or a call, and the compiler's message names the fix.

C# has the full engine, so alternation (a|b), non-greedy quantifiers and lookaround all work. Two mechanical notes: @"…" is a verbatim string, which stops \d from being read as an escape sequence, and the extra parentheses in the Lua column discard gsub's second return value, the replacement count.

The gmatch idiom also silently drops empty fields, so "a,,b" yields two colors rather than three. Split keeps them, and takes an option to remove them if you would rather. This is the kind of place where C#'s larger standard library simply saves you a decision.

The bracketed [10, 20, 30] is a C# 12 collection expression: the same syntax initializes an array, a List<T> or a Span<T>, with the target type deciding which. It is the closest C# comes to Lua's table constructor, and it is new enough that older code will use new int[] { … } instead.

Lua's convention makes colors[#colors] the natural way to reach the last element; C#'s ^1 index-from-end operator does the same job without the length arithmetic, and colors[colors.Length - 1] is the older spelling you will see everywhere. Both languages throw on an out-of-range index — except that Lua does not: it returns nil.

The reason List<T> is the counterpart rather than an array is that C# arrays have a fixed length: there is no Add on int[]. Choosing between them is a decision Lua never asks you to make, and the short answer is that List<T> is what you want unless you know the size up front.

TryGetValue is the pattern to learn: it returns a bool and hands the value back through an out parameter declared inline, which is C#'s way of returning two things without a tuple. Lua's nil-means-absent rule is convenient until an absent key silently propagates; the exception is louder, and on purpose.

ipairs walks from 1 until it finds a nil and stops, so it never sees "d". Worse, #sparse is explicitly undefined for a table with a hole — the reference manual permits either 2 or 4 — so a Lua array must have no gaps to be trustworthy. A C# array has a fixed length that counts every slot, and null is just a value living in one of them.

If order matters, say so. C# has SortedDictionary<K,V> for key order and OrderBy for a one-off, where Lua leaves you to collect and table.sort the keys as above. The Lua column here is the pattern to internalize, because printing a pairs loop directly is how you write a test that passes on your machine and fails elsewhere.

The C# column introduces a tuple — (string Name, int Age) — which is the lightest way to carry a couple of named fields around, and the closest thing on this page to just using a Lua table. A boolean comparator that is not a strict ordering makes table.sort raise "invalid order function"; C# reports the same class of mistake as an InvalidOperationException.

Where filters and Select transforms; the naming comes from SQL rather than from functional programming, which is why they are not called filter and map. Everything in LINQ is an extension method on IEnumerable<T>, so the same two calls work on an array, a List<T>, a Dictionary or a database query.

Traversing the list four times instead of once is real but almost never the bottleneck, and Aggregate is there for the case where it is. Notice that both columns format their floats explicitly: Lua prints a float as 12.0 and C# prints a double as 12, so a bare print would disagree between the two languages while both were right.

A GroupBy yields a sequence of groups, each of which is itself a sequence with a Key, so it composes with everything else — OrderBy here, and Select, Sum or Where just as easily. Note also that word[0] gives a char, a type Lua does not have: a one-character Lua string is still a string.

Lua prints 1,4,9 and C# prints 1,4,9,16, because Select stored the transformation and the source, not the answer — the work happens when string.Join enumerates it. Call .ToList() to force it and get Lua's behavior. The flip side is a genuine gain: a query over a million rows that ends in .First() touches one row.

First throws when nothing matches, which is usually what you want inside code that assumes a match; FirstOrDefault returns null (or 0, for a number) instead and is the closer match to the Lua column's nil. Both Any and All stop as soon as the answer is settled. C# prints its booleans capitalized, as True and False.

The compiler rewrites this into exactly the Where().OrderBy().Select() chain from the previous rows, so the two spellings are interchangeable. Query syntax wins when there are joins or several from clauses; method syntax wins everywhere else, and is what most modern C# uses.

Double here is a local function, declared inside the top-level statements — a good match for Lua's local function, and available before the line that declares it. Func<int, int> is a delegate type: the last type parameter is the return type and the ones before it are the parameters, so a two-argument version is Func<int, int, int>.

The difference shows up when a call is used in a larger expression. Lua adjusts a multi-value call to one value in most positions, so print(divide(17, 5), "x") prints only the quotient — a real source of confusion. A C# tuple is one value everywhere, so nothing silently disappears. Naming the tuple fields, as above, means the caller can also write result.Quotient.

The reason Lua needs select("#", ...) at all is that #{ ... } would be wrong when an argument is nil: packing stops the count at the hole, exactly as in the ipairs row above. values.Length has no such problem, because null is a value in the array rather than the end of it.

The third line is the real gain. Lua's only way to skip a middle argument is to pass nil positionally, which means callers have to count; a named argument says which parameter it is. The trade-off to know is that a default value is baked into the caller at compile time, so changing one in a shipped library does not reach callers until they rebuild.

Both languages capture the variable rather than a copy of its value, which is what makes the counter work. C# implements it by moving count into a compiler-generated class on the heap, and Lua by making it an upvalue; the observable behavior is the same, including that two calls to MakeCounter give two independent counters.

A Lua function value has no signature at all: passing a two-argument function where a one-argument one was expected is legal, and the extra parameter is simply nil. C# checks the arity and the types at the call site. Action<T> is the same thing for a function that returns nothing, since Func always has a return type.

The declaration buys three things the idiom cannot: new Account("Ada") with a missing argument is a compile error, Balance can be readable everywhere and writable only inside the class, and the name Account is a type you can use in signatures. The parameter list on the class line is a C# 12 primary constructor, which is the shortest form and the closest in shape to Account.new.

In C# there is no dot-versus-colon choice to get wrong, and this is implicit — you write it only to disambiguate a parameter from a field. Method syntax and receiver-passing are separate concepts here rather than two spellings of one, which removes a whole category of Lua mistake.

C# makes the relationship a declaration and then demands you be explicit about overriding: the base method must say virtual and the derived one must say override, or the compiler objects. That is a real constraint compared to Lua, where any method on any table can be replaced at any moment — and it is the reason a C# override cannot be a typo.

A property is a method pair wearing a field's clothes, and it is why C# code has so few GetX() methods. { get; set; } generates the storage for you, and => expression makes a read-only computed one. Note the difference in reach: Lua's __index fires for any missing key, so it is one hook for all of them, while a property is declared one at a time.

The name IShape follows a .NET convention: interfaces are prefixed with I. C# interfaces are nominal — a class with matching methods that does not name IShape will not be accepted, which is the opposite of Lua's structural check and the opposite of TypeScript's too. The payoff is that the requirement is documented and enforced in one place instead of discovered at the call site.

Lua prints 99 and C# prints 1. A class is a reference type and behaves like a Lua table; a struct is a value type and is copied on assignment, on being passed to a method, and on being stored in a collection. That last one causes the classic surprise: mutating a struct you pulled out of a List changes the copy, not the item. The usual advice is to make structs small and readonly.

One line generates the constructor, the properties, value-based Equals and GetHashCode, a ToString that prints the fields, and support for with. Records are immutable by default, so with is how you "change" one — the same discipline as returning a new table rather than mutating the one you were handed. This is the type to reach for whenever a Lua table was just carrying data.

An indexer intercepts obj["key"] and only that. It cannot intercept obj.Color, because member access is resolved against the type when the program is compiled, not looked up in a table when it runs. So the half of __index that makes dotted access dynamic has no equivalent here — the next-to-last row in this section shows what you use instead.

In C# read-only is the absence of a setter, checked when the code is compiled. The distinction matters for how you find out: the Lua version turns a typo into an exception in production, and the C# version turns it into a red squiggle. C# also has readonly fields and init-only properties, which allow assignment during construction and refuse it afterwards.

Two differences worth noting. A C# operator is static and takes both operands, so there is no receiver and no asymmetry to reason about, where Lua picks whichever operand has the metamethod. And __tostring becomes an override of ToString, which every type already has — so Console.WriteLine(sum) finds it without the explicit tostring call the Lua column needs.

The reason for four is that Equals is what collections call, GetHashCode is what a Dictionary or HashSet buckets by, and == is what your code writes — so an object with Equals but no GetHashCode gets lost in a hash set. That is a lot of boilerplate to get right, which is exactly why record exists and why it is the right answer nearly every time.

Declaring a variable dynamic switches member resolution from compile time to run time, and DynamicObject lets you intercept it. In exchange you lose everything static typing was buying: no completion, no compile-time checking, and a slower call. It is the right tool for talking to JSON, COM or a scripting host — and the wrong one for the ordinary object design where Lua would reach for __index without a second thought.

Three things are checked for you. The arms must all produce the same type; _ is the catch-all and the compiler warns when there is none and the cases are not exhaustive; and there is no fall-through, so no break to forget. The arms are patterns, not just values — < 0 above is a relational pattern — which is what the next three rows build on.

Inside the string text arm, text is a string, so text.Length is checked at compile time — where the Lua column's #value is only correct because the branch above it happened to be right. The same test outside a switch is written if (value is string text), which is the form you will see most often.

The arms are tried in order, so the more specific ones must come first — exactly as with the Lua ladder, and exactly as easy to get wrong. What you gain is that the shape being tested is visible at a glance rather than spread across boolean operators, and that patterns nest: { Customer: { Country: "GB" } } is a valid arm.

.. is the slice pattern and matches any number of elements, so [var first, .. var rest] destructures a head and a tail. Nothing in Lua corresponds: the length has to be measured and the elements indexed by hand, and — as the ipairs row showed — #values is not even reliable if the table has a hole. Note that the C# version needs no catch-all arm, because the three patterns are exhaustive and the compiler knows it.

The structural difference is what happens when you forget. An unchecked error() in Lua propagates to the host and usually prints a traceback; an uncaught C# exception terminates the process with a stack trace and a non-zero exit code. Neither language checks at compile time that you handled anything — C# has no checked exceptions, unlike Java.

The constraint is what makes catch by type possible, and it comes with machinery for free: a message, an InnerException for wrapping, and a captured stack trace. Custom exception classes are cheap — the one above is three lines — and the convention is to end the name in Exception.

Handlers are tried top to bottom, so the most specific type goes first: a catch (Exception) above a catch (FormatException) is a compile error, which is a nice touch. catch (SomeException error) when (error.Code == 404) adds a filter, and a bare catch with no type catches everything — the equivalent of not checking what pcall handed you.

finally runs on the way out however you leave — normal completion, an exception, or a return from inside the try. That last case is the one worth internalizing, because it is precisely the path the Lua idiom above skips: a return before the cleanup line simply never reaches it.

A type that implements IDisposable can be declared with using, and Dispose() is called when the enclosing scope ends, including via an exception — which is why both columns print close before error:. The win over the wrapper is that the discipline lives with the resource, so every caller gets it without knowing to ask; await using is the asynchronous version.

A method containing yield return is compiled into a state machine that remembers where it stopped — a coroutine, generated for you. coroutine.wrap is the closer of Lua's two spellings because it returns a callable that for can drive, exactly as IEnumerable is what foreach drives. Both are lazy: nothing runs until the loop asks.

C#'s yield return is one-way — there is no way to send a value into a suspended iterator. When you need the conversation you write the state as an object, as above, or use a System.Threading.Channels.Channel<T> to pass values in both directions. Neither is as direct, and it is worth knowing this is a real loss rather than a spelling you have not found yet.

await suspends the method, returns the thread to the pool, and resumes where it left off when the awaited operation completes. So the mechanism is a coroutine, but the decision about when to resume belongs to the runtime rather than to you. The name convention is real: a method returning Task is written with an Async suffix so callers know to await it.

Task.WhenAll returns an array in argument order regardless of which finished first, which is why both columns print first, second even though the C# tasks complete the other way round. Task.WhenAny gives you the first to finish, and a CancellationToken passed through the chain is how you stop the rest — none of which has a Lua counterpart short of building it.

IAsyncEnumerable<T> with await foreach is a sequence whose items arrive over time — paginated API responses, rows streaming out of a query, lines from a socket. The Lua column is the same shape written with the one construct Lua has, which is a fair summary of the whole section: Lua's coroutines are more general, and C#'s three specialized tools each do more for you.

Unity's StartCoroutine takes an IEnumerator and calls MoveNext() on it each frame, so yield return null means "next frame" and yield return new WaitForSeconds(2) means "in two seconds" — the same shape as a LÖVE or Defold scheduler resuming your coroutines from update. Note that these are iterators, not Tasks: Unity coroutines predate async/await and are still the idiom for frame-paced game logic.

A C# using imports no code and returns nothing; it tells the compiler which namespaces to search for unqualified names, and the code itself has already been compiled into the assembly. One file can declare several namespaces and one namespace can span a hundred files, so the directory layout is a convention rather than a mechanism. Modern code writes namespace MathHelpers; once at the top of a file instead of using braces.

C# has four levels, and the one with no Lua counterpart is the interesting one: internal means "visible anywhere in this assembly", which is a unit of packaging Lua does not have. It is also the default for a type — the static class Counter above is internal — so a type is shared within your project and hidden from anyone referencing it until you say public.

LuaRocks installs into a shared tree and the interpreter finds it through package.path, so which version you get depends on the machine unless you add a lockfile tool. dotnet add package writes the reference into the project file, which is checked in, and dotnet restore reproduces it — so the dependency set travels with the code. Neither column runs here, because neither package is installed in the browser runner.

The this on the first parameter is what makes it an extension method: the compiler rewrites "hello".Shout() into StringExtensions.Shout("hello"), so nothing is added to string at all. Two consequences follow. It is scoped — only files that import the containing namespace see it — and it cannot break anything, because it loses to any real method of the same name. The Lua version mutates a table every string in the program shares, which is why libraries are told not to.

table.concat over a table of pieces and StringBuilder are the same technique: one buffer, filled once. C# additionally optimizes concatenation of a fixed number of operands into a single call, so a + b + c in one expression is fine — it is the loop that is not.

Lua's numeric for creates a new control variable each iteration, so each closure gets its own and the code above needs no help. C#'s for has one index for the whole loop, so without the copy every closure would return 4. foreach is the exception — it was changed in C# 5 to create a fresh variable per iteration, precisely because this bug was so common — so the copy is only needed in a for.

In C# the special case is operator == defined on string, and a type can define its own — which is exactly what record does, and why a record compares by value while a class does not. When you want to compare contents rather than identity, left.SequenceEqual(right) is the LINQ answer; Lua has no equivalent and you write the loop.

?. returns null instead of throwing when the left side is null, and the rest of the chain is skipped — so a?.b.c is safe even though only the first link has the question mark. One printing difference to know: Lua's print(nil) writes nil, while Console.WriteLine(null) writes an empty line, which is why the ?? is there to make the absence visible.

C# checks the count and the types at the call site, so both mistakes are compile errors — unless the parameter has a default, in which case omitting it is deliberate. The habit worth unlearning is Lua's value or default at the top of a function: in C# that information belongs in the signature, where the caller can see it.