Kotlin.CodeCompared.To/C#

C# 9 added top-level statements, so the class Program { static void Main… } ceremony is gone — the file body is the entry point, exactly as Kotlin's main shortcut intends. Semicolons are back, though, and they are mandatory. Every example on this page is a top-level program; type declarations, when needed, go after the statements.

Kotlin's val/var axis (mutability) and C#'s var/explicit-type axis (inference) are orthogonal, and C# has no local-immutability keyword at all — const only takes compile-time literals, and readonly applies to fields, not locals. So the discipline val gives you for free must be maintained by hand. Note also that types come before the name (long explicitly, not explicitly: Long) — C-family word order, unlike Kotlin's Pascal-style colon.

The $ moves from inside the string to the front of it: C# marks the whole literal as interpolated, then every {…} is an expression slot — so a literal brace must be doubled ({{), where Kotlin escapes the dollar instead. C# adds format specifiers Kotlin punts to String.format ({age,5} pads, {value:F2} rounds). Raw string literals (""") work like Kotlin's, and better: the closing delimiter's indentation sets the margin, so trimIndent() is built into the syntax.

There is no downTo, no step, and no inclusive range to iterate: Enumerable.Range(start, count) takes a count, not an end, and everything else is a C-style for. C# does have a range operator, but numbers[1..3] is for slicing arrays and spans (half-open, like Python), not for counting. The withIndex() idiom becomes a LINQ Select with the two-argument overload — an early taste of how much of Kotlin's stdlib lives in LINQ here.

Three things to internalize. (1) The check is opt-in: without #nullable enable (or the project-level <Nullable>enable</Nullable>, which modern templates do set) there is no analysis at all. (2) Violations are warnings — the program still compiles and still runs, so a non-nullable string can absolutely hold null at runtime. (3) None of it survives into the runtime: there is no Intrinsics.checkNotNull guard on public entry points, so a null from an unchecked library or from JSON deserialization sails straight into your "non-nullable" field. Treat warnings-as-errors as mandatory and you get close to Kotlin's guarantee; ship with warnings and you have documentation.

Safe navigation is ?. in both, and the elvis operator is spelled ?? — "null-coalescing" — with identical short-circuiting semantics. C# throws in ??=, which assigns only if the target is null (Kotlin needs value = value ?: …). ?. also chains into indexers (list?[0]) and, best of all, into delegate invocation: handler?.Invoke(this, args) is the standard null-safe event raise.

Kotlin's !! compiles to a real runtime check that throws at the assertion — the lie is caught at the exact line you told it. C#'s ! is the null-forgiving operator: it emits no instructions whatsoever, merely telling the static analyzer to stop complaining. The null therefore propagates silently until something dereferences it, and the NullReferenceException surfaces somewhere downstream with a stack trace pointing at the innocent party. Reach for it as rarely as you reach for !!, and reach for ArgumentNullException.ThrowIfNull(value) when you want Kotlin's fail-fast behavior.

The shapes rhyme; the semantics differ. Kotlin's val name in the constructor declares a property; C# 12's primary-constructor parameters are merely captured into scope for the class body to use, and expose nothing publicly unless you write the property yourself. So class Person(string name) gives you no person.Name at all — a quietly surprising result if you assume Kotlin's rules. (Records, next section, do publish them.) Members are also private by default and need an explicit public, where Kotlin's default is public.

Both spell the setter's incoming argument value, and both let a computed property masquerade as a field. The divergence is the backing store: Kotlin's magic field identifier is generated for you, while C# (before the very new field keyword) makes you declare the private backing field by hand as soon as the accessor does anything non-trivial. { get; set; } is the auto-property (no backing field written), { get; } and { get; init; } are the read-only forms — init being C#'s answer to val, settable during object initialization and frozen afterward.

open is virtual, and override is override — mandatory in both, so no accidental overrides. Two differences: C# classes are open by default (it is methods that are closed; sealed class means final, a completely different meaning from Kotlin's sealed — see Pattern Matching), and C# lets a subclass deliberately shadow a non-virtual member with new, which Kotlin simply forbids. The base-constructor call rides on the type list (: Animal(name)), exactly as in Kotlin.

