Логотип проекта Unity

UnityScript: Долгий путь навстречу закату

UnityScript: Долгий путь навстречу закату

Оригинал на Blogs.Unity3D
Автор перевода: alexprey
Редактор: jusper


UnityScript существует с самой первой версии Unity 1.0, но время его жизни приближается к концу. Разработчики потихоньку прекращают поддержку UnityScript. Напомним, что это JavaScript-подобный язык программирования, предлагаемый в качестве альтернативы языку C#.

В этом посте мы не будем углубляться в детали решения, а кратко подведем итоги. Поддержка UnityScript тормозит расширение новых функций, связанных со скриптингом, особенно, учитывая что только 3.6% проектов, действительно используют его полноценно.

Почему?

Каждый раз когда разработчики удаляют что-то из Unity, они всегда понимают, что часть пользователей будут испытывать неудобство.

Сейчас с системой скриптов Unity происходит много всего разного . Вот несколько самых важных изменений:

  1. Обновление среды исполнения скриптов, позволяющее использовать более современные стандартны C# (.NET 4.6 & C# 6).
  2. JobSystem, дающий возможность легко писать многопоточный код таким образом, что он будет оберегать вас от проблемы гонок потоков (race conditions) и мертвых петель (deadlocks).
  3. Новый тип данных NativeArray, который позволит создавать и работать с огромными массивами. Он управляется нативным кодом и предоставляет вам гибкий и прозрачный процесс для работы с памятью, избегая Garbage Collector.
  4. Контроль над процессом сборки скриптов, который можно конфигурировать на свое усмотрение.

Это всего-лишь небольшая часть того, над чем разработчики работают прямо сейчас. На деле изменений в разы больше. В дополнение к специальным скриптовым проектам юнитисты (вольность перевода автора) увеличивают скорость запуска движка и расширяют API, который позволит поддерживать более современные языковые конструкции.

Сегодня, UnityScript и C# примерно сопоставимы в рамках функциональности и производительности: нет ничего, что вы можете сделать в C# и не сможете на UnityScript. С# берет первенство, когда речь заходит о создании экосистемы разработки - это не только миллионы различных документаций и уроков, но и наборы поддерживаемых инструментов как рефакторинг или IntelliSense в Visual Studio. Но ведь UnityScript работает, и зачем мне использовать эти бесполезные инструменты, спросите вы?

Справедливо, но такая справедливость недолговечна. Разрабочики улучшают среду исполнения скриптов и поддерживаемую версию стандарта C#, а это начало пути, в котором UnityScript начнет проигрывать. Сейчас нет поддержки значений по-умолчанию для параметров метода, а также множество других классных функций и конструкций C# (например, использование ссылочных параметров (ref return) приводит к некоторым проблемам). Сейчас эти функции языка не используются в API, но юнитисты хотят их поддерживать!

Все это программный код и нужно время, чтобы реализовать все эти недостающие кусочки в UnityScript. Однако, время - деньги. Необходимо отвлекать инженера, который занимается поддержкой и актуализацией UnityScript от важной работы над новой крутой функциональностью (о который рассказывалось выше) или от исправления багов. Это даже не говоря о поддержке Script Updater и актуализации документации..


Но давайте посмотрим, что мы имеем с другой стороны: как много пользователей затронет это решение? Редактор периодически присылает нам данные о ваших проектах (прим. переводчика - БОЛЬШОЙ БРАТ СЛЕДИТ ЗА ВАМИ). Итак, статистика:

  • На момент использования Unity 5.6 около 14.6% имеют хотя бы один файл с расширением .js
  • 85.4% полностью используют C# и не содержат ни одного UnityScript файла
  • 9.5% в основном используют C# и парочку UnityScript файлов, но это составляет менее 10% от общего числа используемых файлов скриптов. Еще 1.5% всех проектов используют UnityScript от 10% до 20% от всего кода
  • Оставшиеся 3.6% имеют более 20% кода на UnityScript
  • И лишь только 0.8% всех проектов исключительно разработаны (на все 100%) на UnityScript

В основном решение юнитистов сильно повлияет на пользователей, кто по прежнему использует код на UnityScript, но в основном предпочитает C#. Возможно он даже активно вами и не используется: .js файл в проекте, может быть примером скрипта для пакета в Asset Store. Соответственно, самый первый шаг завершения поддержки UnityScript - это работа с разработчиками для Asset Store, чтобы уведомить их о прекращении передачи таких файлов.

