Wayland навязывает 3D. Это не так, обязательна только компоновка. Об этом уже было сказано выше.
А без неё совсем никак? Дело в том, что при включенном композитинге всегда навязывается VSync, по крайней мере, из моей практики и из написанного в статье. А VSync даёт ощутимый input lag в шутерах, например. Играешь будто в киселе. Если никак нельзя его форсированно выключить, то это ставит крест на соревновательных FPS под линуксом.
Не вижу причин не попробовать хотя бы. Я сам пишу веб-приложения по работе исключительно на нём вот уже почти пять лет, и создаётся впечатление, что это действительно единственный веб-фреймворк done right, особенно, если любовь к статической типизации и десктопо-подобному софту выше, чем стремление освоить очередной JS-фреймворк. Я, скажем так, не фанат JS и DOM.
GWT позволяет писать сервер и клиент на одном и том же языке, не переключая контекст в мозгу, это хорошо, если в команде мало людей или ты вообще один (как и было в моём случае). Не могу сказать насчёт дизайна/вёрстки/изысков в области UI/UX, мы используем GWT Bootstrap, и в принципе, всё работает пристойно. Выглядит, наверно, победнее, чем сейчас принято, но всё это внутренний софт для разнообразного учёта и не только. Возможно, если бы стояла такая цель, можно было бы сделать круто и красиво, было б желание — никто не запрещает использовать CSS, HTML, native JS вместе с GWT, он отлично со всем этим делом интеропится, и я кое-где использовал стилизацию и JSNI.
Основные плюсы — единообразие структур данных и, порой, даже части кода между сервером и клиентом, т.к. это физически один и тот же класс, один и тот же код, просто для клиента он транспилируется в JS. Отладка в Eclipse тоже прозрачная между клиентом и сервером (нужен плагин SDBG и Chrome), т.е. можно ставить брейкпоинты в клиентском и серверном коде, трейсить этот код и смотреть переменные, как будто всё написано на Java. Также можно в клиентских исключениях получать трейсбэк с номерами строк в Java-коде.
Вся сериализация и проверки на безопасность уже встроены, можно подцеплять Hibernate и Dozer (для маппинга, чтобы сериализатор не спотыкался на ленивой загрузке), Shiro для авторизации и вперёд. Многие, похоже, используют Spring, но мне он как-то не требовался. Если какая-то структура в БД меняется, это автоматически доступно на клиенте, всё статически типизировано, т.е. веб-приложение является цельным, а не разделено на независимые фронт и бэк. Отсюда все плюсы-минусы, конечно. Скорее всего, я бы не стал делать на GWT какой-то публичный сервис с внешним API и большой командой разработчиков, но для внутренних задач, пожалуй, ничего лучше не найти.
Я немного не в тему, потому что про Java, но эти языки очень похожи. В GWT похожий способ, правда, не совсем иерархический. Пишется интерфейс, расширяющий пустой интерфейс-маркер из состава GWT, его методы возвращают String, а в параметры можно передавать аргументы строки. Сама строка описывается через аннотацию @DefaultMessage (в дефолтной локали) + в ini-файлах, которые можно сгенерировать через инструментарий, также можно задать плюрализацию и дополнительные произвольные аргументы, например, пол пользователя. К сожалению, в .ini уже статически не проверить соответствие ключа имени метода в интерфейсе, так что опечатки всё равно не исключены полностью, но возможно, есть какой-то способ для конкретных IDE.
Далее в коде инстанциируется этот интерфейс через GWT.create (под капотом создаётся прокси-объект, через рефлексию вытаскивающий нужную строку), и можно у такого объекта вызывать методы, получая в ответ локализованные строки. Локаль можно задавать разными способами, от GET-параметра до кук и ручной установки.
Мне такие способы тоже нравятся за проверку правильности ключа, но кроме того, интерфейсы могут расширять друг друга. Например, так я сделал интерфейс CommonMessages со строками, которыми постоянно везде пользуюсь (типа Ok, Cancel, Print, Yes, No и т.д.) и дальше наследуюсь уже от него. На уровне языка получается прозрачный и проверяемый на корректность доступ к этим сообщениям, что позволяет вынести такую общую локализацию в отдельную библиотеку и не дублировать её в каждом проекте. Очень жаль, что стандартная техника локализации во многих фреймворках, языках и платформах делается через обычные строки, а не через систему типов. Неоднократно встречал в локализации проектов на transifex, например, несколько похожих строк, которые отличаются одним пробелом или точкой в конце, наверняка ведь можно было заменить их одной, если бы это было реализовано через тип.
Ну, интуитивная понятность и эффективность довольно-таки ортогональны. Далеко необязательно программа, с которой можно разобраться методом тыка, оказывается самой мощной, надёжной, быстрой и в целом эффективной в своём классе, чем та, которую следует вдумчиво изучать, читать мануал и смотреть туториалы. Ваш редактор, судя по скриншотам, довольно базового уровня, тогда как Blender включает в себя практически полный инструментарий не только для рендера, но и композитинга и редактирования видео.
Да понятно, просто советую попробовать и Krita. Ещё есть My Paint, но он очень сильно ориентирован на художников, редактирование и ретушь там по факту отсутствуют.
Верхнее меню, технически, относится к совсем другой панели, см. выпадающий список слева. Сверху находятся параметры программы в целом — работа с файлами, с рендером, выбор организации окон в соответствии с видом деятельности (моделирование, скульптинг, текстурирование, анимация и т.д.). Но если вам нужно меню сверху, кликните правой кнопкой по меню и выберите Header ⇒ Flip to top (это будет выглядеть странно). Больше вопрос привычки, тем более, в эти меню мне, например, приходилось залезать только чтобы узнать/вспомнить хоткей. Для быстрого выполнения функций советую нажимать пробел и писать там желаемое, очень круто сделано. Ну и в настройках есть пресеты для клавиш и поведения мыши под популярные программы (3DS Max, Maya), выделение правой кнопкой нравится не всем.
В целом, было бы желание, а подстроить программу под свои вкусы не так сложно. Панельный интерфейс так и подавно киллер-фича, на мой взгляд.
Конечно, если всё устраивает, то смысла менять редактор нет. Но всё же безапелляционно заявлять о безальтернативности, как это часто делают, на мой взгляд, не стоит (это не к вам претензия, конечно). Для очень большого числа задач Krita хорошо подойдёт. Adobe несколько зарвались уже и накручивают цену на свою продукцию, ничего нового толком не привнося (что и доказывает ваша статья) + применяют облачный lock-in из-за отсутствия конкуренции. Я считаю этот подход порочным, так что развитие Krita будет полезно не только её непосредственным пользователям, но и пользователям Adobe, для которых могут появиться более выгодные условия использования их ПО.
то стоит сделать ещё один заход, потому что сейчас он
стал намного лучше
Раньше я тоже терялся в странно расположенных опциях и «пластиковом» интерфейсе, в итоге, забросил, не сделав толком ничего (тоже до этого немного работал в Lightwave, кстати). Однако его переделали, причесали, получилось сделать небольшую сценку и анимацию без каких-либо затруднений в плане UI. А хоткеи всё равно надо учить для любой профессиональной программы, и здесь они довольно неплохи.
Все знают про GIMP и обожают его пинать в каждом подобном треде, тем более, он толком уже не развивается много лет. Этакая опенсорсная кукла для битья. Но почему бы не сравнивать с Krita, которая также есть для Mac? Как по мне, она намного ближе к фотошопу и активно разрабатывается, разве что векторные/текстовые инструменты пока довольно убогие, но это в работе, благодаря последнему кикстартеру. Только хотелось бы честного сравнения возможностей, без учёта очевидного vendor lock-in в виде формата PSD.
Парадокс легко решается, если понять, что «сознание» — это абстракция, иллюзия. Это работа мозга, которая направлена на построение модели окружающего мира, которая включает в себя сам мозг и его носитель, тело. Это поступающие данные от органов чувств и мыслительная работа в контексте предыдущего опыта (памяти). Не более. Просто эта абстракция порождает «ощущение Я», которое мозг отказывается считать побочным эффектом симуляции и возводит в ранг чего-то особенного, некопируемого и уникального во всём животном мире. А по сути это такая фича, которая немного баг и может немного мешать эффективно жить.
Поэтому копировать можно что угодно, и каждый экземпляр будет воспринимать себя настоящим, просто потому что он так работает. И никакого Я не существует.
Сайт не претендует на истину в последней инстанции, но позволяет неплохо прикинуть потенциал производительности по CPU и RAM для популярных языков на вполне практических, пусть и не повседневных задачах. А так никто не спорит, что без конкретного приложения, по которому неоднократно прошлись профайлером, абстрактные споры смысла не имеют.
Ну, зависит от конторы. У нас нет фронтэндщиков, дизайнеров, верстальщиков, пишем программы вдвоём. Главный критерий — чтобы выполняло поставленную задачу (преимущественно учёт всех сортов, иногда задачи типа хелпдеска или системы оповещения населения). Дизайна из бутстрапа более чем хватает. Конечно, если делать на продажу и вообще на экспорт, всё сложнее, и с таким мне пока сталкиваться не доводилось.
Это обычно сочетание множества факторов, но конкретно Java и JVM там ближе к концу списка. Вот неэффективные фреймворки, да ещё и неправильно и неуместно применённые, ORM с избыточными выборками и N+1 problem, неэффективные модели данных, просто индусский код — это да. Сам пишу на ней, родимой, уже пять лет, и всё это знаю не понаслышке. Ещё на Java пишут как правильно большие и сложные системы, так что если оно тормозит, возможно, на другом языке оно тормозило бы ещё сильнее (хоть и не факт, т.к. см. выше).
Спасибо. Но это действительно неоправданные ограничения какие-то (если было бы 5€ в год, тогда ещё можно понять), за эти деньги можно взять полноценную VDS без лимитов на процессы и время. Я сам покупаю у LeaseWeb, там 4.95€. У OVH можно взять за 2.99€, да, чуть дороже, но зато свой сервер для чего угодно. Я к тому, что ассемблер для сайта был выбран всё же не только потому, что это было интересно, но и для того, чтобы вписаться в отведённые ресурсы. Сейчас можно примерно за те же деньги получить сервер с намного более хорошими характеристиками и ни в чём себе не отказывать.
Я в основном пишу веб-приложения, т.е. не сайты, а именно аналог десктопа, но в вебе. Там чем меньше знаешь и используешь вышеперечисленное, тем лучше. Можно сосредоточиться на бизнес-логике, когда сервер и клиент суть почти одно целое. Разумеется, далеко не у всех так.
Wt вряд ли подойдёт для крупномасштабных приложений, в частности, потому что почти любое действие на клиенте вызывает запрос к серверу. Отзывчивость приложения напрямую зависит от пинга до сервера. Но для embedded это то, что доктор прописал. Компактно, быстро, а если располагается в локалке, то пинг можно считать близким к нулю. Но в целом, фреймворк любопытный и стоит того, чтобы его хотя б потыкать.
А меня заинтересовали параметры хостинга. Такого ада я ещё не видел, чтобы было ограничение на потребление процессорного времени, да ещё посуточно + ограничение на процессы, но при этом можно запускать свой бинарный код, т.е. не PHP/MySQL-only. Как я понял, хостится ваше приложение на https://www.superhosting.bg (судя по IP), но похожего плана у них не видно. Просто интересно, сколько такое может стоить.
По теме: если кого-нибудь интересует веб-разработка на сравнительно низкоуровневых языках, могу посоветовать взглянуть на Wt — приятный виджетоориентированный фреймворк на C++, fullstack. На хабре немного было про него, но довольно старое всё. Я переписал один небольшой проект «для своих» с Java на Wt, сэкономил кучу памяти, т.к. на VDS её всего 1 Гб. Сейчас ест примерно 10 Мб, не течёт.
Понятно, что какие-то личные проекты можно писать на чём угодно, в том числе и на ассемблере, но в современном мире ценится не потребление памяти или скорость работы, а поддерживаемость продукта, т.к. человеческое время ценится на порядки дороже машинного. Этим можно быть недовольным, но остаётся лишь смириться.
Было такое на двух Nexus 10. На некоторое время помогает зарядка в выключенном состоянии, когда на экране в процессе нарисована только батарея. Я так понял, когда ОС не загружена, там как-то иначе определяется ёмкость, что позволяет зарядить батарею до конца — процесс реально долгий, может занять часов 10, тогда как во включенном состоянии в 100% упирается за часа 4. Зато потом внезапные отключения пропадают. Если с первого раза не помогло, надо повторить. То есть, это вроде бы калибровка батареи, но больше похоже на более полную зарядку.
Это и есть ручная оптимизация — под каждую платформу код пишется на ассемблере с учётом особенностей этой платформы. Я же говорил про оптимизацию компилятором, как это делает GCC или clang. AES вряд ли соптимизирует, это уж слишком мощное распознавание должно быть, но SSE/AVX применяются автоматически, разработчик же продолжает писать на C или C++, никак не вникая в ассемблер и не подсказывая компилятору. Т.к. эти векторные инструкции (вроде как) недоступны, например, на ARM, там GCC скомпилирует код без них, используя стандартные возможности. Я полагаю, что Go так не умеет, и только об этом и говорил. А использовать интринсики или напрямую ассемблерный код, конечно, можно во многих языках и компиляторах, но это неинтересно в рамках данной темы.
А без неё совсем никак? Дело в том, что при включенном композитинге всегда навязывается VSync, по крайней мере, из моей практики и из написанного в статье. А VSync даёт ощутимый input lag в шутерах, например. Играешь будто в киселе. Если никак нельзя его форсированно выключить, то это ставит крест на соревновательных FPS под линуксом.
В контейнере, но несколько моих программ работают и standalone с помощью Jetty embedded. Всё целиком находится в одном .war.
Не вижу причин не попробовать хотя бы. Я сам пишу веб-приложения по работе исключительно на нём вот уже почти пять лет, и создаётся впечатление, что это действительно единственный веб-фреймворк done right, особенно, если любовь к статической типизации и десктопо-подобному софту выше, чем стремление освоить очередной JS-фреймворк. Я, скажем так, не фанат JS и DOM.
GWT позволяет писать сервер и клиент на одном и том же языке, не переключая контекст в мозгу, это хорошо, если в команде мало людей или ты вообще один (как и было в моём случае). Не могу сказать насчёт дизайна/вёрстки/изысков в области UI/UX, мы используем GWT Bootstrap, и в принципе, всё работает пристойно. Выглядит, наверно, победнее, чем сейчас принято, но всё это внутренний софт для разнообразного учёта и не только. Возможно, если бы стояла такая цель, можно было бы сделать круто и красиво, было б желание — никто не запрещает использовать CSS, HTML, native JS вместе с GWT, он отлично со всем этим делом интеропится, и я кое-где использовал стилизацию и JSNI.
Основные плюсы — единообразие структур данных и, порой, даже части кода между сервером и клиентом, т.к. это физически один и тот же класс, один и тот же код, просто для клиента он транспилируется в JS. Отладка в Eclipse тоже прозрачная между клиентом и сервером (нужен плагин SDBG и Chrome), т.е. можно ставить брейкпоинты в клиентском и серверном коде, трейсить этот код и смотреть переменные, как будто всё написано на Java. Также можно в клиентских исключениях получать трейсбэк с номерами строк в Java-коде.
Вся сериализация и проверки на безопасность уже встроены, можно подцеплять Hibernate и Dozer (для маппинга, чтобы сериализатор не спотыкался на ленивой загрузке), Shiro для авторизации и вперёд. Многие, похоже, используют Spring, но мне он как-то не требовался. Если какая-то структура в БД меняется, это автоматически доступно на клиенте, всё статически типизировано, т.е. веб-приложение является цельным, а не разделено на независимые фронт и бэк. Отсюда все плюсы-минусы, конечно. Скорее всего, я бы не стал делать на GWT какой-то публичный сервис с внешним API и большой командой разработчиков, но для внутренних задач, пожалуй, ничего лучше не найти.
Я немного не в тему, потому что про Java, но эти языки очень похожи. В GWT похожий способ, правда, не совсем иерархический. Пишется интерфейс, расширяющий пустой интерфейс-маркер из состава GWT, его методы возвращают String, а в параметры можно передавать аргументы строки. Сама строка описывается через аннотацию @DefaultMessage (в дефолтной локали) + в ini-файлах, которые можно сгенерировать через инструментарий, также можно задать плюрализацию и дополнительные произвольные аргументы, например, пол пользователя. К сожалению, в .ini уже статически не проверить соответствие ключа имени метода в интерфейсе, так что опечатки всё равно не исключены полностью, но возможно, есть какой-то способ для конкретных IDE.
Далее в коде инстанциируется этот интерфейс через GWT.create (под капотом создаётся прокси-объект, через рефлексию вытаскивающий нужную строку), и можно у такого объекта вызывать методы, получая в ответ локализованные строки. Локаль можно задавать разными способами, от GET-параметра до кук и ручной установки.
Мне такие способы тоже нравятся за проверку правильности ключа, но кроме того, интерфейсы могут расширять друг друга. Например, так я сделал интерфейс CommonMessages со строками, которыми постоянно везде пользуюсь (типа Ok, Cancel, Print, Yes, No и т.д.) и дальше наследуюсь уже от него. На уровне языка получается прозрачный и проверяемый на корректность доступ к этим сообщениям, что позволяет вынести такую общую локализацию в отдельную библиотеку и не дублировать её в каждом проекте. Очень жаль, что стандартная техника локализации во многих фреймворках, языках и платформах делается через обычные строки, а не через систему типов. Неоднократно встречал в локализации проектов на transifex, например, несколько похожих строк, которые отличаются одним пробелом или точкой в конце, наверняка ведь можно было заменить их одной, если бы это было реализовано через тип.
У deeplearning4j есть неплохие объяснения про тензоры для не-математиков: раз и два.
Ну, интуитивная понятность и эффективность довольно-таки ортогональны. Далеко необязательно программа, с которой можно разобраться методом тыка, оказывается самой мощной, надёжной, быстрой и в целом эффективной в своём классе, чем та, которую следует вдумчиво изучать, читать мануал и смотреть туториалы. Ваш редактор, судя по скриншотам, довольно базового уровня, тогда как Blender включает в себя практически полный инструментарий не только для рендера, но и композитинга и редактирования видео.
Да понятно, просто советую попробовать и Krita. Ещё есть My Paint, но он очень сильно ориентирован на художников, редактирование и ретушь там по факту отсутствуют.
Верхнее меню, технически, относится к совсем другой панели, см. выпадающий список слева. Сверху находятся параметры программы в целом — работа с файлами, с рендером, выбор организации окон в соответствии с видом деятельности (моделирование, скульптинг, текстурирование, анимация и т.д.). Но если вам нужно меню сверху, кликните правой кнопкой по меню и выберите Header ⇒ Flip to top (это будет выглядеть странно). Больше вопрос привычки, тем более, в эти меню мне, например, приходилось залезать только чтобы узнать/вспомнить хоткей. Для быстрого выполнения функций советую нажимать пробел и писать там желаемое, очень круто сделано. Ну и в настройках есть пресеты для клавиш и поведения мыши под популярные программы (3DS Max, Maya), выделение правой кнопкой нравится не всем.
В целом, было бы желание, а подстроить программу под свои вкусы не так сложно. Панельный интерфейс так и подавно киллер-фича, на мой взгляд.
Конечно, если всё устраивает, то смысла менять редактор нет. Но всё же безапелляционно заявлять о безальтернативности, как это часто делают, на мой взгляд, не стоит (это не к вам претензия, конечно). Для очень большого числа задач Krita хорошо подойдёт. Adobe несколько зарвались уже и накручивают цену на свою продукцию, ничего нового толком не привнося (что и доказывает ваша статья) + применяют облачный lock-in из-за отсутствия конкуренции. Я считаю этот подход порочным, так что развитие Krita будет полезно не только её непосредственным пользователям, но и пользователям Adobe, для которых могут появиться более выгодные условия использования их ПО.
А в каком году пробовали? Если когда он выглядел
Раньше я тоже терялся в странно расположенных опциях и «пластиковом» интерфейсе, в итоге, забросил, не сделав толком ничего (тоже до этого немного работал в Lightwave, кстати). Однако его переделали, причесали, получилось сделать небольшую сценку и анимацию без каких-либо затруднений в плане UI. А хоткеи всё равно надо учить для любой профессиональной программы, и здесь они довольно неплохи.
Все знают про GIMP и обожают его пинать в каждом подобном треде, тем более, он толком уже не развивается много лет. Этакая опенсорсная кукла для битья. Но почему бы не сравнивать с Krita, которая также есть для Mac? Как по мне, она намного ближе к фотошопу и активно разрабатывается, разве что векторные/текстовые инструменты пока довольно убогие, но это в работе, благодаря последнему кикстартеру. Только хотелось бы честного сравнения возможностей, без учёта очевидного vendor lock-in в виде формата PSD.
Парадокс легко решается, если понять, что «сознание» — это абстракция, иллюзия. Это работа мозга, которая направлена на построение модели окружающего мира, которая включает в себя сам мозг и его носитель, тело. Это поступающие данные от органов чувств и мыслительная работа в контексте предыдущего опыта (памяти). Не более. Просто эта абстракция порождает «ощущение Я», которое мозг отказывается считать побочным эффектом симуляции и возводит в ранг чего-то особенного, некопируемого и уникального во всём животном мире. А по сути это такая фича, которая немного баг и может немного мешать эффективно жить.
Поэтому копировать можно что угодно, и каждый экземпляр будет воспринимать себя настоящим, просто потому что он так работает. И никакого Я не существует.
Тестов там много для разных языков. Не для всех выведены ссылки, но минимальная смекалка приводит к сравнению PHP против Java. Тесты могут быть не идеальны, и не стоит делать поспешных выводов. Если есть идеи, как переписать тест, чтобы он стал эффективнее и переиграл другие языки, можно прислать свой вариант.
Сайт не претендует на истину в последней инстанции, но позволяет неплохо прикинуть потенциал производительности по CPU и RAM для популярных языков на вполне практических, пусть и не повседневных задачах. А так никто не спорит, что без конкретного приложения, по которому неоднократно прошлись профайлером, абстрактные споры смысла не имеют.
Ну, зависит от конторы. У нас нет фронтэндщиков, дизайнеров, верстальщиков, пишем программы вдвоём. Главный критерий — чтобы выполняло поставленную задачу (преимущественно учёт всех сортов, иногда задачи типа хелпдеска или системы оповещения населения). Дизайна из бутстрапа более чем хватает. Конечно, если делать на продажу и вообще на экспорт, всё сложнее, и с таким мне пока сталкиваться не доводилось.
Это обычно сочетание множества факторов, но конкретно Java и JVM там ближе к концу списка. Вот неэффективные фреймворки, да ещё и неправильно и неуместно применённые, ORM с избыточными выборками и N+1 problem, неэффективные модели данных, просто индусский код — это да. Сам пишу на ней, родимой, уже пять лет, и всё это знаю не понаслышке. Ещё на Java пишут как правильно большие и сложные системы, так что если оно тормозит, возможно, на другом языке оно тормозило бы ещё сильнее (хоть и не факт, т.к. см. выше).
Спасибо. Но это действительно неоправданные ограничения какие-то (если было бы 5€ в год, тогда ещё можно понять), за эти деньги можно взять полноценную VDS без лимитов на процессы и время. Я сам покупаю у LeaseWeb, там 4.95€. У OVH можно взять за 2.99€, да, чуть дороже, но зато свой сервер для чего угодно. Я к тому, что ассемблер для сайта был выбран всё же не только потому, что это было интересно, но и для того, чтобы вписаться в отведённые ресурсы. Сейчас можно примерно за те же деньги получить сервер с намного более хорошими характеристиками и ни в чём себе не отказывать.
Я в основном пишу веб-приложения, т.е. не сайты, а именно аналог десктопа, но в вебе. Там чем меньше знаешь и используешь вышеперечисленное, тем лучше. Можно сосредоточиться на бизнес-логике, когда сервер и клиент суть почти одно целое. Разумеется, далеко не у всех так.
Wt вряд ли подойдёт для крупномасштабных приложений, в частности, потому что почти любое действие на клиенте вызывает запрос к серверу. Отзывчивость приложения напрямую зависит от пинга до сервера. Но для embedded это то, что доктор прописал. Компактно, быстро, а если располагается в локалке, то пинг можно считать близким к нулю. Но в целом, фреймворк любопытный и стоит того, чтобы его хотя б потыкать.
А меня заинтересовали параметры хостинга. Такого ада я ещё не видел, чтобы было ограничение на потребление процессорного времени, да ещё посуточно + ограничение на процессы, но при этом можно запускать свой бинарный код, т.е. не PHP/MySQL-only. Как я понял, хостится ваше приложение на https://www.superhosting.bg (судя по IP), но похожего плана у них не видно. Просто интересно, сколько такое может стоить.
По теме: если кого-нибудь интересует веб-разработка на сравнительно низкоуровневых языках, могу посоветовать взглянуть на Wt — приятный виджетоориентированный фреймворк на C++, fullstack. На хабре немного было про него, но довольно старое всё. Я переписал один небольшой проект «для своих» с Java на Wt, сэкономил кучу памяти, т.к. на VDS её всего 1 Гб. Сейчас ест примерно 10 Мб, не течёт.
Понятно, что какие-то личные проекты можно писать на чём угодно, в том числе и на ассемблере, но в современном мире ценится не потребление памяти или скорость работы, а поддерживаемость продукта, т.к. человеческое время ценится на порядки дороже машинного. Этим можно быть недовольным, но остаётся лишь смириться.
Было такое на двух Nexus 10. На некоторое время помогает зарядка в выключенном состоянии, когда на экране в процессе нарисована только батарея. Я так понял, когда ОС не загружена, там как-то иначе определяется ёмкость, что позволяет зарядить батарею до конца — процесс реально долгий, может занять часов 10, тогда как во включенном состоянии в 100% упирается за часа 4. Зато потом внезапные отключения пропадают. Если с первого раза не помогло, надо повторить. То есть, это вроде бы калибровка батареи, но больше похоже на более полную зарядку.
Это и есть ручная оптимизация — под каждую платформу код пишется на ассемблере с учётом особенностей этой платформы. Я же говорил про оптимизацию компилятором, как это делает GCC или clang. AES вряд ли соптимизирует, это уж слишком мощное распознавание должно быть, но SSE/AVX применяются автоматически, разработчик же продолжает писать на C или C++, никак не вникая в ассемблер и не подсказывая компилятору. Т.к. эти векторные инструкции (вроде как) недоступны, например, на ARM, там GCC скомпилирует код без них, используя стандартные возможности. Я полагаю, что Go так не умеет, и только об этом и говорил. А использовать интринсики или напрямую ассемблерный код, конечно, можно во многих языках и компиляторах, но это неинтересно в рамках данной темы.