The GDScript vs C# debate in Godot has been running since Mono support first appeared in Godot 3. In 2026, with Godot 4.6 shipping a JIT compiler for GDScript and C# benefiting from .NET 9's AOT improvements, the conversation has shifted from "which one works" to "which one fits your project."

This is not a language war article. Both GDScript and C# are production-ready in Godot 4.6. Both can ship commercial games. The question is which one reduces friction for your specific team, project type, and long-term goals. We will cover syntax, performance with real benchmarks, editor integration, debugging, ecosystem considerations, team dynamics, and the practical reality of switching between them.

We build tools for Godot -- the Godot MCP Server supports both GDScript and C# workflows with its 131 tools. We have seen how both languages perform in real projects, and the answer is genuinely "it depends."

The Languages at a Glance

Before we dive deep, here is the high-level comparison for readers who want the summary.

Now let's unpack each dimension.

Syntax Comparison

The best way to understand the feel of each language is to see the same patterns implemented in both. These are not contrived examples -- they are patterns you will write in every Godot project.

Basic Node Script

GDScript:

extends CharacterBody3D

@export var speed: float = 5.0
@export var jump_force: float = 4.5
@export var gravity: float = 9.8

@onready var animation_player: AnimationPlayer = $AnimationPlayer
@onready var mesh: MeshInstance3D = $Mesh

var _is_jumping: bool = false


func _physics_process(delta: float) -> void:
    var input_dir := Input.get_vector("move_left", "move_right", "move_forward", "move_back")
    var direction := (transform.basis * Vector3(input_dir.x, 0, input_dir.y)).normalized()

    if direction:
        velocity.x = direction.x * speed
        velocity.z = direction.z * speed
    else:
        velocity.x = move_toward(velocity.x, 0, speed)
        velocity.z = move_toward(velocity.z, 0, speed)

    if not is_on_floor():
        velocity.y -= gravity * delta
    elif Input.is_action_just_pressed("jump"):
        velocity.y = jump_force
        _is_jumping = true

    move_and_slide()

    if is_on_floor() and _is_jumping:
        _is_jumping = false

C#:

using Godot;

public partial class PlayerController : CharacterBody3D
{
    [Export] public float Speed { get; set; } = 5.0f;
    [Export] public float JumpForce { get; set; } = 4.5f;
    [Export] public float Gravity { get; set; } = 9.8f;

    private AnimationPlayer _animationPlayer;
    private MeshInstance3D _mesh;
    private bool _isJumping;

    public override void _Ready()
    {
        _animationPlayer = GetNode<AnimationPlayer>("AnimationPlayer");
        _mesh = GetNode<MeshInstance3D>("Mesh");
    }

    public override void _PhysicsProcess(double delta)
    {
        var inputDir = Input.GetVector("move_left", "move_right", "move_forward", "move_back");
        var direction = (Transform.Basis * new Vector3(inputDir.X, 0, inputDir.Y)).Normalized();

        var velocity = Velocity;

        if (direction != Vector3.Zero)
        {
            velocity.X = direction.X * Speed;
            velocity.Z = direction.Z * Speed;
        }
        else
        {
            velocity.X = Mathf.MoveToward(velocity.X, 0, Speed);
            velocity.Z = Mathf.MoveToward(velocity.Z, 0, Speed);
        }

        if (!IsOnFloor())
        {
            velocity.Y -= Gravity * (float)delta;
        }
        else if (Input.IsActionJustPressed("jump"))
        {
            velocity.Y = JumpForce;
            _isJumping = true;
        }

        Velocity = velocity;
        MoveAndSlide();

        if (IsOnFloor() && _isJumping)
        {
            _isJumping = false;
        }
    }
}

The GDScript version is 30 lines. The C# version is 48 lines. This ratio holds across most game logic -- C# is roughly 40-60% more verbose due to braces, type declarations, explicit access modifiers, and the Velocity struct copy pattern (you cannot modify Velocity.Y directly in C# because it is a value type property).

