Сделать на go можно что угодно.
Мысль в том, что серверные многопоточные приложения быстрее и удобнее делать на go.
А для остальных особых преимуществ нет — дело вкуса.
Что я хотел сказать статьёй. «Написание определенных приложений занимает на go в несколько раз меньше времени и усилий чем на java. В том числе за счет более удобных инструментов.»
Нужно завести игровой сервер. Поднять там 2500 клиентов, каждый из которых будет отправлять в среднем 50 сообщений в секунду и получать примерно 750 (через web socket).
Работа gc замечается в едва заметных глазу лагах при передвижении игровых объектов.
Сервера бывают разные. Ваши полмиллина клиентов — это игровые клиетны в реальном времени, как у меня?
Кроме этого, вы не захотели понять суть статьи. Она не о том, что go — лучший язык.
И не о том, что в ява нет профайлеров.
Я сравнил усилия, которые от меня потребовали языки, чтобы сделать одно и то же. Go в данном случае потребовал в разы меньше.
Да, вы правы. В обоих случаях срабатывает AOT и мое сравнение некорректно, а разница в скорости связана с оптимизацией кода.
Я ошибочно связал два факта — существенную разницу в скорости и наличие директивы use asm в production билде при её отсутствии (ну нет её там!) в девелоперском.
FF, действительно влючает AOT несмотря на отсутствие директивы. Интересно, кстати, почему.
>Публичные версии юнити пока не умеют компилировать в WebAssambly
Да, но для целей сравнения скорости достаточно сравнить asm.js и обычный js. Потому что на даный момент WebAssembly — просто бинарное представление asm.js и работает оно ровно с той же скоростью. Разница лишь во времени на скачивание, разархивирование и парсинг. Всё это происходит при инициализации. А дальше скорость одинакова.
>В js в браузере нет интерпретатора, есть разные виды компиляторов.
JIT, конечно есть. Тут я был неточен. Но я хотел сравнить js без AOT и webassembly (где AOT есть всегда).
>Наличие директивы «use asm» никак не влияет на отладку. При открытом отладчике FF иногда отключает AOT компиляцию, но на отладку это не влияет
Возможно, это было просто предположение.
>Я проверил ради интереса — в обоих случаях работает AOT компиляция, так что все осмыслено и директива остается на месте.
А директива «use asm» у вас тоже есть в коде в обоих случаях? В моих девелоперских билдах её нет.
Если она у вас есть, то, видимо, мы используем разные настройки девелоперских билдов.
Если её у вас нет, то как именно вы определили, что AOT работает в обоих случаях?
Всё так. Но даже при том, что код, действительно оптимизирован в обоих случаях, AOT даёт ощутимую прибавку по сравнению с интерпретатором.
Что касается отключения AOT в девелоперском билде, полагаю, это сделано с целью облегчения отладки в браузерном дебагере. Хотя точно не знаю зачем.
Я про то и говорю. Я сравнил asm.js (который по скорости работы равен Webassembly) и обычный интерпретатор javascript (который исполнят в Unity девелоперские сборки)
Вы не правы. AOT компилятор включается только при наличии в скрипте директивы "use asm"
Так вот в девелоперском билде такой директивы нет (специально перепроверил сейчас)
И, хотя код тот же самый, но в девелоперском билде он исполняется интерпретатором js, а в production — прогоняется через AOT компилятор.
По поводу webassembly — если не использовать DOM, то он реально быстрее.
Например, если сравнить девелоперский build Unity игры на webgl (он на чистом яваскрипте) с production build (а он — на asm.js), то у второго FPS на 15-20% выше.
Разумеется, руководитель отдела не будет запускать тесты. Но он будет прислушваться к мнению экспертов (вот как вы слушали руководителя группы и сисадмина). А они уже при помощи тестов смогут лучше оценить новый продукт.
Вроде как суд между гуглом и ораклом закончился как раз обатным: So long as the specific code used to implement a method is different, anyone is free under the Copyright Act to write his or her own code to carry out exactly the same function or specification of any methods used in the Java API. It does not matter that the declaration or method header lines are identical (https://en.wikipedia.org/wiki/Oracle_America,_Inc._v._Google,_Inc.)
И так берут пока нет альтернатив. А вот если один продукт откроет тесты, а его конкурент — нет, то, скорее всего, первый получит конкурентное преимущество.
Мысль в том, что серверные многопоточные приложения быстрее и удобнее делать на go.
А для остальных особых преимуществ нет — дело вкуса.
Работа gc замечается в едва заметных глазу лагах при передвижении игровых объектов.
Кроме этого, вы не захотели понять суть статьи. Она не о том, что go — лучший язык.
И не о том, что в ява нет профайлеров.
Я сравнил усилия, которые от меня потребовали языки, чтобы сделать одно и то же. Go в данном случае потребовал в разы меньше.
Что касается quasar, я сравнивал сами языки, а не экосистему.
Именно поэтому я и не нашел её. Искал с двойными кавычками.
Я ошибочно связал два факта — существенную разницу в скорости и наличие директивы use asm в production билде при её отсутствии (ну нет её там!) в девелоперском.
FF, действительно влючает AOT несмотря на отсутствие директивы. Интересно, кстати, почему.
>Публичные версии юнити пока не умеют компилировать в WebAssambly
Да, но для целей сравнения скорости достаточно сравнить asm.js и обычный js. Потому что на даный момент WebAssembly — просто бинарное представление asm.js и работает оно ровно с той же скоростью. Разница лишь во времени на скачивание, разархивирование и парсинг. Всё это происходит при инициализации. А дальше скорость одинакова.
JIT, конечно есть. Тут я был неточен. Но я хотел сравнить js без AOT и webassembly (где AOT есть всегда).
>Наличие директивы «use asm» никак не влияет на отладку. При открытом отладчике FF иногда отключает AOT компиляцию, но на отладку это не влияет
Возможно, это было просто предположение.
>Я проверил ради интереса — в обоих случаях работает AOT компиляция, так что все осмыслено и директива остается на месте.
А директива «use asm» у вас тоже есть в коде в обоих случаях? В моих девелоперских билдах её нет.
Если она у вас есть, то, видимо, мы используем разные настройки девелоперских билдов.
Если её у вас нет, то как именно вы определили, что AOT работает в обоих случаях?
Что касается отключения AOT в девелоперском билде, полагаю, это сделано с целью облегчения отладки в браузерном дебагере. Хотя точно не знаю зачем.
Так вот в девелоперском билде такой директивы нет (специально перепроверил сейчас)
И, хотя код тот же самый, но в девелоперском билде он исполняется интерпретатором js, а в production — прогоняется через AOT компилятор.
Например, если сравнить девелоперский build Unity игры на webgl (он на чистом яваскрипте) с production build (а он — на asm.js), то у второго FPS на 15-20% выше.
С тестами так не выйдет.