Where data class generates equals, hashCode, toString, and copy, record generates Equals, GetHashCode, ToString, Deconstruct, and a with clone — and it goes one better by overloading == itself, so value equality works through the operator rather than only through a method. Records are also immutable by default (the generated properties are init-only, so they really are val), and unlike Kotlin's data classes they support inheritance from other records.

with is copy() with nicer syntax: a shallow clone of the record with the listed properties replaced, and the original left alone. Both are shallow — a nested mutable object is shared between the copies, in C# just as in Kotlin. The advantage of the language-level form is that with works on any record without generating a method, and it plays properly with inheritance (cloning the runtime type, not the static one).

Value tuples are the real upgrade: (int Min, int Max) is an ad-hoc, named, allocation-free return type — where Kotlin's Pair forces you onto .first and .second (or a whole data class) the moment you want two values back. Any type can opt into destructuring by writing a Deconstruct(out …) method, which is the counterpart of Kotlin's operator fun component1(). Note [3, 1, 4]: C# 12 collection expressions, which infer the target collection type.

Same feature, one character apart: named arguments use a colon (excited: true) rather than =, which reads oddly for about a day. Both languages let you skip middle parameters this way, and both re-evaluate nothing — but C# bakes the default value into the call site at compile time, so changing a default in a library requires recompiling every caller to see it. That surprise does not exist in Kotlin, where the default is evaluated inside the callee.

Kotlin's = expression body is C#'s => expression body, available on methods, properties, constructors, and operators alike — the same conciseness, one arrow instead of an equals sign. Two conveniences to steal: new(…) is a target-typed new that infers the type from the left-hand side, and C# functions declared inside a method body are local functions, closing over locals with no lambda allocation. What C# does not have is top-level functions: Double above is legal only because top-level statements wrap it; in a real file, every method belongs to a type (usually a static class).

The mechanics are identical — static methods with sugar at the call site, resolved at compile time, no dynamic dispatch, and invisible to the extended type. C# demands more ceremony (a static class, a static method, the this modifier on the first parameter) and, more importantly, offers no extension properties and no extension operators, so val String.initials has to become a method call. LINQ is itself nothing but extension methods on IEnumerable<T>, which is the single best advertisement for the feature in either language.

The split is the thing to memorize: Func<…, TResult> when the lambda returns a value, Action<…> when it returns nothing — because C# has no Unit type to unify them, void is not a real type. There is no it, so every parameter is named; there is no trailing-lambda syntax, so the lambda stays inside the parentheses and Kotlin's block-style DSLs have no direct analog. In exchange, delegates are multicast (you can += several handlers onto one), which is the foundation of C#'s event keyword.

The default is reversed: Kotlin's listOf hands back the read-only interface and you must ask for mutability, while C#'s List<T> is the concrete mutable class and you must ask for IReadOnlyList<T>. In both cases it is a view, not a guarantee — the underlying list is still mutable through another reference — but the C# convention of exposing the concrete type on APIs means read-only collections are far rarer in practice. Note [1, 2, 3]: C# 12 collection expressions finally give literals a compact syntax, and ages["Ada"] on a missing key throws (TryGetValue is the safe form; Kotlin's get returns null).

The dictionary: map is Select, filter is Where, fold is Aggregate, flatMap is SelectMany, sortedBy is OrderBy, first is First, firstOrNull is FirstOrDefault, sumOf is Sum, and joinToString is the static string.Join — which breaks the chain and must wrap it. Watch FirstOrDefault: on a value type it returns 0, not null, so "not found" and "found a zero" are indistinguishable — SingleOrDefault has the same hazard. There is also a SQL-like query syntax (from n in names where … select …) that compiles to these same calls; almost nobody uses it.

IEnumerable<T> is Sequence<T>, and a method with yield return is sequence { yield(…) } — infinite generators work identically. The trap is deferred execution: a LINQ chain is a query, not a result, so it re-executes every time you enumerate it (note the two Count() calls above), and it will happily observe changes to the source collection you made after building it. Kotlin's eager default makes this impossible. The fix is a terminal .ToList() to materialize — the mirror image of the asSequence() habit.