Neither version is "better." The GDScript version is faster to write and read. The C# version provides more compile-time safety and better IDE support for refactoring.

Signal Connections

GDScript:

func _ready() -> void:
    # Direct connection
    $Button.pressed.connect(_on_button_pressed)

    # Lambda
    $Button.pressed.connect(func(): print("Clicked"))

    # With arguments
    $Button.pressed.connect(_on_button_pressed.bind("extra_data"))

func _on_button_pressed(data: String = "") -> void:
    print("Button pressed: ", data)

C#:

public override void _Ready()
{
    // Direct connection
    GetNode<Button>("Button").Pressed += OnButtonPressed;

    // Lambda
    GetNode<Button>("Button").Pressed += () => GD.Print("Clicked");

    // With captured variable (no bind equivalent needed)
    string extraData = "extra_data";
    GetNode<Button>("Button").Pressed += () => OnButtonPressed(extraData);
}

private void OnButtonPressed(string data = "")
{
    GD.Print($"Button pressed: {data}");
}

C# uses standard .NET event syntax (+=) instead of Godot's connect() method. This is more familiar to C# developers and supports closures naturally. GDScript's bind() method is functional but less elegant than C# lambdas with captures.

Resource Definitions

GDScript:

class_name WeaponData
extends Resource

@export var weapon_name: String = ""
@export var damage: float = 10.0
@export var attack_speed: float = 1.0
@export var weapon_type: WeaponType = WeaponType.SWORD
@export var icon: Texture2D = null
@export var effects: Array[StatusEffect] = []

enum WeaponType { SWORD, AXE, BOW, STAFF, DAGGER }

func get_dps() -> float:
    return damage * attack_speed

C#:

using Godot;

public enum WeaponType { Sword, Axe, Bow, Staff, Dagger }

[GlobalClass]
public partial class WeaponData : Resource
{
    [Export] public string WeaponName { get; set; } = "";
    [Export] public float Damage { get; set; } = 10.0f;
    [Export] public float AttackSpeed { get; set; } = 1.0f;
    [Export] public WeaponType Type { get; set; } = WeaponType.Sword;
    [Export] public Texture2D Icon { get; set; }
    [Export] public Godot.Collections.Array<StatusEffect> Effects { get; set; } = new();

    public float GetDps() => Damage * AttackSpeed;
}

Note the [GlobalClass] attribute in C# -- without it, the resource will not appear in the Godot editor's resource creation menu. This is one of those gotchas that trips up new C# users. GDScript's class_name handles both global registration and class naming in one line.

Async and Coroutines

GDScript:

func fade_out_and_transition() -> void:
    var tween := create_tween()
    tween.tween_property($Sprite, "modulate:a", 0.0, 1.0)
    await tween.finished

    get_tree().change_scene_to_file("res://scenes/next_level.tscn")

func wait_for_timer() -> void:
    await get_tree().create_timer(2.0).timeout
    print("Two seconds passed")

C#:

public async void FadeOutAndTransition()
{
    var tween = CreateTween();
    tween.TweenProperty(GetNode("Sprite"), "modulate:a", 0.0f, 1.0f);
    await ToSignal(tween, Tween.SignalName.Finished);

    GetTree().ChangeSceneToFile("res://scenes/next_level.tscn");
}

public async void WaitForTimer()
{
    await ToSignal(GetTree().CreateTimer(2.0), SceneTreeTimer.SignalName.Timeout);
    GD.Print("Two seconds passed");
}

GDScript's await signal syntax is cleaner than C#'s await ToSignal() wrapper. This is one area where GDScript's tight engine integration provides a noticeably better developer experience. C#'s async/await is more powerful in general (.NET Tasks, cancellation tokens, etc.), but for Godot-specific signal awaiting, GDScript wins on ergonomics.

Performance: The 2026 Reality

GDScript JIT in Godot 4.6

