Чего не хватает в C#

Чего не хватает в C# с точки зрения Unity-разработчика

C# — мощный и постоянно развивающийся язык, но для разработки игр в Unity есть несколько недостатков, которые особенно заметны в контексте высокопроизводительных и многопоточных проектов. Несмотря на усилия Microsoft и сообщества, некоторые области остаются болезненными точками.

Ключевые недостатки в контексте разработки игр

1. Нативная поддержка Value Types для обобщённых типов (Generics)

Одно из главных ограничений — невозможность использовать неуправляемые (unmanaged) типы в качестве обобщённых параметров там, где это логично. Например, нельзя создать List<MyStruct> с гарантией размещения в стеке или управляемого пула без боксинга. В Unity, где важно избегать аллокаций в куче, это критично.

// Хотелось бы, но так нельзя:
public struct FixedBuffer<T> where T : unmanaged
{
    private fixed T data[1024]; // Ошибка: тип T не может использоваться в fixed буфере
}

2. Отсутствие встроенной системы обработки ошибок без исключений

Исключения в C# дороги с точки зрения производительности, особенно на платформах вроде iOS или WebGL. Для игр, где важна стабильность кадровой частоты, не хватает альтернатив, подобных Result-типам из Rust или Option-типам из F#. Хотя можно реализовать свои, встроенной поддержки нет.

// Пример желанной нативной реализации:
public Result<T, Error> TryGetComponent<T>() where T : Component
{
    if (gameObject.TryGetComponent(out T component))
        return Result.Ok(component);
    return Result.Fail(new Error("Component not found"));
}

3. Ограниченная работа с памятью и низкоуровневые операции

Несмотря на появление ref struct, Span<T> и Memory<T>, для разработки игр не хватает:

• Нативных массивов с фиксированным размером (аналог fixed array в C/C++), интегрированных в язык.
• Прямого контроля над выравниванием данных в структурах для оптимизации под конкретные архитектуры (например, SIMD).
• Удобных инструментов для ручного управления памятью без полного погружения в unsafe-контекст.

4. Слабые возможности метапрограммирования

Хотя Roslyn и Source Generators добавили возможности, они сложны в использовании для простых задач. В Unity часто нужны:

• Генерация boilerplate-кода для систем компонентов (например, как в ECS).
• Компиляция выражений в рантайме с минимальными накладными расходами (сейчас часто используют System.Linq.Expressions, что медленно).
• Встроенные макросы или шаблоны кода, как в C++, для уменьшения дублирования.

5. Недостатки для Data-Oriented Programming (DOP)

С появлением Unity DOTS/ECS стало ясно, что C# не идеален для DOP:

• Отсутствие нативной поддержки SOA (Structure of Arrays) — приходится использовать сложные обёртки.
• Ограничения для бурст-компилятора: множество правил и исключений, которые усложняют разработку.
• Слабая интеграция с SIMD-инструкциями, хотя System.Numerics.Vectors помогает, но часто недостаточен.

6. Проблемы с многопоточностью и асинхронностью

Хотя async/await — мощный инструмент, для игр он имеет недостатки:

• Высокие накладные расходы на стеки вызовов и контексты синхронизации.
• Отсутствие детерминированного планирования для игрового цикла (например, интеграции с UnitySynchronizationContext).
• Нехватка легковесных корутин, аналогичных UniTask (сторонняя библиотека для Unity), но на уровне языка.

Что уже улучшается и возможные обходные пути

Некоторые проблемы решаются:

• Records и pattern matching упрощают работу с данными.
• Nullable reference types помогают избежать null-ссылок.
• Сообщество создаёт библиотеки (например, UniTask, MemoryPack).

В Unity часто используют гибридные подходы:

• C++ плагины для критичных по производительности участков.
• Пользовательские allocators и пулы объектов.
• Code generation через редактор или сторонние инструменты.

Заключение

C# активно развивается, но для game development, особенно в высоконагруженных проектах, не хватает низкоуровневого контроля, предсказуемой производительности и удобных абстракций для DOP. Многие разработчики Unity вынуждены использовать обходные пути или смешивать C# с другими технологиями. Идеальным был бы язык, сочетающий безопасность C# с производительностью C++ и гибкостью Rust, но пока такого решения нет в экосистеме Unity.