Both are expressions that return a value, both test types and bind the narrowed value in one step (C#'s int number declaration pattern is Kotlin's smart cast, just written down), and _ is else. The cruel joke is the keyword: C# spells the guard when — so when in C# is what if does inside a Kotlin when branch. C# goes further with property patterns (Person { Age: > 65 }), list patterns ([1, .., 9]), and relational patterns (> 100) that Kotlin has no syntax for.

In C#, sealed class means "cannot be inherited from" — it is Kotlin's default, the opposite of open, and has nothing to do with closed hierarchies. To get the real thing you nest the subtypes inside an abstract base with a private constructor, so no outside type can join the union. Even then the compiler will not prove exhaustiveness: a switch without a _ arm compiles with a warning and throws SwitchExpressionException at runtime if nothing matches. Discriminated unions are the most-requested missing C# feature and are on the roadmap; until they land, this is the strongest gap between the two type systems.

On the JVM, List<String> and List<Int> are the same class at runtime, which is why Kotlin needs inline fun <reified T> to inline the call site and recover the type — and why is List<String> is illegal. The CLR specializes generics for real, so typeof(T), new T() (with the where T : new() constraint), and is T all just work in an ordinary method. Value types get their own specialized code too, meaning List<int> stores raw ints with no boxing — where Kotlin's List<Int> silently boxes every element into an Integer.

Identical keywords, identical rule — out for a type that only comes out (producers), in for one that only goes in (consumers) — and both are checked at the declaration. The difference is that C# has no use-site variance: Kotlin's List<out Number> parameter (its answer to Java's ? extends wildcard) has no C# spelling, so an IEnumerable<T> is covariant because its interface declares out T, and a List<T> is invariant forever. Also note that C# variance only applies to interfaces and delegates, never to classes.

A struct lives inline — on the stack or embedded in its owner — and is copied on assignment, with no heap allocation and no garbage to collect. That makes List<Point> a flat block of memory rather than a list of pointers, which is why C# is at home in game engines and numeric code where the JVM must fight the allocator. The costs are real: copies are silent (mutate one and the other is unchanged — a classic bug), large structs are slower to pass than a reference, and a struct always has a zero-initialized default. readonly record struct is the sweet spot and the closest thing to value class, minus the one-field restriction.

The mapping is clean: suspend fun foo(): String is async Task<String> Foo(), delay is Task.Delay, and awaiting is await rather than a plain call. Two structural differences hide underneath. A Task is hot — it starts running the moment it is created, so var task = FetchGreeting(); without an await is already in flight, where a Kotlin suspend function does nothing until called and async is explicit about launching. And a forgotten await silently discards the result and any exception, which is why "fire and forget" bugs are a C# genre unto themselves.

Task.WhenAll is awaitAll and Task.WhenAny is the race — but note what is absent: the tasks began running when Select created them, not when you awaited, so there is no async { } to write and also no scope that owns them. Because C# tasks are real threadpool work, WhenAll gives you genuine parallelism across cores without a Dispatchers.Default equivalent — the CLR has no GIL and no single-threaded default.

A CancellationToken is a parameter you thread through every async signature by hand and check yourself — Kotlin's coroutines carry cancellation in the context automatically and make every suspension point a cancellation point. Nothing owns a C# Task, so one can outlive the method that started it and fail with nobody listening; Task.WhenAll waits for all of them and only then reports the first exception (the rest land in an AggregateException). The discipline Kotlin gives you by construction is, here, a convention you enforce in code review.

Neither language has checked exceptions, so the discipline is identical and only the exception names change (IllegalArgumentException is ArgumentException, IllegalStateException is InvalidOperationException, NullPointerException is NullReferenceException). C#'s catch … when (…) filter is a real upgrade: the predicate runs before the stack unwinds, so a non-match leaves the original throw site intact for the debugger. Missing, though, is runCatching/Result<T> — C# has no idiomatic value-returning error wrapper, so the TryParse/out pattern (a bool plus an out parameter) is what the standard library reaches for instead.