Godot 4.6 introduced a JIT (Just-In-Time) compiler for GDScript. This is the most significant performance improvement to GDScript since the language's creation. Previous versions interpreted GDScript bytecode, which was adequate for game logic but noticeably slow for computational tasks.

The JIT compiler translates GDScript bytecode to native machine code at runtime. For code with tight loops, mathematical operations, and array processing, the improvement is dramatic.

Benchmark Results

We ran benchmarks on three hardware tiers using Godot 4.6 stable. Each test was run 100 times and averaged. All tests used typed GDScript (static type annotations) since the JIT compiler optimizes typed code more aggressively.

Test 1: Array Processing (sort 100,000 integers)

Test 2: Physics Queries (10,000 raycasts per frame)

Test 3: Game Logic (1,000 AI agents updating state machines)

Test 4: String Operations (parse 10,000 JSON entries)

What the Benchmarks Tell Us

GDScript 4.6 JIT is 3-8x faster than 4.5 interpreted. This is a massive improvement that makes GDScript viable for workloads that previously required C# or GDExtension. The JIT closes the gap significantly.

C# is still 2-3x faster than GDScript JIT for computational tasks. For pure number crunching, array manipulation, and tight loops, C# retains a clear advantage. The .NET runtime is mature and heavily optimized.

Typed GDScript matters enormously for JIT performance. Untyped GDScript JIT is only 2-3x faster than interpreted, while typed GDScript is 5-8x faster. If you use GDScript and care about performance, add type annotations to everything.

For typical game logic, the difference is negligible. Test 3 shows that even with 1,000 AI agents, GDScript JIT takes 1.9ms on desktop. Your frame budget is 16.6ms at 60fps. GDScript's 1.9ms versus C#'s 0.7ms is a difference that matters only if you are doing something extreme.

The real bottleneck is almost never your scripting language. Rendering, physics, and draw calls consume the vast majority of your frame budget. Your character controller, inventory system, and dialogue logic are rounding errors in the performance profile. Unless you are writing a simulation-heavy game (thousands of entities with complex logic), the language choice will not be your performance bottleneck.

When Performance Actually Matters

C# has a genuine performance advantage in these specific cases:

• Procedural generation at runtime. Generating terrain, dungeons, or mesh data during gameplay. Array allocation and mathematical operations dominate, and C# is measurably faster.
• Custom physics or collision. If you are implementing spatial partitioning, custom broadphase, or soft body simulation in script rather than using Godot's built-in physics.
• Large-scale AI simulations. Hundreds or thousands of entities with complex decision-making logic running every frame.
• Data processing. Parsing large data files, serialization/deserialization, compression/decompression.

For everything else -- player controllers, UI logic, dialogue systems, quest management, camera systems, game state management -- the performance difference between GDScript JIT and C# is invisible to the player.

Editor Integration

GDScript

GDScript's editor integration is seamless because the language was designed for the editor. Everything just works:

• Instant script reload. Save a GDScript file and changes apply immediately. No compilation step, no waiting.
• Inspector integration. @export annotations are reflected in the inspector instantly. Custom export hints (@export_range, @export_enum, @export_flags) work without any additional configuration.
• Autocompletion. The built-in script editor understands GDScript natively. Node paths auto-complete, signal names auto-complete, and API documentation is available inline.
• Documentation generation. Add ## comments above classes and functions and they appear in the in-editor help system, alongside the engine's own documentation.
• Tool scripts. @tool scripts run in the editor, enabling custom gizmos, inspector plugins, and editor tools. This works reliably in GDScript.

GDScript's weakness in the editor is the built-in script editor itself. It is functional but basic compared to dedicated IDEs. There is no advanced refactoring, limited multi-file search-and-replace, and the debugger is adequate but not powerful. You can use external editors (VS Code with the Godot GDScript extension), but the experience is not as polished as C#'s IDE integration.

C#