Тем 3.6% пользователей, которые частично используют UnityScript, и отдельно 0.8%, чей код состоит только из UnityScript, разработчики приносят свои извинения. Принятое решение для вас - это полная лажа ( sucks for you ). Юнитисты обещают предпринять шаги, чтобы смягчить переход.

Что будет дальше?

Резкого выдергивания вилки из электропитания не будет. А будет следующее:

Первым делом, еще в начале Июня изменилась политика публикаций новых ассетов для Asset Store - все ассеты, содержащие UnityScript теперь отклоняются. Весь новый код, который вы пишите должен быть написан только на C#.
Скоро запустится сканирования всех существующих пакетов в Asset Store для поисках содержащих UnityScript. Авторам будет направлена просьба об изменении кода на C#. После этого неисправленные ассеты будут удалены из магазина.

Во-вторых, Unity 2017.2 beta больше не поддерживает опцию создания JavaScript (UnityScript) в меню редактора. Но вы по прежнему сможете создавать новые скрипты вне редактора Unity (например, с помощью MonoDevelop).

В-третьих, юнитисты начинают работу над специальным инструментом для автоматической конвертации UnityScript в C#. На самом деле, он уже существует, но работает не совсем так, как хотелось бы. Разработчики еще не решили, что это будет - встроенное решение в редактор Unity или отдельный инструмент с открытым исходным кодом. Скорее всего дело прояснится уже к релизу Unity 2017.2.

Разработчики надеятся, что процесс отказа от UnityScript пройдет сказочно быстро и просто - в особенности для группы, которая использует UnityScript только на 10%.

Как только будет понимание, что уровень использования UnityScript стал достаточно низким, юнитисты перестанут поставлять специальный компилятор, а юнька разучится распознавать .js файлы, как код пользовательских скриптов. Все примеры из документации будут также удалены.

Компилятор UnityScript по прежнему останется доступным для пользователей, он размещается на нашем аккаунте GitHub - https://github.com/Unity-Technologies/unityscript.

Немного о Boo

Разработчики анонсировали еще в 2014 году, что прекращают поддержку Boo в документации и в редакторе Unity. Но компилятор Boo по-прежнему оставался на месте, потому что UnityScript на самом деле это более высокая обертка над Boo и использует его библиотеки, а так же компилятор UnityScript был написан на Boo.

Удаление UnityScript также означает, что можно окончательно избавляться от компилятора Boo. Это затронет, лишь 0.2% проектов на версии Unity 5.6, содержащие хотя бы один файл с расширением .boo, и еле заметные 0.006% проектов, которые содержат больше трех файлов с таким расширением.


Мнение переводчика

Лично я считаю, что это это правильное решение и очень надеюсь на то, что отказ от UnityScript поможет им улучшить поддержку самых последних версий C#. А что думаете вы?


Если вы нашли неточность в тексте перевода, пишите об этом в комментариях.

перевод


Считаю это правильным шагом.
Это был какой-то недоязык, который конвертился в шарп/бу, что как бы дикость. Новичкам нравился, но дикость она и есть дикость.
+Теперь сэкономят на документации под язык.
Единственный минус это то, что уйдет поддержка скриптов старых на нём, их много, но к счастью не критично много.
Жаль что убирают Boo. Хотя при отсутствии нормальной среды под язык он оставался непопулярным, таким и останется, но все таки в языке действительно были удобные функции

Devion, ну сам Boo они еще очень давно хотели выпилить. А на счет старых скриптов, то я так понял, что будет тулза, которая сконвертирует это в шарп, наверняка не без проблем, но все же.

Единственное, что меня настораживает, что пропадает легкий способ сделать что-то простенько-заскриптованное, типа сцены. Но я так понимаю на замену простым скриптам придет что-то вроде визуального программирования, хотя я не уверен. Еще не успел пощупать их новый таймлайн, возможно он сойдет для этого

alexprey,

возможно он сойдет для этого

Таймлайн предназначен для быстрой, нечерезжопной реализации катсцен. В купе с доп. инструментами можно делать годноту по кнопке "вжух", не дергая кодера, что довольно выгодно.
Простенькое заскриптованное уровня, например?

Jusper,

Простенькое заскриптованное уровня, например?

Да, хотя бы обычный рычаг или что-то вроде этого. При нажатии сделать несколько действий, вроде открыть двери и заспавнить мобов.