C#'s editor integration has improved significantly in Godot 4.x but still has friction points:

• Compilation required. C# scripts must be compiled before changes take effect. The build is triggered automatically when you run the project, but there is a noticeable delay (2-10 seconds depending on project size). This interrupts the rapid iteration flow that GDScript provides.
• IDE integration is excellent. Visual Studio, Rider, and VS Code with C# Dev Kit all provide full IntelliSense, refactoring, debugging, and code analysis. If you are coming from a professional C# development background, this feels like home.
• Debugging is superior. You can attach a full .NET debugger with conditional breakpoints, watch expressions, call stack inspection, and hot reload (in some configurations). GDScript's debugger is basic by comparison.
• [Export] attributes work but have occasional edge cases. Certain generic types, nested Resources, and custom property hints require more ceremony than GDScript equivalents.
• [Tool] scripts work but are less reliable than GDScript @tool scripts. The C# assembly must be reloaded when you modify tool scripts, which can cause editor instability in complex cases.
• Build system complexity. C# projects use MSBuild/dotnet CLI under the hood. Occasionally, the build system gets into a bad state (stale assemblies, reference issues) that requires a clean rebuild. GDScript never has this problem because there is no build step.

The practical impact: C# developers should use an external IDE (Rider is the community favorite for Godot C#). GDScript developers can use either the built-in editor or an external one.

Debugging Experience

This deserves its own section because debugging is where you spend a significant portion of development time.

GDScript Debugging

Built-in debugger features:

• Breakpoints (click the gutter in the script editor)
• Step over, step into, step out
• Local and member variable inspection
• Stack trace on errors
• Remote scene tree inspection (view the node tree of a running game)
• Profiler (function call timing, physics and rendering frame times)

What is missing:

• Conditional breakpoints
• Watch expressions
• Edit-and-continue
• Memory profiler
• Thread debugging (GDScript is single-threaded by design)

Print debugging culture. Let's be honest: most GDScript developers debug with print() statements. The built-in debugger works, but it is slow to set up breakpoints, and the variable inspector does not always show complex types clearly. The community leans heavily on print debugging, which is fine for small projects but scales poorly.

C# Debugging

Full .NET debugging features:

• Conditional breakpoints
• Hit count breakpoints
• Watch expressions and immediate window
• Edit-and-continue (limited in Godot context)
• Call stack with decompiled source for engine calls
• Memory profiling through .NET tools
• Thread inspection

Practical experience:

• Attach Rider or Visual Studio to the running Godot process
• Set breakpoints in game code and they hit reliably
• Inspect Godot objects, Resources, and node trees through the debugger
• Step through code with full variable visibility
• Use the .NET memory profiler to find leaks

The debugging experience alone is a strong argument for C# in larger projects. When you have a complex bug involving multiple interacting systems, a proper debugger with conditional breakpoints and watch expressions saves hours compared to print-based debugging.

Ecosystem and Libraries

GDScript Ecosystem

GDScript's ecosystem is Godot-native. Every addon in the Godot Asset Library is either GDScript or has a GDScript interface. If an addon is written in C#, it requires the .NET version of Godot to use, which limits its audience.

Popular GDScript addons:

• Dialogic 2 - dialogue system
• GodotSteam - Steam API integration
• Phantom Camera - camera framework
• Limbo AI - behavior trees and state machines
• Qodot - Quake map importer

The limitation: GDScript cannot access external libraries. You cannot pull in a NuGet package, a Python library, or a Rust crate. If you need functionality that does not exist in the Godot ecosystem, your options are GDExtension (C/C++/Rust bindings) or finding a Godot-specific implementation.

C# Ecosystem

C# in Godot gets access to two ecosystems:

Godot addons that support C# (a subset of the total, but growing).

The entire NuGet ecosystem. This is a significant advantage. Need JSON parsing? Use System.Text.Json. Need networking? Use the .NET HTTP client, gRPC, or SignalR. Need a math library? Use MathNet.Numerics. Need SQLite? Use Microsoft.Data.Sqlite.

The practical impact of NuGet access:

For games that need backend communication, database access, or complex data processing, the NuGet ecosystem is a genuine productivity multiplier.

GDExtension: The Third Option

Worth mentioning: GDExtension allows you to write performance-critical code in C, C++, or Rust and expose it to both GDScript and C#. This is the answer for the rare cases where neither scripting language is fast enough. You write the hot path in native code and call it from your preferred scripting language.

The Godot MCP Server can help set up GDExtension bindings, but the workflow is significantly more complex than pure GDScript or C# development. Only go this route when you have profiled and confirmed that scripting performance is actually the bottleneck.

Team Considerations

Solo Developer

For a solo developer, the choice is simpler: use whichever language you are more comfortable with.

If you know Python but not C#, use GDScript. The learning curve is minimal, the community resources are abundant, and you will be productive immediately.

If you know C# from Unity or professional development, use C#. The type system and IDE support will feel natural, and the debugging experience will be better than what you are used to in GDScript.

If you know both or neither, start with GDScript. The faster iteration loop (no compilation) and tighter editor integration make it the better choice for learning Godot's architecture. You can always add C# later for specific systems.

Small Team (2-5 developers)

For small teams, consider the team's background:

Team with .NET experience: C# is the obvious choice. Shared conventions, familiar tooling, and strong IDE support for code review and refactoring.

Team with mixed backgrounds: GDScript is easier to onboard new developers into. A Python developer, a JavaScript developer, and a Java developer can all read and write GDScript within a day. C# is more specific and requires existing familiarity with static typing and object-oriented patterns.

Team with a designer who scripts: If you have a game designer or level designer who writes some code but is not a programmer, GDScript is far more accessible. The Python-like syntax and lack of boilerplate lower the barrier to contribution.

Larger Teams (5+)

For larger teams, C#'s advantages in code organization become more significant:

• Interfaces and abstractions. C# interfaces, abstract classes, and generics provide contracts between team members' code. GDScript's duck typing works fine in small codebases but makes it harder to enforce architectural boundaries in large ones.
• Namespaces. C# namespaces prevent class name collisions. GDScript's global class_name registration can cause conflicts as the project grows.
• Refactoring tools. Renaming a method in C# with Rider's refactoring tool updates every reference across the project. In GDScript, you do a text search and hope you caught them all.
• Static analysis. C# analyzers catch bugs at compile time that GDScript would catch only at runtime. For a large team where any individual does not know the entire codebase, this is valuable.

Hiring Considerations

If you are a studio hiring developers:

• C# developers are abundant. The language is used in enterprise software, web development, game development (Unity), and cloud services. You can hire from a large talent pool, though you may need to teach Godot-specific patterns.
• GDScript developers are a smaller pool but they know Godot deeply. Someone who has learned GDScript has invested specifically in the Godot ecosystem and likely understands the engine's architecture, scene system, and philosophy.
• Neither pool is a bottleneck for indie-scale teams. At 1-5 people, you are hiring for game development ability, not language expertise. A good developer can learn either language in a week.

Porting from Unity

This section is specifically for the significant number of developers who have moved or are considering moving from Unity to Godot.

The C# Advantage for Unity Migrants

Your Unity C# code will not run in Godot unmodified. The APIs are completely different -- MonoBehaviour becomes Node, GameObject becomes Node, GetComponent<T>() becomes GetNode<T>(), Instantiate() becomes scene.Instantiate(). But the language is the same, and that matters more than you might think.

Your knowledge of C# patterns transfers directly:

• Async/await patterns
• Generic collections and LINQ
• Interfaces and dependency injection
• Event patterns with delegates
• NuGet library familiarity
• IDE workflows (Rider, Visual Studio)

The mental model shift is from Unity's component architecture to Godot's scene tree architecture. That shift is significant regardless of language. But doing it in a familiar language removes one variable from the equation.

What Does Not Transfer

Even with C#, these Unity patterns do not have direct Godot equivalents:

The Case for GDScript Even as a Unity Migrant

Counterargument: using C# in Godot can create a trap where you try to write Unity patterns in Godot. GDScript forces you to learn Godot's way of doing things because you cannot fall back on familiar patterns. The "Godot way" -- signals, scene composition, node-based architecture -- is different from Unity's approach, and fighting it with Unity-style C# patterns leads to worse code than embracing it with GDScript.

Many experienced Unity migrants report that after an initial adjustment period, GDScript's tighter integration with Godot's editor and scene system made them more productive than C# in Godot. The caveat is that this is a personal experience and not universal.

Our recommendation for Unity migrants: try GDScript for your first Godot project (a small one). If it clicks, stay with it. If you miss static typing, IDE support, and NuGet access, switch to C# for your second project. The first project is about learning Godot, not being productive.

Export Considerations

Build Size

C# adds 30-60 MB to your export because the .NET runtime must be bundled. For desktop games, this is irrelevant. For mobile or web exports, it may matter.

Platform Support

The web export gap is worth noting. GDScript exports to WebAssembly cleanly. C# web exports require the .NET WASM runtime, which in Godot 4.6 is functional but still marked as experimental. If web distribution is important to your project, GDScript is the safer choice today.

Console Exports

Console exports in Godot are already complex regardless of language. C# adds an additional layer of complexity because the .NET runtime must be configured for each console platform. In practice, the studios handling Godot console ports (W4 Games and others) support both GDScript and C#, but the process is smoother with GDScript.

The Verse Question: Unreal's Language Debate

It is worth noting that Unreal Engine has its own version of this debate. Epic introduced Verse, a new programming language designed specifically for Unreal Engine (initially for Fortnite Creative / UEFN, with plans for broader UE integration).

Verse occupies a different niche than C++ and Blueprints -- it is a functional, statically-typed language with features like first-class concurrency and failure contexts. As of 2026, Verse is available in UEFN but has limited availability in general Unreal Engine projects.

The parallel to the Godot debate:

• GDScript is to Godot what Verse is to Unreal: a language designed specifically for the engine, with deep integration and engine-specific features.
• C# is to Godot what C++ is to Unreal: a general-purpose language that provides maximum performance and access to external ecosystems, at the cost of more complexity.
• Blueprints have no direct Godot equivalent. Godot's VisualScript was deprecated and removed. The closest alternative is Orchestrator, a community addon.

If you are evaluating both engines, the language ecosystem is worth considering. Unreal gives you Blueprints (visual), C++ (performance), and eventually Verse (modern, engine-specific). Godot gives you GDScript (simple, engine-specific) and C# (powerful, general-purpose). Both engines also support native extensions for when scripting is not enough.

For Unreal developers interested in AI-assisted workflows, the Unreal MCP Server provides 305 tools that work with Blueprint, C++, and editor operations -- effectively using AI as an additional "language" for engine interaction.

Mixing Languages

Godot 4.6 supports using both GDScript and C# in the same project. This is a viable strategy, but it comes with caveats.

When Mixing Works

GDScript for game logic, C# for systems code. Write your player controller, UI, and dialogue in GDScript for rapid iteration. Write your procedural generation, networking layer, or data processing in C# for performance and library access.

GDScript for prototyping, C# for production. Prototype systems in GDScript, then rewrite the ones that need performance or complexity in C#. GDScript prototypes are fast to iterate on, and the rewrite to C# gives you a chance to redesign the architecture with lessons learned.

When Mixing Does Not Work

Cross-language signal connections. Connecting a GDScript signal to a C# method (or vice versa) works but requires using the Godot signal system (Connect() method) rather than language-native patterns. It is awkward and loses type safety.

Shared data types. Passing complex data between GDScript and C# requires using Godot's built-in types (Godot.Collections.Dictionary, Godot.Collections.Array) rather than language-native types. You cannot pass a C# List<T> to GDScript or a GDScript Array[Type] to C# typed collections.

Build complexity. Mixed projects require the .NET version of Godot even if most code is GDScript. You pay the C# export size overhead for the entire project.

Team confusion. When some files are .gd and others are .cs, developers need to understand both languages and know which convention to follow in each context. This cognitive overhead is real.

Our recommendation: pick one language as your primary and use the other sparingly for specific, well-bounded systems. Do not split 50/50.

What Doesn't Work: Honest Limitations

GDScript Limitations

No compile-time safety net. Typos in variable names, incorrect function signatures, and type mismatches are caught at runtime, not compile time. Optional static typing in 4.6 helps, but it is not enforced by default and many community tutorials and addons do not use it.

Limited refactoring. Renaming a class or method requires manual find-and-replace across the project. There is no automated refactoring tool that understands GDScript's semantics.

No external library access. You are limited to what Godot provides and what the community has built as addons. If you need a specific algorithm, data structure, or protocol implementation that does not exist in the Godot ecosystem, you must build it yourself or use GDExtension.

Single-threaded by default. GDScript runs on the main thread. You can use Thread for background work, but there is no async/await for threading, no thread-safe collections, and shared state requires manual mutex management. For CPU-intensive background tasks, C# or GDExtension is better.

C# Limitations in Godot

Second-class citizen feel. Despite significant improvements, C# in Godot occasionally feels like an afterthought. Documentation examples are GDScript-first. Community tutorials are predominantly GDScript. Some addons do not support C# at all. You will spend time translating GDScript examples to C#.

Build system fragility. The .NET build system occasionally produces confusing errors, stale assembly references, or IDE synchronization issues. Experienced .NET developers know how to handle these; newcomers may find them frustrating.

Editor tool scripts. Writing editor tools and plugins in C# is possible but less stable than GDScript. Assembly reloading can cause the editor to behave unexpectedly with complex C# tool scripts.

Larger export size. The 30-60 MB overhead from the .NET runtime is a fixed cost regardless of how much C# you write.

Web export immaturity. The .NET WASM runtime in Godot is not production-ready for complex projects. If web is a target platform, this is a blocker.

The Verdict

There is no single correct answer. Here is our project-type recommendation.

Use GDScript If:

• This is your first Godot project
• You are a solo developer or very small team
• Your project is 2D or simple 3D
• Rapid iteration speed is your priority
• You target web or mobile platforms
• You do not need external libraries
• Your team does not have C# experience

Use C# If:

• You are migrating from Unity with an existing C# team
• Your project has performance-critical scripting (procedural generation, AI simulation)
• You need NuGet libraries (networking, databases, data processing)
• Your team is larger than 5 developers and needs strong code organization
• Debugging complex systems is a daily activity
• You are building a commercial project with long-term maintenance needs

Use Both If:

• You have a clear boundary between systems (e.g., all gameplay in GDScript, all backend/networking in C#)
• Your team is comfortable with both languages
• You are willing to accept the build complexity and export size tradeoff

The Elephant in the Room

If performance is your primary concern and you are considering C# in Godot for that reason alone, ask yourself: should you be using Godot at all? Unreal Engine with C++ and Blueprints provides significantly better performance for complex 3D games, and the Blueprint Template Library provides pre-built gameplay systems that eliminate much of the C++ boilerplate. The Unreal MCP Server further reduces the complexity barrier.

Godot's strength is not raw performance. It is simplicity, fast iteration, lightweight projects, and an open-source philosophy. Both GDScript and C# serve that vision in different ways. Choose the one that lets you ship your game with the least friction.

The best language is the one that does not get in your way. For most Godot developers in 2026, that is GDScript. For a significant minority -- especially Unity migrants and .NET-experienced teams -- that is C#. And that is a perfectly healthy state for an engine to be in.