На скриншоте ниже, согласно профайлеру, Slack занимает почти все ресурсы процессора. Интересно, чем это он там занимается?
Процесс был запущен в фоне когда это произошло. Я даже не взаимодействовал со Slack — я был на встрече. И заметил я это только из-за шума системы охлаждения моего ноутбука. Перезапуск Slack в этот раз решил проблему.
Но это нормально для Slack. В фоновом режиме Slack часто потребляет 5% процессора. Что он делает? Я без понятия.
Я готов поспорить, что команда разработчиков Slack тоже не знает. Сколько строк кода им пришлось написать чтобы их клиент работал? Я думаю в районе 50 тысяч. Возможно, 100 тысяч. Но Slack — не нативное приложение. Или не обычное нативное приложение. Он работает поверх Electron, а это значит, что когда вы его скачиваете, вы на самом деле скачиваете полную копию Google Chrome (скорее, Chromium — прим. пер.). Chrome на момент написания содержит 15 миллионов строк кода, не являющимися комментариями. Код непосредственно Slack составляет менее 1% объема загрузки.
Chrome сам по себе — тот ещё боров. Он большой и сложный. Он использует ОЗУ и процессор как будто больше на них никто не претендует и сильно уменьшает время жизни от батареи.
Вы можете думать о Slack как о маленькой программе на JavaScript, которая работает внутри другой операционной системы (виртуальной машины) Chrome, которую вы запускаете чтобы, в сущности, пользоваться аналогом IRC. Даже если сам Chrome у вас уже запущен, то каждое приложение на Electron разворачивает свою, дополнительную копию.
И называть Chrome операционной системой — это не преувеличение. По количеству строк кода Chrome практически такого же размера как ядро Linux. Как и у ядра Linux у него есть API для различного оборудования, включая OpenGL, VR, MIDI. Он содержит встроенную копию SQLite, систему управления памятью и свой собственный диспетчер задач. На macOS в нём даже есть драйвер USB для игрового контроллера Xbox 360. (Я знаю что он там, потому что я его и написал. Извините.)
Содержит ли Slack мой код для контроллера Xbox? Знает ли команда Slack об этом? Знает ли об этом хоть кто-то? Slack занимает 160 Мб на диске. Это порядка 70 несжатых копий Властелина Колец. Другие приложения Electron на моем компьютере — Spotify (200 Мб) и Atom (260 Мб). Linux я впервые установил при помощи дискет. Понадобится 450 дискет, чтобы записать эти три простых приложения. Все вместе они весят как настольный дистрибутив Ubuntu. Который, думаю, содержит в себе клиент IRC, текстовый редактор и музыкальный проигрыватель. Полноценная операционная система, пользовательское окружение и веб-браузер.
Вы скажете, что дисковое пространство сейчас ничего не стоит. Да, но не оперативная память. Новенький блестящий MacBook Pro по умолчанию укомплектован 8 Гб ОЗУ. В связи с продолжительностью работы от батареи вы не можете приобрести модель с более чем 16 Гб. И прямо сейчас Slack находится где-то между 300 Мб и 1 Гб в памяти моего ноутбука:
Come on. Это приложение для обмена текстом.
Другая вещь, которой всегда не хватает — заряд батареи. Современные процессоры сохраняют заряд путём остановки когда это возможно (когда нет никаких задач). Проклятие power management это программы, которые постоянно используют процессор всего на пару процентов. Они заставляют процессор постоянно просыпаться, разгоняться и снова останавливаться. Это идеальный способ уничтожить драгоценный заряд батареи. Если у кого-то есть время (просто оставьте их запущенными) — я бы посмотрел как сильно Spotify, Slack и Atom уменьшают время работы от батареи на современных ноутбуках. Это невероятно.
И нет, Spotify не проигрывает музыку. Он просто… запущен. Делает свои загадочные хромовские дела. И он тоже использует несколько процентов процессора. Просто, чтобы существовать.
(Во время написания этой заметки Chrome в отместку решил занять 100% ресурсов процессора. Во встроенном диспетчере задач это был загадочный процесс «Browser». Спасибо, Chrome.)
Если быть честным, то JavaScript вне браузера не является проблемой. На самом деле я думаю, что API, которые предоставляет современный веб гораздо лучше существующих API операционных систем. Мы должны ими пользоваться.
Но нам необходимо найти возможность использовать эти новые парадигмы (React и его друзья) на настольных платформах без необходимости запускать больше чертовых копий Chrome. Мне просто не настолько интересно ваше приложение, чтобы это оправдывало запуск очередного инстанса Chrome. Разработчику легко попасть в ловушку ощущения того, что ваше приложение или сайт это подарок человечеству и самое важное, чем они могут заниматься. Почему бы не воспользоваться избыточными ресурсами? Нам нужно бороться с таким образом мышления. Такой путь приводит к миру, где у нас не может быть хороших вещей. Такой путь приводит к миру, где батареи наших ноутбуков должны вырасти, чтобы обеспечивать питанием процессоры, чтобы они выполняли ещё больше бесполезной работы. Такой путь приводит к возвращению Shockwave Flash и нагревающихся в карманах телефонов, которые загадочным образом оказываются разряжены когда мы хотим ими воспользоваться. К паранойе по отношению к заряду батареи и закрытию приложений как только мы закончили с ними работать. (Я смотрю на вас, iTunes и Mischief.)
Просто скажите Electron НЕТРазработчики, не позволяйте своим друзьям писать приложения на Electron. Если вы хотите использовать JS и React — воспользуйтесь React Native. Это как Electron, но только у вас нет необходимости распространять копию Chrome всем пользователям и запускать ещё одну копию Chrome чтобы использовать ваше приложение. Оказывается, современные операционные системы уже имеют хорошие и быстрые UI библиотеки. Используйте их, олухи!
Другой печальный факт это то, что даже многие разработчики и понятия не имеют что происходит в их компьютерах. Они пользуются Slack, но не знают насколько он прожорлив. Это твоя ответственность, как разработчика, знать всё это. Практикуйтесь. Изучите средства для профилирования. Воспользуйтесь iStatMeters или одним из бесплатных аналогов. Вы не можете улучшить то, что не измеряете.
Может, мы должны покупать более медленные компьютеры, чтобы почувствовать боль. Facebook намеренно ограничивала скорость интернета в своих офисах раз в неделю, чтобы вызвать сочувствие их пользователям в других странах третьего мира (кхе-Австралия-кхе). Может, как разработчики, мы должны тоже делать это со своими компьютерами, например, заставлять код работать гораздо медленнее, чем обычно, чтобы вооружиться интуицией в отношении производительности. Пару лет назад я оставил свой ноутбук на работе на долгие выходные. Вместо поездки за ним я решил подключить мой Raspberry Pi (чертовски медленное 1 поколение) и использовать его для разработки. Внезапно, множество операций, которые осуществлялись мгновенно на моём обычном ноутбуке с i7 стали ужасно медленными. И я потратил выходные, чтобы сделать свой рабочий процесс более гладким. Все эти твики производительности также переносятся и на обычные устройства. Уменьшение времени запуска с 5ти секунд до 2х на Raspberry Pi ощущалось невероятным прыжком. Это исправление точно так же стало прыжком с 0.5 секунд до 0.2 или вроде того. Это всё равно очень заметно для пользователя. Время запуска в 0.5 секунд достаточно мало, чтобы упустить этот факт при разработке, но падение до 0.2 очевидно ощущается как намного быстрее.
Пользователи: Пожалуйста, жалуйтесь на медленные программы. На дворе 2016 год (… — прим. пер.). Мы носим суперкомпьютеры в наших карманах. Для программ недопустимо быть медлительными.
Разработчики: Производительность имеет значение. Память имеет значение. Мне не важно, что ты самая привлекательная девушка на танцполе, Slack. Я закрываю тебя как только покидаю офис. Я удаляю тебя с компьютера как только имею такую возможность. Медлительность это баг. Самая быстрая программа это та, которую ты не запускаешь. Так что хватит встраивать целый Chrome в своё приложение.
И все вы, веб-разработчики: Выучите С или Rust или что-то в этом духе. Ваши программы выполняются на компьютере. Пока вы не знаете как работает компьютер вы обречены. И убирайтесь с моей лужайки пока не узнаете! *трясёт кулаком*
И да, почитайте про кризис ожирения сайтов (перевод на Habr). Это очень смешно. И очень грустно. И очень жизненно.
Edit: Spotify на самом деле использует Chromium Embedded Framework вместо запуска через Electron. Но он всё равно встраивает Chrome. Я не знал об этом когда писал статью, но не забираю свои слова по поводу конечной производительности.
Комментарии (385)
kaleman
22.10.2018 01:18+315 лет пишу под винду десктопный софт, но JS-приложения для десктопа… Не могу этого понять. Зачем? То есть нафига? Это такой способ поиздеваться над пользователяли? Троллинг? Или это полноя и окончательная победа Идиократии? У меня только непонимание и одни вопросы… Наверное безнадежно я устарел. Могу написать софтинку на VCL под Дельфи, или MFC. На нелюбимом WPF под шарпы. С Qt тоже знаком. Да хоть на голом WinAPI, сделаю вам красивый UI и все будет летать со скоростью блокнота. И даже в сотню кбайт скомпилированного EXE с зависимостями только виндовых библиотек. Но эти кривые и монструозные жс приложения в сотни мегабайт. Так и хочется крикнуть — Господь жги, тут уже нечего спасать…
evnuh
22.10.2018 01:24+2Может быть чтобы была одна кодовая база на все популярные ОС: win, macOS, linux, iOS, Android, web?
Это же выбор между скорость и стоимостью разработки и количеством сжираемых ресурсов железа пользователя. Кто-то готов потратиться и пожалеть юзера, кто-то не готов. Особенно это становится актуально, во времена, когда «Мы носим суперкомпьютеры в наших карманах.» Почему бы не использовать бесплатно эти суперкомпьютеры и платить за разработку только одной программы, а не пяти?
И уж тем более глупо советовать «подите выучите С или Rust, вы, веб-разработчики». Не думаю, что Slack пишут макаки, выбор писать на веб-стеке — это осознанный выбор, а не от того, что «ничего другого не умеем».LexS007
22.10.2018 01:40+4Это просто экономия, в ущерб конечным пользователям.
Разработчики написали одну веб-версию, и вместо того что бы написать нормальный десктопный клиент, обернули вебверсию электроном, Готово.
Для стартапа это нормально, но Slack Technologies уже зрелая компания с огромной базой корпоративных клиентов, пора и о них подумать.
Даже не вижу смысла качать их клиент, просто держу открытую вкладку Slack в браузере.evnuh
22.10.2018 02:21+1Да, это экономия в ущерб конечным пользователям. Я это и сказал. Глупо ожидать от бизнеса, что он не будет снижать затраты, когда он может их снижать. Бизнес — не альтруизм.
Methos
23.10.2018 09:58я бы не сказал что в ущерб
чтобы написать быструю прогу, нужны ресурсы, хорошие ресурсы и время
это намного большие деньги, чем на js
и если например чтобы пользоваться этой прогой вам нужно заплатить 100 баксов в месяц вместо например 10, вы заплатите?
Simplevolk
23.10.2018 10:25На самом деле, в конечном счете, мы заплатим по 100 баксов, так как программа будет отъедать все больше ресурсов на разработку и поддержку. И тариф будет увеличен.
Ну или пользователь будет вынужден заплатить 100 баксов, чтобы купить дополнительную память\процессор\итд.Methos
23.10.2018 19:48просто все те, кто ноют, что памяти мало и скорость мала, пусть вспомнят о том, что в 1995 году были спектрумы с 64 кб памяти
а в 2000 году (18 лет назад) pentium с непомню-уже-сколько памяти (наверное 256 Мб), и windows 98 работала на этом компе, хотя и со скрипом.
а сейчас компы такой же мощности, если не выше, умещаются в задний карман джинсов и можно в браузере запустить виртуальную windows 98 и в автобусе ехать и работать по несколько часов =)
YemSalat
22.10.2018 09:44Вот тоже умa нe приложу — нафига все качают Слаковское приложение (по сути запускают еще один хром)??
Веб версия же всe умеет (кроме шаринга десктопа нa видеозвонках)Neikist
22.10.2018 09:58+1Слаком не пользуюсь, но все же удобнее когда есть разные приложения на панели задач, чем куча вкладок в браузере.
RifleR
22.10.2018 10:31PWA нас всех спасет.
Neikist
22.10.2018 10:42Чем именно? Даже если будет в отдельном окне — все равно та же унылая веб фигня. Ладно дома у меня i7, ссд и 16 гигов ддр4, а на ноуте, который покупался в дополнение к пк на сумму которую не жалко, двухядерный целерон и 3 гига памяти.
ImKremen
22.10.2018 10:58Ну так можно же ярлык добавить.
Neikist
22.10.2018 11:00Эм, ярлык на что? Как будто будет открыто отдельное окно которое не будет стакаться с окном огнелиса, не будет затирать последние открытые вкладки при неправильном порядке закрытия окон и т.д.
unclechu
23.10.2018 03:19В Firefox есть профили, можно параллельно запускать несколько независимых инстансов с разными профилями. Например запуская:
firefox --new-instance -P foo
Где
foo— произвольное имя профиля (если такого профиля ещё нет, откроется окно с управлением профилями).
Каждый профиль имеет свой набор расширений и настроек браузера.
YemSalat
22.10.2018 23:18все же удобнее когда есть разные приложения на панели задач, чем куча вкладок в браузере.
Мне наоборот нравится поменьше открытых программ :)
А вкладки вроде слака/почты и т.п. я обычно делаю «Pin Tab» тогда они занимают меньше горизонтального места и их труднее нечаянно закрыть.
ThunderCat
22.10.2018 14:02Веб версия же всe умеет (кроме шаринга десктопа нa видеозвонках)
вроде и это реализуется через расширение устанавливаемое в браузер.
domix32
22.10.2018 19:37Потому что Маки например не умеют в нормальное переключение окон одного и того же приложения, например. Только «Показать все окна». Довольно неудобно на мой взгляд.
warranty_voider
22.10.2018 11:56+1Это просто экономия, в ущерб конечным пользователям.
на минуточку, Slack это коммерческое приложение. Пользование им стоит денег. Вы готовы платить в 5 раз больше, чтобы получить быстрые и качественные нативные приложения под 5 платформ? Даже сейчас у слака не самая приятная ценовая политика, а за 5х никто им не будет пользоваться вообщеOgra
22.10.2018 12:14Сейчас у Слака 193 открытые вакансии: slack.com/careers#openings Из них разработчиков два-три десятка от силы. Они могут прямо сейчас нанять по десять разработчиков на каждую платформу, из-за этого цена вырастет на 2%, не больше.
fiftin
22.10.2018 19:30Не пойму почему все приводят приложение Slack как пример насколько Electron плох. Скачайте приложение Discord, оно очень крутое, сделано на том же Electron.
khanid
22.10.2018 20:19Не пользовался слаком, но пользовался дискордом. И могу сказать, что, на мой взгляд сисадмина, он тормозит. А ещё лезет по процессам, да и вообще куда не просят.
neit_kas
22.10.2018 20:55+1Ок, VSCode. Функционально — круто. Можно быстро поднять себе удобную IDE под любой ЯП. Поднимал под C++. Я понятия не имею, что, но томозило оно знатно. Пустым (ну, м.б. с 1-3 плагинами) пользоваться ещё можно, но чуть больше и всё.
CheatEx
23.10.2018 11:434790 проц, 16 Гб, эта хрень стартует секунд 15. Телега в которой у меня в 10 раз больше групп и каналов меньше секунды.
Каким раком дискорд попал в крутые приложения?
Gorthauer87
22.10.2018 11:45+1Есть Slack, а есть к примеру Discord, оба на электроне, но просто сравните скорость их работы и отзывчивость интерфейса.
Neikist
22.10.2018 11:51Я пока видел только vs code из таких приложений которым хоть как то пользоваться можно. Дискорд тоже непозволительно много ресурсов сжирал для задач которые выполняет и не сказать что быстро на слабом железе работал.
jashcka
22.10.2018 18:41не можно, не может открыть лежащий рядом файл, долго что-то ищет ( этот же файл ), а потом начинается самое веселое, разваливается на ходу, плагины перестают работать один за другим
neit_kas
22.10.2018 20:59Я пока видел только vs code из таких приложений которым хоть как то пользоваться можно.
Несколько плагинов в него влепи и посмотри на результат.Neikist
22.10.2018 21:15К счастью я вовремя одумался и вернулся к более нормальным IDE (тем более что это не IDE в общем то). А если просто редактор текста нужен то есть vim который и под виндой неплохо работает.
neit_kas
22.10.2018 23:08При допиливании плагинами её вполне можно считать IDE (позиционируется, на сколько знаю, тоже как универсальная IDE): дебаггер есть, подсветка есть, автодополнение есть, что ещё надо?
Ну, судя по всему, под линукс нормальная IDE — это та, которую собрал по сути сам (тот же Emacs). Остальное мне не зашло. Основная фишка, которая мне нравилась в VSCode и которой не было в других IDE — это кастомные команды сборки и запуска. С учётом того, что мне не зашёл ныне популярный CMake, а зашёл Premake — это было очень весомой фичей.encyclopedist
24.10.2018 11:42Основная фишка, которая мне нравилась в VSCode и которой не было в других IDE — это кастомные команды сборки и запуска.
Это ксть в абсолютно всех IDE, которые я видел.
boblenin
22.10.2018 23:08Насколько я помню VSCode на менее чем 8Gb оперативки, даже для маленьких проектов не вариант (в отличии от того же rider который на 4gb на мелких проектах вполне выживает), т.к. когда вышло — пробовал. Может быть сейчас уже не так.
Самое неприятное, что все эти приложения на электроне из всех сил пытаются выглядеть как будто они легковесные, а по факту — очень тяжелые решения. Ну это как если взять Ford Granada Station Vagon 1982, прикрутить спойлер, покрасить красным тормозные колодки, раскрасить кузов яркими красками и налепить стикеры а-ля ралли. Нелепо.
PsyHaSTe
22.10.2018 14:54Отвратительно у обоих — имхо.
Люди начинают забывать, как должно работать приложение. Посмотрите на тот же телеграм, просто сравните время запуска, время синхронизации, потребляемую память… Но нет, зато мы во время длиннющей загрузки занимающей чуть ли не десяток секунд мы показываем смешные фразочки. Дешевый способ купить внимание пользователя, пока вся эта машинерия разворачивается.technic93
22.10.2018 17:21Да телеграм напомнил мне о старых временах, когда всё работало быстро, как в старом скайпе.
progman_rus
22.10.2018 19:51Так телеграмм Программисты писали, а не «программисты»
MikailBag
22.10.2018 20:03ТГ на c++ + qt написан. Чтобы программа на плюсах тормозила, надо очень сильно постараться)
bodqhrohro
22.10.2018 20:04Telegram теперь тоже запускается минут 10, спасибо ломающим изменениям в Fontconfig 2.13 и ихним кастомным костылями ради отображения своих эмодзи — читает мимо кэша весь /etc/fonts. И оперативку жрёт будь здоров: если в чатах с кучей картиночек и стикеров обитать, почти до гигабайта подтекает за пару дней.
ValdikSS
23.10.2018 21:48FONTCONFIG_FILE=/etc/fonts/ telegrambodqhrohro
24.10.2018 01:10Я с этой переменной и запускал, как только поломалось — без неё окно вообще не появлялось, и вроде даже процесс в итоге крашился, точно не помню. Причём с ней тоже стартовало долго, и большая часть диапазонов Юникода отваливалась, а в файловом диалоге вообще все символы квадратиками были, даже ASCII — выбирал вслепую или копипастил из автодополнения баша. Через несколько недель случайно запустил без переменной и обнаружил, что уже и так работает, причём лучше.
farcaller
22.10.2018 15:39Discord от релиза к релизу иногда течет просто ужасно:
OnelaW
22.10.2018 16:22+2Ой, выколете мне глаза, веб-общалка на 1 гиг? Что она такое делает что не могут другие? Нее, это безумие нужно остановить.
krab90
23.10.2018 15:04
Если открыть чаты и покликать по разным каналам то поднимается и держится в пределах 130-140 МБ (зависит от количества GIF). После закрытия окна через 5 секунд потребление 94-95 под вантузом. Всего скорее сабж на скриншоте выше под macOS течет по памяти сильно. Ну оно и очевидно это же JS/Electron.
homocomputeris
22.10.2018 19:10Ну, VLC и LibreOffice как-то же на разных платформах существуют.
staticlab
22.10.2018 19:14У LibreOffice свой графический тулкит для этого.
Goodkat
22.10.2018 19:53А LibreOffice не на джаве написан? Он такой тормозной в сравнении с MS Office, что я на джаву грешил.
staticlab
22.10.2018 23:07Он на C++, как ни странно.
boblenin
22.10.2018 23:15Странно. Википедия en.wikipedia.org/wiki/OpenOffice.org#Use_of_Java с вами не вполне согласна. И даже поминает дедушку Столлмана в этой связи.
staticlab
22.10.2018 23:31https://github.com/LibreOffice/core — 88% C++, 6% Java. Ну и [https://habr.com/company/pvs-studio/blog/426977/](PVS Studio) дважды тестировали.
turbanoff
23.10.2018 00:15+1Статья про OpenOffice, а не LibreOffice. Уже давно выпилили Java из поставки.
khim
23.10.2018 00:32+2Там есть много ньюансов:
1. В OpenOffice.org Sun долго пытался напихать кучу Java в разнае места.
2. После того, как LibreOffice отпочковался — они её выкорчевали и интерфейс стал быстрее.
3. Главное: с тех пор вышло много новых версий MS Office — и они стали сильно тормознее.
Так что про стереотип «тормозной LibreOffice» стоит забыть: он и в самый момент появления (то есть отпочковывания от OpenOffice.org) не был особо тормозным, а сейчас — так и вообще «летает». В основном за счёт пункта номер 3, правда…
progman_rus
22.10.2018 19:49по большому счету С++ это уже кодовая база на win, macOS, linux, iOS, Android.
в 99 из 100 достаточно API вызовы для каждой из платформ в обертки завернуть не затрагивая основной код.neit_kas
22.10.2018 21:03+3Чистый C++ и UI — это боль. Но Qt сильно спасает.
boblenin
22.10.2018 23:20+1Я попробовал вспомнить варианты где бы был чистый C++ и UI. Везде либо просто C, либо какие-то препроцессоры, либо другие виды C — не C++. Разве что WTL, который и правда удовольствием не назовешь. А вы что имели в виду?
neit_kas
23.10.2018 18:02По чистым C++ с UI — я понимаю использование наиболее нативных вариантов. С Windows всё ясно: WinAPI. Под Linux не так однозначно. Наиболее нативным думаю там является XLib. И вот без какой-то монструозной штуки слабо представляю, как это можно обернуть чем-то, сделав кроссплатформенным (как описал комментатор выше).
AEP
22.10.2018 01:51Оффтоп:
Примерно 15 лет назад читал книжки, как писать софт под Windows. Про все эти оконные процедуры, windows-сообщения, объекты ядра, и еще упоминается MFC как красивая обертка над этим делом. Потом пересел на Linux и от этого дела отстал, но чувствую, что знания надо освежить. Но вот сейчас не могу найти современных книг по Windows-разработке, которые именно про нативные приложения, и которые начинают с азов. Не посоветуете ли чего толкового?quwy
22.10.2018 01:56+1Так ничего не поменялось. WinAPI стабилен как пирамида Хеопса и это очень правильно. Сгодится даже учебник времен Windows 95.
Grief
22.10.2018 04:48А как же .NET? Выше его сравнили с Electron, но (сугубо имхо) — это реально крутая вещь, особенно учитывая то, что под linux есть mono. Я сам давно не писал под винду, но когда заканчивал, вроде был курс на уход от winapi в сторону .net для всего пользовательского софта, для которого это возможно.
ideatum
22.10.2018 08:56Уже более 2-х лет существует .Net Core, работающий под Linix, MacOS и Windows.
.net core sdk
для любителей собрать самостоятельноSimplevolk
22.10.2018 09:46А в версии 3.0 обещают завезти WPF. Но, думаю, только под виндой. Есть еще проект Авалония — кроссплатформенная WPF.
Liminiens
22.10.2018 17:02
Flaksirus
22.10.2018 14:12+1Кор это круто, но тут речь про десктоп — в коре нет и пока не будет UI при поддержки Microsoft. WPF в core — это скорее убийство FullFramework с переездом самого нужного в кор. Как выше заметили есть AvaloniaUI, что отлично подойдет для пет проджекта, но я бы поостерегся писать на ней что то для бизнеса.
jacob1237
22.10.2018 02:05+2К сожалению программистов такая вещь как Electron пользуется спросом у бизнеса именно по причине оптимизации денежных трат. Сегодня количество веб разработчиков в разы превышает количество других прикладных программистов. Писать софт на JavaScript попросту быстрее и дешевле, чем использовать специализированные технологии.
Electron действительно сжирает всю память и процессорное время. Однако это дает возможность бизнесу быстро вводить в строй новые продукты.
И это единственная причина. Electron как технология ужасен. Но технологии не стоят на месте и в будущем все-таки есть надежда на более выигрышную по производительности технологию.
Закон перехода количественного в качественное никто не отменял :)
Fesor
22.10.2018 02:29+1Закон перехода количественного в качественное никто не отменял :)
напомните мне примеры выполнения этого закона.
jacob1237
22.10.2018 03:10-2Пример: язык Go. Раньше все писали сетевые сервисы на чем попало, то есть Python, Perl, Node.js, C++ и т.д. Сегодня для этого берут Go. Компилируемый язык со встроенной кооперативной (а также вытесняющей) многозадачностью.
Посмотрите на проект Сentrifugo: https://github.com/centrifugal/centrifugo
Раньше был написан на Python (Tornado), теперь на Go. В итоге производительность увеличилась на порядки, а потребление памяти снизилось, не сильно при этом потеряв в простоте поддержки кода.Fesor
22.10.2018 03:31+1Простите, но где тут количество и о каком качестве идет речь?
Если говорить о количестве и качестве — посмотрите на увеличение количества разработчиков на Go. А теперь проанализируйте тренд уровня этих разработчиков.
То что у нас появился компилируемый эрланг (да, я сейчас ооооочень сильно утрировал, без децентрализации это все не сильно нужно) это замечательно, однако качественного скачка я не вижу. Люди как и раньше писали на Java/Perl/Python/Node/C++ так и продолжают писать. Просто теперь есть еще Go и Rust. А еще есть D, Elexir, Kotlin и многие другие штуки. Но что-то как-то люди продолжают писать микросервисы на php.
p.s. центрифугу юзаю, и рад что кто-то ее написал. Но будь она написана на эрланге, хаскеле или ocaml — мое отношение к ней не сильно бы отличалось.
jacob1237
22.10.2018 03:45-2Качественный скачок — новый специализированный язык, поддерживающий многозадачность из коробки.
Сетевые сервисы сейчас проще и быстрее писать на Go, не теряя в производительности и потреблении памяти.
Написать сетевое приложение на Go значительно проще чем на C++. Касательно Java/Python и т.д. — все это языки, в которых для исполнения кода используется дополнительная абстракция (виртуальная машина/интерпретатор), так что по эффективности они априори проигрывают.
По поводу D могу сказать что там не все так однозначно. Есть фреймворк vibe.d, но он из коробки не даст той же производительности как и Go. В vibe.d тоже используется кооперативная многозадачность, но там нет встроенного пула потоков, по которому раскидываются задачи (технически это возможно, но программисту все еще нужно понимать что происходит "под капотом").
По поводу микросервисов могу сказать что эта архитектура скорее попытка адаптации к рынку труда, чем к решению технологических задач. Микросервисы можно писать на чем угодно, и этот факт позволяет компаниям охватывать при найме гораздо большую часть рынка, чем просто "PHP Developer" или "Erlang Developer" (и т.д.).
Rust же совсем не про сетевые сервисы. Это С на стероидах. В будущем приложения, которые раньше писали на C, будут писать на Rust, т.к. этот язык конкурирует именно с C и его производными.
Так что Go на мой взгляд именно что качественный скачок применительно к написанию сетевых сервисов. А на Ваш взгляд?
Szer
22.10.2018 08:38Качественный скачок — новый специализированный язык, поддерживающий многозадачность из коробки.
Поддерживающий только ОДНУ парадигму многозадачности (корутины) из коробки, и оберачивающий весь синтаксис на фоне в монадку Async, чтобы блокирующие вызовы байндились на континуейшн как будто это императивный код.
Любой нормальный язык даст вам на выбор другие парадигмы многозадачности: треды, корутины, фиберы. Монадки конечно же любые на выбор (без дженериков в Го их не сделать, поэтому захардкожена одна), на выбор вытесняющие или кооперативные юзер-спейс планировщики.
Это всё из Го убрали чтобы среднему гоферу не надо было мучаться проблемами выбора.
Fesor
22.10.2018 14:10+3Написать сетевое приложение на Go значительно проще чем на C++
Согласен. Написать его эффективно — не сильно проще чем на C++. Просто язык дает меньше возможностей по стрельбе по ногам.
так что по эффективности они априори проигрывают.
Напомню что в го рантайм тоже не бесплатный. GC, распределение корутин, все это довольно жиное и в целом приводит к тому что грамотно написанное приложение на Java будет примерно так же эффективно работать. Другой момент что с Go будет проще. Однако тот же rust уделает их всех, хотя посадить студента на раст будет проблематичнее да.
Это С на стероидах.
Тогда Go это С на седативах.
А на Ваш взгляд?
На мой взгляд Go, это ответ на проблему низкой квалификации разработчиков. Урезанный по самое немогу язык (не считаю что это плохо, если что), который максимально защищает человека от вопросов применения воображения. Все делается примитивно и в лоб. Идеально для массовой разработки.
Является ли это качественным скачком? Нет. С точки зрения качества разница не велика. Опять же — основная проблема го — хайп, в свете которого все кому не лень начали на нем писать. И с каждым годом квалифицированность среднего разработчика на Го вызывает вопросы. Сейчас идет процесс усложнения языка, что в купе с наплывом слабых разработчиков скорее всего отбросит его успех назад.
Если же для вас Го это качественный скачек — задумайтесь. Это скачек для вас или для индустрии в целом?
jacob1237
22.10.2018 19:34Создается ощущение, что Вы нарочно опускаете контекст дискуссии. Ключевое слово "сетевые сервисы" почему-то осталось незамеченным Вами и остальными комментаторами этой ветки.
Как и обычно бывает в рунете (и на Хабре в частности) — сначала закидывают шапками, а потом разбираются.
Я говорил не про сам язык программирования Go, а лишь привел его в пример в качестве иллюстрации закона перехода количественного в качественное (по Вашей же просьбе). Контекстом этого перехода является именно предметная область написания сетевых сервисов (network applications), а не проблемы отрасли, парадигмы программирования или вселенской справедливости.
Причем под количеством и качеством я понимал термины из философии (Диалектика Гегеля / Диалектический Материализм), а не количество как число (уж тем более число разработчиков) и качество как качество ПО.
Сам пример перехода я подрузамевал так:
- Появляется проблема написания сетевых сервисов и приложений;
- Появляются разрозненные решения: зачастую библиотеки/фреймворки к существующим языкам для работы над проблемой;
- Возрастает сложность проблемы, возрастает нагрузка на приложения;
- Постепенно продолжают происходить количественные изменения: предлагаются новые варианты решения — multi-threading (Java, Apache HTTP server, etc.), fork (CGI, FastCGI, *CGI), async concurrency (libevent, libev, libuv, etc. и основанные на них решения — NGINX, NodeJS и т.д.)
- Происходит качественный скачок — появление и позиционирование языка Go для решения этих проблем. Язык заточен исключительно под предметную область: объединяет модель multi-threading и async concurrency — программа запускается в несколько потоков, которые в свою очередь обрабатывают очередь задач (goroutines), позволяя еще более эффективно использовать процессорные ядра.
Стандартная библиотека позволяет написать мощный и быстрый HTTP сервер в пару строк кода за несколько десятков минут. На решение подобной задачи с точно такой же эффективностью в других языках уйдет просто уйма времени (особенно в C++).
Если Вы не согласны с такой интерпретацией, то подробнее о примерах действия закона можете прочитать в вики.
За сим позвольте откланяться. Считаю данную дискуссию исчерпанной и вышедшей за рамки данной статьи.
Szer
22.10.2018 23:37+2Смешались в кучу кони, люди.
Происходит качественный скачок — появление и позиционирование языка Go для решения этих проблем. Язык заточен исключительно под предметную область: объединяет модель multi-threading и async concurrency — программа запускается в несколько потоков, которые в свою очередь обрабатывают очередь задач (goroutines)
Я понимаю что гоферам застилает глаза божественность Пайка, но неплохо мы обзнакомиться с теорией.
Языки, в которых в самом синтаксисе была селективная асинхронность с синхронным общением между легковесными тредами и корутинами:
- Concurrent ML + Parallel CML
- Racket
Не говоря уж у тонне либ для языков:
- Haskell — дофига. Control.Concurrent.CML хотя бы! Control.Concurrent.CHS туда же.
- F# — Hopac
- Clojure — core.async
Не поверите, везде одно и то же — собственный шедулер в юзер спейсе, n:m модель, легковесная абстракция над ОС тредами, синхронное общение (ченелы), селективная асинхронность.
Что нового привнёс Go? Убрал с гоферов необходимость учить Haskell, F# или кложу. Про CML я просто молчу, старый язык уж очень, хотя он до сих пор где-то в продакшне телекома юзается по слухам.
jacob1237
23.10.2018 01:48-1Смешались в кучу кони, люди.
Сочувствую. Но не переживайте, все у Вас наладится, я в это верю, правда.
Я понимаю что гоферам застилает глаза божественность Пайка, но неплохо мы обзнакомиться с теорией.
Полностью согласен! Осталось только предложить это самим гоферам, а не писать это под моими комментариями. =)
Что нового привнёс Go?
Go популярен, поэтому я упомянул именно его, для того чтобы говорить с людьми на одном языке, принимая во внимание то что я не знаком с Fesor лично и не знаю его бэкграунда. Это считается нормальным в диалоге — переходить от общего к частному.
А вот то что у Вас от этого бомбануло (наверное), не сказать чтобы прямо моя вина. Тем более что дискутировал изначально я не с Вами =)
Языки, в которых в самом синтаксисе была селективная асинхронность с синхронным общением между легковесными тредами и корутинами:
СSP модель в Go не является чем-то новым и захватывающим, но вот то что язык специализировали под определенные задачи, сделали при этом его компилируемым в машинный код, приспособили под современный рынок труда а затем правильно отпозиционировали — вот это как раз является.
Я не вижу смысла продолжать дискуссию, потому что мы с Вами, судя по-всему, говорим несколько о разных вещах.
Но раз уж Вы решили вступить в ряды диванного спецназа (ведь в интернете опять кто-то неправ), то ответьте, какие из перечисленных Вами языков кроме Haskell компилируются в машинный код и почему все они достаточно маргинальны по сравнению с Go?
Szer
23.10.2018 07:38+1Я не вижу смысла продолжать дискуссию… ответьте, какие из перечисленных Вами языков кроме Haskell компилируются в машинный код и почему все они достаточно маргинальны по сравнению с Go?
Противоречивые параграфы вижу я, но ладно :)
GHC у Хаскеля умеет компилировать как в натив, так и под LLVM
FSC в F# умеет компилировать только под CLR, но есть такая штука как .NET Native, которая сразу полученный код для CLR гонит в натив. Не пользовался за ненадобностью.
В JVM тоже есть способ гнать байткод в натив — Excelsior например.
Не буду скрывать, нативный бинарник Go получится крайне маленьким по размеру по сравнению с любым из вышеперечисленных, но это из-за скудности стандартной либы Go (и это слабо сказано), а не потому что там какие-то ядерные оптимизации происходят.
По поводу маргинальности — PHP и Питон тоже популярнее Haskell, F# и Clojure. Да и вообще всех ФП языков. Возможно даже вместе взятых.
Делает ли это Haskell, F# или Clojure плохими языками? Для тех кто не осилил их освоить — несомненно.
jacob1237
23.10.2018 12:52GHC у Хаскеля умеет компилировать как в натив, так и под LLVM
FSC в F# умеет компилировать только под CLR, но есть такая штука как .NET Native, которая сразу полученный код для CLR гонит в натив. Не пользовался за ненадобностью.
В JVM тоже есть способ гнать байткод в натив — Excelsior например.Ну конечно есть способы. Даже в некоторых скриптовых языках есть возможность компиляции в нативный код. Вот только это не отменяет того факта что частотность использования этих решений на продакшне гораздо ниже. И не все из них production-ready. Тем временем Go уже давно production-ready и предоставляет компиляцию (причем достаточно быструю) в нативный код из коробки =)
Не буду скрывать, нативный бинарник Go получится крайне маленьким по размеру по сравнению с любым из вышеперечисленных, но это из-за скудности стандартной либы Go (и это слабо сказано), а не потому что там какие-то ядерные оптимизации происходят.
Вы сравниваете Haskell и Go, как будто это два конкурирующих между собой языка. По-моему вполне очевидно и ожидаемо что у специализированного языка стандартная библиотека может быть меньше чем у более общего.
Причем посыл Вашего абзаца мне видится таким: "да признаю (черт возьми!) что Go тут перещеголял другие языки. Но… но… но это все от того что он хуже!" =D
Все мы знаем что "Любая достаточно сложная программа на <язык_программирования> содержит заново написанную, неспецифицированную, глючную и медленную реализацию половины языка Common Lisp" ®
Но большие и примечательные production сетапы на Lisp (как и на Haskell) в мире можно пересчитать по пальцам.
Потому что обслуживать, скажем, торговые сети или интернет магазины дешевле и целесообразнее при помощи вчерашних студентов или переквалифицировавшихся профессионалов, чем при помощи PhD и профессоров из вузов Ivy League. Ибо масштаб проблемы слегка не тот.
И в этом Go прекрасно решает свою задачу, ведь написание сетевых сервисов и всяких HTTP серверов — это не научная проблема, а самая что ни на есть прикладная.
По поводу маргинальности — PHP и Питон тоже популярнее Haskell, F# и Clojure. Да и вообще всех ФП языков. Возможно даже вместе взятых.
Делает ли это Haskell, F# или Clojure плохими языками? Для тех кто не осилил их освоить — несомненно.Изначальный вопрос был:
почему все они достаточно маргинальны по сравнению с Go?
Но Вы, получается, ушли от ответа, так что тут раунд!
И вообще, кому нужен Clojure, когда есть Common Lisp? =)
PsyHaSTe
23.10.2018 12:58Вам бы тендеры устраивать. Вы берете список особенностей, под которые попадает только Go, говорите, что это самые важные качества в ЯП, и побеждает… Go. Какая внезапность.
Не вижу смысла спорить «какой язык более гошный, чем го». Предлагаю воспользоваться каким-либо честным методом сравнения, например методом идеальной точки. Выделить важные качества языка (с формальной точки зрения можно воспользоваться дисперсионным анализом, чтобы не ругаться, какое качество действительно важное), проставить им экспертные оценки, и сделать соответствующий вывод.jacob1237
23.10.2018 13:21Вам бы тендеры устраивать
А Вам бы с таким аватаром только в дискуссиях про ЯП участвовать =)
Не вижу смысла спорить «какой язык более гошный, чем го»
Что значит более "гошный"? Когда Go появился, сначала его позиционировали как конкурента и замену языку C, но не найдя на этом поприще признания, его просто специализировали под написание сетевых приложений. И в этом ключе он уже обрел популярность.
Создается впечатление что Вы упорно не хотите видеть какую проблему он решает и уводите все в плоскость сравнения языков по их возможностям.
Можете объяснить зачем среднестатистическому HTTP серверу (к примеру) аппликативные функторы, монады и монадные трансформеры (в общем их виде)?
Вот перепишем Nginx на Haskell, вот тогда уж точно заживем!
PsyHaSTe
23.10.2018 13:25+1А Вам бы с таким аватаром только в дискуссиях про ЯП участвовать =)
Еще и гадать по аватарке будете, неплохо )
Создается впечатление что Вы упорно не хотите видеть какую проблему он решает и уводите все в плоскость сравнения языков по их возможностям.
Можете объяснить зачем среднестатистическому HTTP серверу (к примеру) аппликативные функторы, монады и монадные трансформеры (в общем их виде)?Затем же, зачем и в любой другой программе — чтобы описать пайплайн обработки запроса в удобном виде. А может и не нужны, это ведь просто инструмент. Во-первых есть много промежуточных сценариев, а во-вторых вопрос аналогичен "зачем среднестатистическому HTTP серверу нужны
continueиbreak".jacob1237
23.10.2018 13:36Зачем среднестатистическому HTTP серверу нужны continue и break
Ну, наверное затем, чтобы, как минимум, можно было более удобно построить конечный автомат для парсинга HTTP запроса, нет?
Хотя да, что уж там, с монадами-то процесс парсинга значительно ускорится и потребит меньше памяти! Это ж как можно будет распараллелить процесс, если парсить заголовки и тело запроса отдельными pure функциями, завернутыми в монаду. Ого-го!
0xd34df00d
23.10.2018 16:35Не понимаю ваших ужимок. attoparsec'ом (а он монадический) парсить одно удовольствие. В плюсах всем дерет задницу почему-то boost.spirit, который тоже, по большому счёту, монадический (особенно x3).
Ну и если вы пишете ваш парсер на аппликативных функторах, а не на монадах, то это сразу, автоматически (а, главное, статически) значит, что парсер не может принимать решения на основе уже распаршенных значений, что позволяет генерировать более эффективный код.
Ну, это к вашему вопросу о том, зачем знать разницу между монадой и аппликативным функтором.
jacob1237
23.10.2018 16:49Не понимаю ваших ужимок
Давайте я Вам объясню:
Я не пишу на Go. Для моих задач он не имеет достаточной выразительности и удобства. Я упомянул Go в качестве ответа на вопрос Fesor.
Посыл мой заключался в том, что сегодня все пишут GUI на Electron, а завтра есть вероятность появления какой-либо более оптимизированной по памяти и скорости технологии, согласно закону перехода количественного в качественное.
Я упомянул Go специально, т.к. это всем понятный пример, который на слуху у большинства, в отличие от более маргинальных здесь приведенных языков (F#, Racket, CML и т.д.), и упомянул его в совершенно конкретном контексте — сетевых приложений.
Вместо того чтобы прочитать мои сообщения внимательно, люди, заметив упоминание Go, решили наброситься на меня и начать выяснять чем Go лучше или хуже других технологий (еще и попутно выставляя меня фанатиком Go).
Скажите, Вы тоже не видите изначального посыла моих комментариев?
0xd34df00d
23.10.2018 16:54Тогда тем более не понимаю, причём тут монады и прочие профункторы и написание парсеров на них.
Говоря об изначальном посыле — на мой взгляд (и, вероятно, на взгляд прочих ваших оппонентов, особенно апеллирующих к тому, что это уже давно было в
Симпсонахдругих языках), в случае Go как раз видно количественный рывок, а не качественный.
jacob1237
23.10.2018 16:54Ну, это к вашему вопросу о том, зачем знать разницу между монадой и аппликативным функтором.
Вы видимо тоже не хотите читать мои комментарии. Скажите, где именно я задавал вопрос о том "зачем знать разницу между монадой и аппликативным функтором"?
0xd34df00d
23.10.2018 16:55Этот комментарий подразумевает, что автору сервера имеет смысл об этих вещах знать (ну или не знать).
0xd34df00d
23.10.2018 16:33Можете объяснить зачем среднестатистическому HTTP серверу (к примеру) аппликативные функторы, монады и монадные трансформеры (в общем их виде)?
Чтобы управлять эффектами и гарантировать на уровне типов, что вы не полезете в
/etc/shadow, не пустите неавторизованного пользователя куда не надо, не проинтерпретируете число как строку или наоборот и так далее.
Посмотрите servant.
Вот перепишем Nginx на Haskell, вот тогда уж точно заживем!
nginx не надо, а вот какой-то гошный бенчмарк я ради интереса пару лет назад на хаскеле переделал (тут ещё на хабре разные люди на свои любимые языки пытались его переписать), и работало оно быстрее.
0xd34df00d
23.10.2018 16:30Потому что обслуживать, скажем, торговые сети или интернет магазины дешевле и целесообразнее при помощи вчерашних студентов или переквалифицировавшихся профессионалов, чем при помощи PhD и профессоров из вузов Ivy League. Ибо масштаб проблемы слегка не тот.
А зачем для магазинов всякая хардкорная конкурентность и всё такое? Да и для торговых сетей, судя по тому, что там тоже студенты полезнее, тоже.
jacob1237
23.10.2018 16:41Думаю это вопрос не ко мне. Лучше об этом спросить у Ozon: https://vc.ru/ozon/45542-go или у Zalando, или у остальных пользователей.
В основном они применяют Go для инфраструктурных моментов (насколько мне известно).
Также есть всякие рекламные биржи и т.д.
Alexey2005
23.10.2018 20:03Кодеры СДЭК (одной из крупнейших курьерских компаний в России) видимо тоже так думали. А потом случилось страшное: после апгрейда внезапно выяснилось, что система немасштабируема.
На тестовых серверах всё ОК, а вот реальные нагрузки мгновенно кладут систему на обе лопатки, причём даже добавление серверных мощностей не позволяет справиться с проблемой.
Всё упало 26 сентября, прошёл уже почти месяц, всё это время программисты пафосно превозмогают проблему, но безуспешно. Завязанные на них интернет-магазины терпят убытки, франчайзи разоряются, техподдержка убита напрочь наплывом разгневанных пользователей.
А система лежит. И если продолжит лежать ещё недельки три, то есть неплохой шанс увидеть банкротство крупной курьерской компании исключительно по вине IT.0xd34df00d
23.10.2018 20:17+2То есть, если эту систему бы пилили и обслуживали студенты, но на Go, то она магически бы заработала?
Ну ок, магический язык, действительно. Надо переходить.jacob1237
24.10.2018 13:50Думаю что ответ на Ваш комментарий был связан с вопросом: "А зачем для магазинов всякая хардкорная конкурентность и всё такое?".
Про Go упоминаний не было. Но Вы опять про Go и про студентов, хотя я, например, использовал сочетание "вчерашних студентов", что подразумевает то что человек все-таки закончил обучение в ВУЗе.
И такое происходит на протяжении всей ветки со всеми комментаторами.
"Чукча не читатель, чукча писатель!" ©
Очень жаль что русскоязычное комьюнити сильно уступает в адекватности цивилизованным странам.
Szer
24.10.2018 14:33Очень жаль что русскоязычное комьюнити сильно уступает в адекватности цивилизованным странам.
Очень здорово что вы всё русскоязычное комьюнити назвали нецивилизованным на основании одного спора в интернете.
jacob1237
24.10.2018 15:01здорово что вы всё русскоязычное комьюнити назвали нецивилизованным
Ну вот видите как оно получается. Я же написал что русскоязычное комьюнити уступает в адекватности, а не то что оно нецивилизованно.
Говорю же, "Чукча не читатель, чукча писатель".
И уж точно не Вам на это мое высказывание обижаться, тем более что Вы тут совсем недавно пытались выставить меня фанатиком Go, говоря что "гоферам застилает глаза божественность Пайка, но неплохо бы ознакомиться с теорией." и позволяя себе прочие фривольности (при весьма забавном обстоятельстве, что я на Go НЕ пишу).
Так что давайте закроем тему. Здесь больше нечего обсуждать.
PsyHaSTe
23.10.2018 12:55+1Да тут проще можно сказать — PHP популярнее самого Go. Значит ли это, что PHP лучше?
mkshma
22.10.2018 17:32+1Сегодня для этого берут Go.
Разве что смузи стартапы. Ему еще версий 5 развиваться до момента, когда им можно будет безболезненно пользоваться.Fesor
22.10.2018 19:04А какие у вас критерии для безболезненного использования?
mkshma
22.10.2018 19:39Нет нормальной обработки ошибок, нет шаблонов, нет перегрузки функций и операторов, зависимость от единого настроенного воркспейса (бить палками того, кто подумал однажды, что GOROOT — хорошая идея). Еще кто-то подумал, что это отличная идея — добавить в язык указатели и отобрать возможность проводить над ними арифметические операции. Зачем-то сделали неявную реализацию интерфейсов. Это так, по верхам прошлись. Знаете что из всего этого собираются решить во второй версии? Шаблоны. А обработку ошибок умудрились сделать еще хуже. Хотя в идеале ошибки должны стать языковой конструкцией, а не возвращаемым параметром. А совсем в идеале добавить кейворд, заставляющий в любом случае ошибку эту обрабатывать, иначе кидать compile error. Но Go-коммьюнити настолько консервативное, что году к 25 мы может половину из этого и увидим. В лучшем случае. Правда решение всех этих проблем приведет нас к ситуации с питоном и его версионированием — к такому сектантское коммьюнити Go просто не готово. Так что я бы просто закопал этот язык сразу, а не ждал, пока не окажется слишком поздно для лечения отстреленной ноги.
boblenin
22.10.2018 23:37> Нет нормальной обработки ошибок
Такая же или чуть-чуть получше чем в ANSI C. Какую бы вы хотели? Надеюсь не исключения, которые в том же C++ весьма не редко отключают?
> нет шаблонов
Так же как их нет во множестве языков, например в Java
> нет перегрузки функций и операторов
Зато они есть в C++
> зависимость от единого настроенного воркспейса
Зато все единообразно и чинно-благородно. Разве не к этому пытается куча фреймворков на JS, Python прийти?
> бить палками того, кто подумал однажды, что GOROOT — хорошая идея
GOPATH уже почти победили, GOROOT кстати очень похож на JAVA_HOME
> Зачем-то сделали неявную реализацию интерфейсов.
Затем, чтобы не делать в очередной раз явную. Сначала работающий код, а потом его можно поструктурировать, если он еще остался нужным.
> А совсем в идеале добавить кейворд, заставляющий в любом случае
> ошибку эту обрабатывать, иначе кидать compile error.
Вы какой-то rust хотите сделать из Go. Тут придется от смузи отказаться и пересесть на Bulleit. Если обращали внимание. На множестве языков, где есть opt out обработка ошибок — разработчики этот самый opt out и делают автоматом, первым делом.
> Правда решение всех этих проблем приведет нас к ситуации с питоном и
> его версионированием — к такому сектантское коммьюнити Go просто не
> готово.
Так ведь уже есть множество языков, где все что вы хотите — сделано. А вот языка, который практически не нужно учить — больше нет. Зачем нужен еще один JS/C#/C++/Java?0xd34df00d
23.10.2018 00:11Какую бы вы хотели? Надеюсь не исключения, которые в том же C++ весьма не редко отключают?
Монадическую + изредка экзепшоны.
Так же как их нет во множестве языков, например в Java
В джаве есть дженерики, да и вообще джава — не образец с точки зрения их реализации.
Зато они есть в C++
И это типа плохо для C++ или хорошо для Go?
Fesor
23.10.2018 03:00В джаве есть дженерики
ну дженерики и метапрограммирование на темплейтах это все же разные немного вещи.
0xd34df00d
23.10.2018 03:18+1Между «никаких средств реализации параметрического полиморфизма» и «ещё один тьюринг-полный язык в языке» есть достойные позиции, и дженерики в стиле Java (а лучше — без стирания типов, в стиле C#) там вполне себе находят себе место. Говорю как любитель обмазаться темплейтами.
PsyHaSTe
23.10.2018 13:07Темплейты как по мне довольно злые. Бытие определяет сознание, и то, что на плюсах можно делать крутые штуки через темплейты не означает, что это лучший способ метапрограммирования. Для примера гляньте тот же const genetics в Rust — много интересных вещей можно сделать на генериках, и которые будут работать для любого типа T, а не то, что мы код написали, про который в лучшем случае можно сказать «в тех случаях, где мы этот шаблон инстанцируем, код компилируется и корректно отрабатывает».
0xd34df00d
23.10.2018 16:39Далеко не лучший, конечно.
Дженерики в другом смысле куда лучше, если вам нужно просто анализировать структуры данных и, скажем, генерировать код для сериализации, либо полноценный доступ к AST, да, как Template Haskell.
boblenin
23.10.2018 19:20Это типа зачем из Go делать C++, если уже есть C++? В этом и проблема с C#, Java, C++, JS — что они все более и более похожие, типа Pepsi vs Coca Cola. Странно было бы в упрек Lisp ставить то, что он не похож на Basic или SQL то, что он не похож на Mathematica? Один язык для решения общих задач, множество специализированных для решения узких задач.
0xd34df00d
23.10.2018 20:07Я из всех перечисленных языков более-менее знаю только C++, и на мой такой ограниченный взгляд они все совершенно не становятся всё более и более похожими.
boblenin
23.10.2018 20:56Честно говоря я затрудняюсь понять, что вы хотели сказать. Вы не знаете другие языки или вы сомневаетесь в уровне своей квалификации для того, чтобы обсуждать эти языки? И возразить на ваше утверждение о том, что языки не становятся более похожими я могу только приведя самые примитивные примеры из того что внедряли в каждый из них не так давно
C#, C++ — var, auto
C#, C++, JAVA, Typescript — lambda expressions
C#, JAVA, Typescript — generics
C#, JAVA, Typescript — Exceptions try/catch/finally
…
переодинчески возникает ощущение дежавю просматривая ченджлог то одного языка, то другого. Кстати недавно было видео от создателя PHP на эту тему.
У нас был perl для работы с текстом, был javascript для работы с dom из html, был C++ для прикладного софта и Java/Delphi/C# для энтерпрайза и фронтэнда. Вместо того, чтобы развивать javascript в сторону наиболее комфортной работы с dom/css/html — мы получили язык уровня Java который ничем не лучше Java для работы с dom/css/html.Politura
23.10.2018 21:13из того что внедряли в каждый из них не так давно
Какое-то расплывчатое у вас понятие «не так давно» :)
Эксепшены в C# от рождения, генерики, со второй версии, где-то начало нулевых годов, var по-моему тоже где-то в то-же время появился, ну может лямбды не так давно, но кажется еще до рождения Typescript языка.
PsyHaSTe
23.10.2018 22:31Для любой пары языков можно найти даже больше похожих вещей, чем ваш перечень.
- в js тоже есть var, как и в куче других языков. Ладно, предположим вы имели ввиду только вывод типов, но он есть в куче других языков. Стал ли C# похож на Haskell?
- В питоне тоже есть лямбды, питон похож на C#/C++/Java?
- В хачкеле есть генерики, в расте есть генерики, даже в го теперь есть генерики. Похож ли C#/Typescript на Go?
- Эксепшны есть в повершелле. Стала ли Java похожа на Powershell?..
Теперь давайте про ченджлоги. Посмотрим что у C# 8.X:
- Not null reference types
- Records
- HKT
- Type classes
- Defalt interface methods
- Code generation extension
- Method contracts
...
Приведите ченджлог другого языка, который похож на данный.
staticlab
23.10.2018 23:26Справедливости ради, lambda expressions (arrow functions) появились не в TS, а в JS (ES2015). При этом функции как объекты первого класса (с поддержкой захвата лексического окружения) существуют чуть ли не изначально. Обработка же исключений try/catch/finally тоже появилась давным давно, ещё в стандарте JS 1.4 (1999 год).
PsyHaSTe
23.10.2018 13:04+1Такая же или чуть-чуть получше чем в ANSI C. Какую бы вы хотели? Надеюсь не исключения, которые в том же C++ весьма не редко отключают?
Как насчет ADT? Но нет, это слишком сложно. А еще замедляет компилятор.
Так же как их нет во множестве языков, например в Java
Только в жабе есть генерики, а в го — простите. Видел Go2 — это больше на издевательство похоже. Такое ощущение, чтобы людей тошнило от генериков, а Пайк будет к каждому подходить и говорить «я же говорил, что генерики это плохо, а вы требовали… Нате, получайте».
Зато они есть в C++
А при чем тут Go? Аргумент «потому что пароход».
Зато все единообразно и чинно-благородно. Разве не к этому пытается куча фреймворков на JS, Python прийти?
У вас нет нормальных зависимостей, и все, что предлагает го коммьюнити в качестве решения — смириться.
Затем, чтобы не делать в очередной раз явную. Сначала работающий код, а потом его можно поструктурировать, если он еще остался нужным.
Удачи потом дебажить, как какой-нибудь интерфейс вывелся просто потому, что по стечению обстоятельств совпали члены типа.
Так ведь уже есть множество языков, где все что вы хотите — сделано. А вот языка, который практически не нужно учить — больше нет. Зачем нужен еще один JS/C#/C++/Java?
Хороший вопрос. Отсюда кстати следует вывод, что если Go1 еще полезен компаниям, которые хотят сэкономить на кадрах и отказываются их обучать (что хорошо для компании, но плохо для самих разработчиков и коммьюнити в целом), то Go2 — это такая вот ни рыба, ни мясо — сложно для освоения простым людям, а непростым просто ненужная солянка идея из 60х в довольно плохом изложении.
mkshma
23.10.2018 13:10+1Такая же или чуть-чуть получше чем в ANSI C.
И сильно лучше, чем в ассемблере. Как уже упомянули, монадическая выглядит неплохо, хотя очень уж из стиля Go выбиваться будет. Что в принципе даже неплохо, наверно.
Так же как их нет во множестве языков, например в Java
Язык без шаблонов обрекает себя на очень узкую область применения. Исключением могут быть разве что языки старше меня, но тут дело в специфике.
Зато они есть в C++
И поэтому пока нет никакого смысла менять C++ на Go.
Зато все единообразно и чинно-благородно. Разве не к этому пытается куча фреймворков на JS, Python прийти?
Это тот python, для которого люди придумали virtualenv, чтобы как раз эти воркспейсы и поделить? В том-то и дело, что зачастую не надо единообразно. Нужен разный зоопарк версий под разных заказчиков и возиться со всем этим в одном воркспейсе не самая тривиальная задача.
Затем, чтобы не делать в очередной раз явную.
И в итоге не понятно, во-первых, а какие интерфейсы мы вообще реализуем, а, во-вторых, нет ну вообще никаких гарантий, что мы его реализовали.
Вы какой-то rust хотите сделать из Go.
Ну, на мой вкус, не самый плохой вариант развития событий.
А вот языка, который практически не нужно учить — больше нет
У нас есть JS. SO-ориентированное программирование цветет и пахнет на нем. Код тоже пахнет. Изучение того же C++ на достаточном уровне либо отобьет у вас желание программировать, либо научит нормально распоряжаться ресурсами. Если начинать с Go, то без умного чувака рядом человек скорее всего будет гнать мусор тоннами.boblenin
23.10.2018 19:34> Как уже упомянули, монадическая выглядит неплохо, хотя очень уж из стиля Go
> выбиваться будет. Что в принципе даже неплохо, наверно.
Даже представить не могу как бы это выглядело. Можете попробовать на псевдокоде примерчик написать?
> Язык без шаблонов обрекает себя на очень узкую область применения.
> Исключением могут быть разве что языки старше меня, но тут дело в
> специфике.
Так ведь это и хорошо, разве нет? Узкоспециализированый язык, заточеный под эту специальную задачу позволит решать эту задачу более эфективно. А очередной монстр никаких преимуществ перед другими такими же языками широкого профиля иметь не будет. А недостатки — будет, в виде меньшей библиотеки инструментов, меньшего коммьюнити итд
> И поэтому пока нет никакого смысла менять C++ на Go.
И я о том же. Не надо C++ менять на Go. Кесарю кесарево.
> Нужен разный зоопарк версий под разных заказчиков и возиться со всем этим в
> одном воркспейсе не самая тривиальная задача.
Ну на это жаловаться во времена докера — как-то странно.
> И в итоге не понятно, во-первых, а какие интерфейсы мы вообще реализуем, а,
> во-вторых, нет ну вообще никаких гарантий, что мы его реализовали.
Вот с первым согласен. И считаю, что это прекрасно. А второе — действительно проблема, но ведь это и не важно. Если код потребителя изменился так, что ему перестал подходить уже реализованый интерфейс — то и проблему можно решать там, где ее проще всего решить — в коде клиента.
> Ну, на мой вкус, не самый плохой вариант развития событий.
А зачем, если уже есть rust?
> Изучение того же C++ на достаточном уровне либо отобьет у вас желание
> программировать, либо научит нормально распоряжаться ресурсами. Если
> начинать с Go, то без умного чувака рядом человек скорее всего будет гнать
> мусор тоннами.
В очередной раз вспоминаю лекцию Uncle Bob-а. Каждые 5 лет количество разработчиков удваивается. Не потому, что они на свет выползают, а потому что есть спрос. Если вы хотите ограничить этот приток, то даже успеха вам желать будет странным. Это как пытаться зонтиком заткнуть дыру в плотине.0xd34df00d
23.10.2018 20:08Даже представить не могу как бы это выглядело. Можете попробовать на псевдокоде примерчик написать?
Что именно, монадическую обработку вообще или конкретно на Go?
mkshma
24.10.2018 02:22В очередной раз вспоминаю лекцию Uncle Bob-а. Каждые 5 лет количество разработчиков удваивается. Не потому, что они на свет выползают, а потому что есть спрос. Если вы хотите ограничить этот приток, то даже успеха вам желать будет странным. Это как пытаться зонтиком заткнуть дыру в плотине.
Так пусть вкатываются, кто ж им мешает. Вот только вкатываться в IT они должны через боль и страдания, а то потом у нас Gmail лагает и на Хабре страница с 2к комментов минуту грузится. Таких вот тут не надо.
YemSalat
22.10.2018 09:51-2Electron действительно сжирает всю память и процессорное время.
Не путайте слаковский клиент и электрон. Сам электрон ничего нe «сжирает».
Недавно писал нa нем тулзу для трея — занимает 25МБ, процессор вообще не трогает фактически. Скажете 25МБ для мелкой трейной проги — это много? Я скажу что она работает на всех популярных операционках и написана нa языке без прямого управления памятью.daggert
22.10.2018 10:05+1Как человек писавший утилиту для трея в xp и убунте 6.04 — да, 25 метров это дичь для мелкой трейной проги. После всяких борландовских с++ старых, где можно было влезть в мегабайт (прога смотрящая смб шары в локалке) — электрон это жир жирный.
fatronix
22.10.2018 10:18У меня в XFCE каждый плагин для трея примерно столько же ест, две панели (по одной на экран) в сумме съедают мегабайт 200.
Sabubu
22.10.2018 11:57Может они тоже на Яваскрипте? В Гноме 3 gnome-shell написана на JS + нативный код (по типу React Native, только без потерь производительности на реакт). Ест 100-200 Мб, правда она всем занимается, и панельки выводит, и поиск, и окнами управляет.
fatronix
22.10.2018 13:08Нет, почти всё написано на Си либо других компилируемых языках.
Хотя, справедливости ради, эти плагины обычно плотно завязаны на иксы или вообще являются модифицированными либами для иксов (libxcb, например, который в момент написания комментария кушает 37 мегабайт).
xRay
22.10.2018 10:14Без информации о функционале сложно согласится с тем что всего-то 25Мб. Что ваша программа делает?
К примеру клиент Telegram потребляет 47МБ.YemSalat
23.10.2018 13:36Без информации о функционале сложно согласится с тем что всего-то 25Мб. Что ваша программа делает?
Ничего почти не делает, показывает иконку + статистику кое-какую.
25МБ весит просто обертка.
Я понимаю что в отрыве от контекста — 25МБ — это много.
Но надо учитывать, во-первых, что это всего 0.15% от современных средних 16ГБ.
А во-вторых, что за ~50 строк кода и 25МБ памяти мы получаем программу, которая работает везде без плясок с бубном.
И 25МБ не будут просто так расти в геометрической прогрессии с ростом функционала, все зависит от прямоты рук разработчиков.
Не стоит брать слак в пример, он просто коряво сделан. Я ужe вышe писал что сам юзаю веб версию вместо клиента.PsyHaSTe
23.10.2018 14:11У меня в пиках 33 гигабайта из 16 физических, потому что автор каждого из сотни процессов, что постоянно запущены в ОС исходили из той же логики. А ничего, что браузер по крайней мере четверть этого места занимает? Какой-нибудь докер еще половину. И тут остается, что у пользователя всего 4 гига свободной памяти, которую надо как-то поделить между системными процессами, каким-нибудь офисом, скайпом, и электрон-поделиями.
Neikist
23.10.2018 14:29+1современных средних 16ГБ
Вы забыли уточнить: средние 16 гигов на машине программиста. Потому что в реальности 16 гигов это ни разу не среднее значение. Обычно сейчас 4 и 8 встречаются. На совсем дешевом железе 2-3. На совсем-совсем дешевом и того меньше.JC_IIB
23.10.2018 15:08На совсем дешевом железе 2-3. На совсем-совсем дешевом и того меньше.
Это что ж за дешевое железо-то такое? В том же ДНСе компов меньше, чем с 4 гигами нету в продаже. Я бы сказал, средние машины сейчас как раз 8, реже — 16.Neikist
23.10.2018 15:38Я допустим буквально несколько месяцев назад взял ноут простенький где 3 гига. Просто в деревню ездить или на природу. Дома то понятно нормальные 16 гигов на ПК.
Притом я еще видел варианты с 2 и 1 гигом (да и сейчас есть в том же днс двухгиговые варианты за 10к примерно). И не надо забывать что есть еще и БУ железо которое покупают люди с невысоким достатком.Simplevolk
23.10.2018 15:52Вот именно, что «нормальные» 16 гигов. Собирал комп 4 года назад и поставил как раз 16 гигов «на вырост». И если раньше в среднем у меня уходило по 6-8 гигов после старта системы, то сейчас уже 10-12… Инфляция?
JC_IIB
23.10.2018 15:53Ну, если речь идет о ноутах, то тут возможны варианты, да. Я, прежде чем написать свое предыдущее сообщение, открыл сайт ДНСа и проверил — десктопные варианты у них начинаются с 4мя гигами, меньше нет.
И не надо забывать что есть еще и БУ железо которое покупают люди с невысоким достатком.
4 гб модуль DDR4 новый по ценам ДНСа — в районе 2500 р, на авито бэушные они по 2000 у барыг, стало быть у частников можно купить по 1600-1700 где-то.ainoneko
24.10.2018 10:23
Осталось уточнить, в какое место БУ железа можно засунуть DDR4. («Более старая» память дороже.)И не надо забывать что есть еще и БУ железо которое покупают люди с невысоким достатком.
4 гб модуль DDR4 новый по ценам ДНСа — в районе 2500 р, на авито бэушные они по 2000 у барыг, стало быть у частников можно купить по 1600-1700 где-то.
(Для «носить с собой в автобусе» у меня нетбук, в который больше 2ГБ просто «по инструкции» не ставится (да, говорят, в некоторые можно ставить больше, чем положено, и оно даже работает).)JC_IIB
24.10.2018 10:47Осталось уточнить, в какое место БУ железа можно засунуть DDR4
В такое БУ, которое не старше 4-х лет, DDR4 была представлена в 2014м.
«Более старая» память дороже.
ДНС, новый модуль G.Skill 4GB DDR3 = 2 тыщи рублей, Patriot 2100 р. Есть даже дешевле.
Авито первые попавшиеся предложения: Ddr3 4gb Hynix 2Rx8 PC3-10600 1250 рублей, 4гб ddr3 рс-12800/10600 — 1700 рублей.Neikist
24.10.2018 12:16Ну 4 года всего это почти новье)) Так то народ и железки вроде asus eeepc на авито покупает/продает. Я допустим сам недавно покупал, но решил что железо посовременней все же нужно и опять же продал несколько месяцев как.
batyrmastyr
22.10.2018 11:26На языке без прямого управления памятью дедушка Вирт ещё в 1989 году забахал свою оконную ОС с гибридом из среды разработки, Word Pad и ActiveX. Уж не знаю сколько оперативки она жрала, на 25 мегагерц процессора ей хватало.
zeronice
22.10.2018 12:4125Mb?!?!
Прям сейчас на .net запустил форму с треем: бинарник — 42кб и в памяти 3,5 мб. И да, вот оно процессор не трогает.GrigoryPerepechko
22.10.2018 15:28.net либо Windows-only, либо опять же тянуть целый mono на macOS/linux а это уже не 42кб.
По памяти 3.5мб для иконки в трее тоже звучит жирновато, вам не кажется?
К примеру зачем вам 1МиБ памяти для стека основного потока?zeronice
22.10.2018 17:12ну все же, .net это еще и рантайм, и спорить с нативным кодом, содержащим только winapi я не буду. по поводу 1мб на поток — это не к нам, это более древний вопрос. Каюсь в неопытности, я не знаю как указать рантайму есть меньше по дефолту, но вроде бы iis ест в 4 раза меньше.ну и этот 1м — не реально съеденный, а всего лишь обозначенный в виртуальной памяти.
PsyHaSTe
22.10.2018 17:33Во-первых mono не в моде уже года четыре.
Во-вторых то, что у вас сишный рантайм встроен в большинство ОС никого не расстраивает. C++ redistrutable на гигабайты люди охотно ставят, а вот 50мб фреймворка это чересчур. Как-то не очень честно.
Отвечая товарищу zeronice, IIS тоже кроме как в легаси проектах не используется, kestrel + nginx наше все.
OnelaW
22.10.2018 16:2625 метров это очень много.
Сможет ли утилита при том же умении отжирать памяти намного меньше?
progman_rus
22.10.2018 19:5525 метров для трея?
Она что сворачиваемость белка еще при этом считает?
PS мою молодость за такое выписывали пожизненный эцих с гвоздямиYemSalat
23.10.2018 13:48Да епрст, я ж говорю в ней 50 строк кода и она работает везде.
Понятно дело что можно заморочиться и написать отдельно для каждой платформы и сэкономить ресурсы.
Интереснее было бы посмотреть пример подобной программы например на Джаве, и сравнить количество кода / расход памяти.
unclechu
23.10.2018 03:39+1Сегодня количество веб разработчиков в разы превышает количество других прикладных программистов. Писать софт на JavaScript попросту быстрее и дешевле, чем использовать специализированные технологии.
Давайте честно назовём вещи своими именами. Сейчас много не "веб-разработчиков", а много просто плохих/слабых/неопытных разработчиков. Дефицит хороших специалистов.
Fesor
22.10.2018 02:25И даже в сотню кбайт скомпилированного EXE с зависимостями только виндовых библиотек.
Оцените стоимость разработки того же слэка в вашем исполнении. В человекогодах, с сохранением всех фич. Умножьте это все на 6 (OSX, Linux, Android, iOS, Web). И поскольку у нас теперь не 1 UI а 6 имплементаций — умножим все это на оптимистичный коэффициент 1.5 (накладные расходы на синхронизацию, коммуникацию). Не забудем о тестировании (стоимость оного так же увеличится на порядок, поскольку нам не просто надо 6 UI-ек тестить, а еще и учитывать всякие там версии операционки и кучу других нюансов). Итого — стоимость разработки увеличивается на порядок.
Теперь добавим к этому тот факт что найти разработчиков под все это, которые смогут заставить это все работать — это тот еще квэст. Уж простите, но реалии рынка таковы. Можете винить в этом ужасную ситуацию с образованием в IT в целом. Ну нету адекватных специалистов на рынке в том количестве, в котором необходимо что бы все нэйтив и т.д.
Итого — 10X стоимость разработки. Что до пользователей — как вы думаете, повлияет ли увеличение стоимости разработки на стоимость продукта для потребителя? Нет? Они там свои тарифы просто так нарисовали? Если что — подавляющее большинство пользователей пользуются слэком бесплатно. Так что будет по итогу хуже для пользователя?
Теперь о грустном — вот у меня пред глазами 2 приложения. Телеграм и слэк. Обе отжираютт 600 метров памяти, одно нативное — а другое нет. UI по отзывчивости работает примерно одинаково. Да, слэк иногда подлагивает, но обычно из-за нюансов того, как они реализовали перерисовку, а не потому что хром медленно рендрит. В нэйтиве среднестатистический разработчик так же налажает с локами трэедов или при работе с I/O. И да, по CPU в идле нативный телеграм жрет чуточку больше.
А если не видно разницы — зачем вкладывать в разработку на порядки больше средств? Не лучше ли вложить эти средства в оптимизацию UI и разработку новых фич или даже отдельных продуктов, расширяя бизнес?
p.s. как пример качественного приложения под электрон — сравните vscode с atom. И то и то написано на JS, и то и то — электрон, вот только в том как это все работает какая-то разница все же есть.
iproger
22.10.2018 02:57Все верно. Но процессоры подходят к финалу эволюции. Вы видели последние i7, точнее, уже i9? Там везде частота 4.6-4.9. 5.2 является пределом сегодня. Нельзя вечно наращивать частоты и ядра, а ядра так вообще мало помогают с однопоточными приложениями.
Рано или поздно придется отложить костыли и взяться за решение этой проблемы.Fesor
22.10.2018 03:24Но процессоры подходят к финалу эволюции
во первых не к финалу эволюции а к ограничениям элементной базы. А во вторых — причем тут процессоры?
Если что — основная проблема на сегодняшний день не процессоры, а скорость доступа к памяти и I/O. Пока вы ходите в оперативку за списком тредов вашего чатика, процессор может много чего сделать. Очень много всякого.
И выливается это все в распаралеливание и асинхронную работу. А учитывая уровень среднестатистического разработчика сегодня расчитывать на эффективную работу не приходится.
Напомню, что некие ребята из компании Mozilla дабы решить эту проблему хотя бы частично свой язык программирования придумали (именно что бы распаралелить рендринг страничек в своем браузере и при этом не свихнуться).
Что до вопроса с электроном и намеки что приложение на электроне потребляет ресурсов неадекватно больше чем нативное решение — пока это все пустые домыслы. Попробуйте реализовать какой-либо продукт нативно и в электроне. Причем так что бы функционал был идентичен и исходники открыты (дабы можно было объективно проверить насколько качественно реализовано).
Я бы не сказал что все это кастыли. Скорее это попытка компенсировать низкий уровень разработчиков.
iproger
22.10.2018 17:38Да, вы правильнее написали. Финал для текущей архитектуры.
Я думаю что проблема именно в скорости цп. Это заметно когда даже 8700k 5.0ггц открывает программы с небольшим пролагом. Ту же phpstorm он открывает 5-10 секунд. И вряд ли дело в диске: m2 samsung 970 pro — один из быстрейших ssd. Мне видится что проблема именно в скорости ядер. Даже если поставить ramdisk то все равно не будет нужной скорости. Тот же тяжелый скрипт выполняется за 300мс под всеми оптимизациями (я про мадженту).
Рзработчики игр, например, все больше уходят в многопоточность: для последних игр уже необходимы 4, а желательно 6 иди 8 ядер.Fesor
22.10.2018 19:12Это заметно когда даже 8700k 5.0ггц открывает программы с небольшим пролагом.
и пролаг этот связан с тем что ваш процессор ждет пока данные загрузятся (из кэша, потом из памяти при кэш мисе, и если что еще на файловую систему сгонять).
Ту же phpstorm он открывает 5-10 секунд.
И как вы думаете, какой процент этого времени уходит на ожидание I/O? Или вы думаете оно там яростно что-то считает?
один из быстрейших ssd
Даже если поставить ramdisk то все равно не будет нужной скорости.
Рзработчики игр, например, все больше уходят в многопоточность
Ну вы сравнили, объемы вычислений игрушки какой и объем вычислений требуемый тому же шторму.
Шторм упирается в I/O. Да, есть нюансы, типа специализированный софт для симуляций, визуализации и т.д. который можно развивать только за счет параллелизма вычислений, но это опять же маленький процент прикладного софта.
iproger
22.10.2018 19:47Так я не только о шторме. Все программы бы работали сильно быстрее если сделать у cpu условные 10ггц.
Вот reindex проекта, использование диска было по-минимуму.
Качество не получилось, прошу прощения :)Fesor
22.10.2018 20:09Все программы бы работали сильно быстрее если сделать у cpu условные 10ггц.
нет. Еще раз — проблема не в CPU у 90% приложений. Проблема в работе с памятью.
Вот вы PHP разработчик, да? Помните выход php7? Мол "теперь в 2-3 раза быстрее". Вы же понимаете что это "быстрее" было не потому что у вас вдруг дополнительно частот стало больше, а потому что сильно оптимизировали работу с памятью, повысили локальность данных, уменьшили количество кэш мисов процессора.
А потому ваш слэк или шторм будет педалить одинаково что на 5Ghz что на 10Ghz. А вот скажем рендринг картинки в каком vray будет да быстрее порядочно.
Вот reindex проекта, использование диска было по-минимуму.
А теперь попробуйте сделать так — понизьте частоты вашего процессора и повторите эксперемент. И попробуем найти корреляцию суммарного времени построения индекса от частот CPU.
iproger
23.10.2018 00:52Вот вы смеетесь, а я не поленился и проверил. Хотя погрешности наверняка имеют место быть.
8700k 5.0 3600, ssd обычный: reindex 17:00 sec.
8700k 3.0 3600, ssd обычный: reindex 28:00 sec.
Предварительно несколько раз прогнал ради разогрева кэшей. Конечно, 3.0 — нижняя планка для настольных процессоров сейчас, но результат показательный.
При этом согласен что io тоже в равной степени медленное. И скорость действительно сильно зависит от оптимизации кода.
На тех же Райзенах очень важна частота и вид оперативы, разницу даже видно невооруженным глазом. А у Интела тащит кэш.
Ну это мое мнение.Neikist
23.10.2018 00:55Ну так то и целероны всякие в бюджетных железках используются.
iproger
23.10.2018 01:00А каким боком они?
В тесте выше тогда надо было отключить 2-4 ядра и оставить 2. Тогда частота повлияла бы еще сильнее.
Я бы не стал сравнивать i7 с селеронами. Как минимум из-за большего кэша и большего числа ядер.
Да и во многих многоядерных процессорах частота часто в пределах 3.3-3.6.Neikist
23.10.2018 07:14Ну я к тому что на них еще как бы не на порядок все медленнее бы делалось. Так что я с вами согласен что не только I/O слабое место а процов давно хватает.
PsyHaSTe
23.10.2018 13:10По двум точкам трудно судить. Сделайте замеров 20 с шагом 0.1, тогда корреляция будет четко видна. Если, конечно, это не слишком сильно вас затруднит.
Vilgelm
23.10.2018 02:49Что до вопроса с электроном и намеки что приложение на электроне потребляет ресурсов неадекватно больше чем нативное решение — пока это все пустые домыслы
У Telegram есть нативный клиент и клиент в Electron (даже несколько). Можно сравнить. Но учитывая, что нативный клиент умещается в 47 MB (если там не миллион чатов), а сам по себе пустой процесс Chrome ест около 60, то сравнение будет явно не в пользу Electron.
remzalp
22.10.2018 08:20Ок, немного снизить потребности поможет Java или если совсем C++ — QT, оно работает уже много где, так что более половины перечисленных платформ (без учета тонкостей) смогут поддерживаться одной кодовой базой.
Fesor
22.10.2018 14:18+2поможет Java
я сейчас смотрю на то сколько жрет IDEA и VSCode на одном и том же проекте (и да я понимаю что IDEA может делать много больше того, что я использую, но оно ж мне и не нужно) и как педалит их UI, и у меня возникают сомнения.
Опять же — вы недооцениваете возможности современных браузеров в плане отрисовки UI. Да, есть нюансы но в целом не думаю что у того же свинга есть хоть какие-то преимущества перед страничкой отренденной хромом.
QT
Помню году так в 2009-ом ковырялся с их этим QtQuick. Мне идея дико нравилась и реализация была неплохой. Во всяком случае писать софт под десктоп не на QT мне тогда не хотелось. Однако, беря в расчет то как реализован Qt, сомневаюсь что получится что-то существенно лучшее.
смогут поддерживаться одной кодовой базой.
Вот только я не хочу писать ни на Java ни на C++. А хочу например на Rust всю бизнес логику писать. Потому что type safe и прочее и прочее. Или на хаскеле.
На данный момент существуют два решения для интероп языков — webassembly (все компиляторы на базе LLVM в целом уже умеют в него компилить) и graalvm (оч интересный проект как по мне). А потому опять же — электрон выыигрывает тут так как в отличии от ораклавской graalvm все основано на открытом стандарте.
0xd34df00d
22.10.2018 17:59Однако, беря в расчет то как реализован Qt, сомневаюсь что получится что-то существенно лучшее.
Хм, почему? Да и старые добрые императивные qtwidgets никто не выпиливает.
Fesor
22.10.2018 20:11ну если мне память не изменяет, они просто все контролы на opengl запилили. Почти как это делают браузеры со своим html+css. Ну или вы можете сделать на webgl ;)
0xd34df00d
22.10.2018 21:10Тормоза возникают-то не из-за OpenGL. Я бы ещё понял, если бы вы, например, на их V4 (который кастрированный V8 и который занимается выполнением их диалекта ecmascript) кивнули.
Fesor
23.10.2018 00:06Тормоза возникают-то не из-за OpenGL.
тормоза происходят из-за блокировки потока перерисовки этого UI. А заблокировать этот самый поток легко когда он один.
Всякие же сервис воркеры для фронтэндера это уже ух, сложна. Ну то есть требует уже уровня повыше среднего.
0xd34df00d
23.10.2018 00:12А заблокировать этот самый поток легко когда он один.
Вот как раз классический GUI-поток (с xlib) в иксах ровно один.
А если у вас синтаксис декларативный, модельки эти все там, и руками ничего императивного вы не пишете, то достаточно умный™ компилятор и рантайм могут это всё раскидать по потокам.
Alex_ME
22.10.2018 23:08Подождите, я правильно понял, что они берут браузер, который написан умными людьми на C++/Rust и который с помощью OpenGL хардверно ускоренно рисует всякий HTML-GUI, и затем из всего HTML-GUI используют canvas, в котором с помощью OpenGL на JS рисуют свои кнопочки?
Fesor
23.10.2018 00:08+1все так. Смысл в этом небольшой конечно, разве что полная свобода и полная независимость от вендора браузера.
poxvuibr
22.10.2018 18:00электрон выыигрывает тут так как в отличии от ораклавской graalvm все основано на открытом стандарте.
Ну стандарта может и нет, но код то у GraalVM открытый
AllexIn
22.10.2018 14:23Не не не. Писал на QT под мобилки — очень специфично и уж точно «одной кодовой базой» не пахнет.
Simplevolk
22.10.2018 08:39Вот поэтому я использую Телеграм, а не Слак. Потому что телеграм не отъедает по гигабайту памяти. И легковесный. Сейчас, в 2018-м это ценно.
algotrader2013
22.10.2018 08:53Отличный пример, кстати. Слак, у создателей которого сейчас деньги не кончаются, а они жмотятся на портирование в нативный код. И телеграм, который с первой версии с намного меньшими ресурсами делался как надо (правда Дуров начинал с реально сильной командой олимпиадников, а не энтерпрайз макак). Но, к сожалению, инвесторы активно раздувают капитализацию слака, тем самым говоря, "красавчики, продолжайте в том же духе".
fatronix
22.10.2018 10:28Если бы в нём еще память не текла, было бы вообще замечательно. За неделю аптайма с 50 мегабайт жиреет до 500.
IgnisNoir
22.10.2018 13:30Это вы о Слаке или о Телеграме? О_О просто у меня ни та мни там не течет. А комп я не выключаю месяцами
fatronix
22.10.2018 13:52О телеграме. Сейчас он запущен с утра пятницы (3 дня) — уже съедено 220 мегабайт.
faiwer
22.10.2018 14:32+1У меня 23.5 GiB ОЗУ. Увеличивал с 16, ибо стало не хватать. Ииии. Всё равно не хватает. Всё течёт. Уже выработался рефлекс. Вижу 90+% потребление ОЗУ? Ок, перезапускаю skype и виджет потребления озу на mate-panel показывает ступеньку вниз (падает 5-8% потребления). Перезапускаю Vivaldi — ещё 20%. Перезапускаю Chrome — ещё 20%. Оба браузера восстанавливают все открытые вкладки. Но память к прежнему уровню сразу не восстанавливается. Перезапускаю shutter, slack, tint2 — ещё по 10%. Т.е. просто перезапустив окружение я возвращаю себе 10+ GiB ОЗУ. День-другой и снова приходится повторять расстрелы.
Не могу понять, это нынче так софт пишут, если у меня что-то с системой не то? Раньше (пару лет назад) при 16 GiB ОЗУ я редко превышал 10 GiB отметку. Скажем когда запускал сразу 2 virtual box VM.
Chamie
23.10.2018 14:48Может, просто кэши наполняют?
faiwer
23.10.2018 16:46Думаю у каждого текущего приложения может быть своя проблема. Скажем какие там у tint2 (написан на C) могут быть кеши? А разпирает его порой больше 2 GiB. Shutter (python) растёт как на дрожжах с каждым новым скриншотом. Явно течёт память. Браузеры, те и правда могут что-то жесточайше кешировать. Потом текут отдельно взятые табы в них. Вот у меня открыт inoReader в Vivaldi. Кушает он сейчас немного не мало — 1400 MiB. Доходило и до 3+ GiB. В нём реклама течёт. Автор об этой проблеме знает — говорит покупайте премиум, там без рекламы. Skype и Slack текут
потому что электронруки кривые, видимо, у авторов. Кто знает. Тут надо детективную история по каждому случаю проводить.
LexS007
22.10.2018 12:14Вот тут да, телеграм отличный пример, уже почти под каждую платформу вторые переписанные с нуля клиенты выпустили.
GrigoryPerepechko
22.10.2018 15:42Телеграмм под macOS после запуска и 5 минут использования отъел 650MB
Он написан на плюсах и свифте, работает фантастически быстро. Но с памятью не всё гладко.
some_x
22.10.2018 09:51Но есть же нормальные кроссплатформенные инструменты: .NET core, xamarin, QT, java. Зачем выбирать выбирать тормозной WEB?
YemSalat
22.10.2018 09:56Покажите мнe кроссплатформенное приложение нa той же джаве, которое не «жрет» ресурсы.
PsyHaSTe
22.10.2018 15:03-1По сравнению с целым электроном оно не «жрет» ресурсы, а вежливо подъедает с уголка.
gotozero
22.10.2018 17:42Жор ресурсов не единственный компонент злобы на электрон.
Оно при этом еще и тормозит.
Я готов простить жор Идее например, если она выполняет важные задачи и довольно быстро.YemSalat
24.10.2018 12:56Опять же это зависит в основном от прямоты рук разработчиков. Выше ужe приводили в пример VSCode, который IDE на электроне и работает пошустрее того же вебшторма например.
evnuh
22.10.2018 20:50+1кросплатформенные нынче — это обязательно +iOS и +Android. Ещё желательно +web.
kpakozz96pyc
22.10.2018 10:35я не верю что телеграмм ест 600мб, хоть убейте, ни разу не замечал ни единого лага в нем, в то время как slack жутко тупит просто при разворачивании его из трея.
Вот сейчас я на них смотрю — слак — 500мб и 4 канала +8 чатов, телеграм 32мб 20 каналов и 30+ чатов.
При умножении на 6 — вы тоже ошибаетесь — непосредственно написание кода — это не 100% разработки. Спецификации, дизайн и аналитика едят гораздо больше, при этом шарятся между платформами процентов на 90.defaultvoice
22.10.2018 11:22Да нет, было такое несколько раз. Но они буквально в течение пары дней выпускали апдейт, который это фиксил (загадочные надписи в чейнджлогах на манер «Performance improvements» были как раз об этом)
Vilgelm
23.10.2018 02:58Telegram начинает столько есть когда в нем около 1000 активных чатов и под 10 млн непрочитанных сообщений. Проверено лично.
pansom
22.10.2018 10:37Телеграм отжирает 7мб оперативы. ЧТО Я ДЕЛАЮ НЕ ТАК?
khanid
22.10.2018 20:33В зависимости от. Допускаю, что у него память течь может где-то, но я не сталкивался. Основные цифры потребления телеги у меня умещаются в 100 Мб (да данный момент 87540 Кб) — у меня куча картинок и анимации, типа гифок, в общении обычно. В любом случае. Для телеги 600 Мб и больше — явно не норма. А вот для слэка, судя по комментариям, вариант нормы.
AlexTest
22.10.2018 12:27вот у меня пред глазами 2 приложения. Телеграм и слэк. Обе отжираютт 600 метров памяти
Telegram 600 метров — жесть, что вы с ним делаете если не секрет?
У меня 50-70 метров максимум:
Fesor
22.10.2018 14:22+2
был запущен 12 дней. После перезапуска сходу сьел 190 метров.
Vilgelm
23.10.2018 03:00У вас точно нативный клиент, а не один из тех, что на Electron? Или сколько у вас чатов\каналов?
Fesor
23.10.2018 03:15групповых чатов штук 20, приватных — штук 100, может больше, не знаю где посмотреть. сообщений в день прилетает под пару сотен (почти все в мьюте). Нет не электрон — тот который официальный нативный на плюсах и все такое.
Self_Perfection
22.10.2018 19:35Я когда-то давно поставил у себя на мониторинг процесс telegram-desktop, так что могу показать
график использования памяти telegram-desktop 1.3.14
PsyHaSTe
22.10.2018 14:59Эм, что вы с телеграмом делаете, что он 600мб ест? Я больше 100 в жизни не видывал, хотя у меня полсотни разных чатов и каналов с кучей картинок и гифок.
Для сравнения, вкладка гмейла ест как раз те 600мб.GrigoryPerepechko
22.10.2018 15:48На винде и macOS по разному.
На macOS меньше 300 со старта у меня не получается — snag.gy/nlQiEX.jpg
unclechu
23.10.2018 03:42Они там свои тарифы просто так нарисовали?
Маленький инсайд, — зачастую ответ на этот вопрос — да (без шуток).
Massacre
23.10.2018 05:07Это просто конкретно Телеграм течёт по памяти, его надо перезапускать через некоторое время и будет снова мегабайт 50-60. Слаку же это вряд ли поможет. Правильнее сравнивать с Мирандой.
Sabubu
22.10.2018 08:04Только не будет ли ваша софтинка выглядеть как серое окно с кнопками из 90-х? Посмотрите на мобильные приложения — пользователи привыкли немного к другому дизайну. Сможет ли ваше приложение асинхронно работать со всякими HTTP API, получать и передавать данные, синхронизировать их локально?
Что касается C#, это хороший язык (типизируемый, компилируемый, со сборкой мусора и с ООП), но не знаю, насколько легко на нем писать не привязанные к винде приложения. Вы пишете, WPF, но это будет работать только под виндой.
Что касается дельфи… он как бы немного устаревший.
j_wayne
22.10.2018 09:48> Только не будет ли ваша софтинка выглядеть как серое окно с кнопками из 90-х? Посмотрите на мобильные приложения — пользователи привыкли немного к другому дизайну.
Но это же не проблема. Telegram Desktop имеет вполне обычный «web desktop app» вид. Но к ресурсам не сильно требователен, отзывчивость GUI тоже адекватная. На Qt написан.
HTTP API, вебсокеты — все это в Qt есть. Для этого не обязателен браузер)
Solexid
22.10.2018 09:48.net standart + Avalonia.Ui. Одна кодовая база, работать будет на всём.
staticlab
22.10.2018 11:44А есть на Авалонию какая-нибудь адеватная демка, чтобы потыкать на разных платформах?
KvanTTT
22.10.2018 12:10Например AvaloniaILSpy, дизассемблер .NET.
staticlab
22.10.2018 12:33Если честно, контролы довольно мерзкие, причём на всех платформах сразу. Выглядят нисколько не нативно. На Убунте, к тому же, дропдауны в настройках не работают от клавиатуры. Рендеринг шрифтов ужасен. Копипаст через контекстное меню не работает. Активаторы по Alt в линуксе не работают. Контекстное меню по соответствующей клавише на клавиатуре нигде не работает. Вангую также большие проблемы с accessibility.
Помимо прочего, разработчики приложения забыли, что на линуксе регистрозависимая файловая система, из-за чего приложение падает при правом клике на сборку (идёт запрос файла
images\Delete.png, а директория называетсяImages).
Вердикт: пока что крайне сырая библиотека, и использовать её для реального кроссплатформенного приложения не стоит.
staticlab
22.10.2018 13:12На Убунте, к тому же, дропдауны в настройках не работают от клавиатуры.
Поправка: не работают с мышкой, только с клавиатуры.
kin63camapa
22.10.2018 12:52пусть мое приложение будет выглядеть как окно с кнопками из 98 винды, пускай оно будет на псевдографике (а лучше просто текстовое, я так и не сумел сделать так чтобы на мой 25 дюймовый монитор помещалось больше десятка сообщений), но если меседжер жрет 300 мегабайт памяти то в топку такой меседжер
Fesor
23.10.2018 11:48Вы же понимаете что телеграм это не просто текстоый меседжер? Стикеры, аттачи аудио, различные графические ресурсы (аватарки), форматирование текста, ну и webrtc, шифрование всего этого дела.
Невидимая рука рынка так решила, что месенджеры отжирающие по 300 метров памяти нужны, значит они нужны. Иначе спроса бы небыло.
Другой вопрос что возможно рынок так решил потому что качественно лучше ничего нет. Может быть вам стоит сделать свой продукт качественно лучше чем все что есть на рынке, и возможно на ваш продукт будет высокий спрос.Massacre
23.10.2018 22:57Альтернативы-то нет уже (был скайп, убили). Если вы считаете, что пользователям нужны именно тормознутые и жрущие мессенджеры, то вы это зря. И почему именно webrtc?
biseptol
22.10.2018 19:09Сколько времени и денег будет стоить написать и поддерживать Slack на 1) WinAPI, 2) Cocoa, 3) Cocoa для iOS и еще 4) на Java/Kotlin для Андроида? И 5) веб версию? И чтобы это все красиво и одинаково выглядело?
Поставьте себя на место даже не владельцев бизнеса, а менеджера разработки, перед которым стоит выбор: логистический и управленческий ад синхронизации пяти разных codebases и содержание команды в (как минимум) пять человек на мартышкин труд писать одно и то же на разных языках. Либо взять проверенный и работающий для 99% Electron и бурно развивающийся и богатый возможностями JS+React+HTML5+CSS, в которых JSON можно загрузить одной строчкой, а анимацию сделать двумя.
Electron — это, возможно, крайность, но тот же React Native — это вполне себе способ кросс-платформенной разработки, если есть задача сделать продукт, который можно развивать и поддерживать.iPilot
22.10.2018 19:46Epic Games (создатели Unreal Engine) срубили сотни миллионов бабла на Fortnite, и вдруг снизили цену на лицензию этого самого Unreal Engine. Тот случай, когда денег слишком много для конкретной группы лиц. Видимо, другие намного жаднее.
khanid
22.10.2018 20:47За различные платформы в части UI не скажу, но вот вопрос у меня возникает. А что, логика приложения принципиально от этого будет отличаться? Я просто не могу представить, какой функционал WinAPI может логике программы-чатика понадобиться?
Переписывал тут старое одно своё приложение года 2 назад с win7+mysql на centos + mariadb. Всё, что мне пришлось поправить, это работу с сокетами и БД — по странице кода на каждый. Различия в ОС, да. Но вот в остальной части ничего не трогал — стандарты c++ не от ОС же зависят.
Но у меня нет графики. Даже если графика задействована, то она, по-прежнему, обёртка над логикой, прослойка между пользователем и логикой. Если же логика привязана к специфическим для ОС элементам управления, то я глубоко задумался бы.
Simplevolk
23.10.2018 08:34А потом в один прекрасный момент, выходит легковесный и быстрый аналог слака\скайпа и все с радостью в одно мгновенье пересаживаются на него (WhatsApp,Telegram vs Скайп).
Neikist
23.10.2018 08:44По моему скайп спасают хорошие звонки, демонстрация экрана и инерция корпоративного сектора. Потому что лично я уже давно только телегу использую, а скайп запускаю только на работе.
Fesor
23.10.2018 11:50звонки у слэка тотго же тоже неплохие, как и шаринг экрана. Так что остается только инерция корпоративного сектора.
p.s. за последние 3 года пользовался скайпом исключительно через web.Neikist
23.10.2018 12:10Так слак та же хрень, единственное чем лучше скайпа — наличием пары доп функций. А тормозит также.
faiwer
23.10.2018 12:25Несколько раз пробовал пользоваться звонками slack-а. Не смогли. То не заводится, то не слышно, то приложение уходит в какой-то вечный цикл, то ещё какая-то чертовщина. Так ни разу не удалось нормально воспользоваться им. А desktop-версия под linux у меня даже "взять трубку" ни разу не смогла (в отличии от браузерной).
fiftin
22.10.2018 19:16Можете скинуть ссылку на ваше приложение? Хотел бы оценить насколько крут UI написанный на MFC.
ivan386
23.10.2018 00:13Ну десктопное приложение на JS можно было писать под Windows со времён IE 5. Но единственное которым я пользовался это был интерфейс для ffmpeg или подобного конвертера видео.
Интересно в современой винде работают hta или нет?
Dimash2
22.10.2018 02:01+2А я хотел бы защитить Электрон. Я запускал под электрон бету версию пульта управления Windows с Айфона. Писал для себя, в продакшн не запустил, потому что были баги. Имел не малый опыт по написанию JS софта под еще старые ipad при помощи webview, но окружение тогда было запрограммировано Xcode программистом.
Мое личное мнение, что Slack тормозит, потому что именно его код написан плохо, а не потому что он на Electron. Так как я часто пишу разный высоконагруженный код в браузер, собственно я пишу разный софт, который работает из под браузера и с большими данными и с разными анимациями, то я вас уверяю, что да, запуская софт при помощи Электрон — вы подтягиваете много в оперативку, но не он прямо ответственен за баги, а именно реализация.
Я искренне, вообще не понимаю, как разработчики уровня Slack позволяют такие тормоза, ведь это всего-лишь управление текстовыми данными и так как js позволяет все делать асинхронно, то нагрузку можно прекрасно балансировать.
Может меня заминусуют, но я люблю писать JS софт, это невероятно просто, но я знаю как писать его так, чтобы он работал быстро и даже парюсь, чтобы он не мучал батарейку, но мне не нравится, когда просто плохой софт выдают за проблему платформы.
Тот же Atom, давным давно был достаточно быстрым, но сегодня — он на столько тормознутый, что им невозможно пользоваться, но пробелма там же не с Electron, а именно с реализацией подсветки синтаксиса. На сколько я помню, все Webview редакторы используют одну и ту же библиотеку подсветки, что и приводит к абсолютно одинаковым тормозам, что Atom, что Adobe. Отсюда у меня простейший вопрос, кто те разработчики, которые это планировали и решили, что и такие редакторы стоит выводить в продакшн да еще и не фиксить столько лет? Но многие люди всеравно опользуются, не смотря на то, что редактировать уже даже стандартный файл не является возможным.
Я посмотрел свой диспетчер задач, никакой безумной активности в простое (именно активности) я не заметил, но из Electron софта у меня только Slack. Но знаете, что больше всего сжирает ресурсов в Скайпе? (Сейчас найти не могу, но раньше так было) — рекламный Баннер ), приходилось раньше открывать другой окно Скайпа, чтобы баннер ушел и нагрузка на CPU ушла.PsyHaSTe
22.10.2018 15:07Может меня заминусуют, но я люблю писать JS софт, это невероятно просто, но я знаю как писать его так, чтобы он работал быстро и даже парюсь, чтобы он не мучал батарейку, но мне не нравится, когда просто плохой софт выдают за проблему платформы.
…
На сколько я помню, все Webview редакторы используют одну и ту же библиотеку подсветки, что и приводит к абсолютно одинаковым тормозам, что Atom, что Adobe. Отсюда у меня простейший вопрос, кто те разработчики, которые это планировали и решили, что и такие редакторы стоит выводить в продакшн да еще и не фиксить столько лет?
Есть подозрение, что если никто не смог написать библиотеку лучше Webview, то может это проблема платформы и написать такую производительную библиотеку невозможно? По чисто объективным причинам, примерно тем же, почему хорошо структурированное нормализованное апи сталкивается с проблемой N+1.
advance
22.10.2018 02:08+1Это, конечно, всё очень далеко от реальности…
Не поймите не верно- я сам android-разраб и пишу исключительно натив, и у меня JS-приложения тоже вызывают негодование.
Но IT правит бизнес. И только бизнес. И он двигает индустрию, разработчики к этому не причастны.
И вот когда начинаешь считать деньги- выясняется, что JS-приложения очень дешево обходятся. В том числе и с косяками. А еще выясняется, что время разработчика стоит дороже вычислительных ресурсов пользователя. Точнее эти ресурсы для бизнеса бесплатны почти совсем. И этими ресурсами бизнес расплачивается за скорость и дешевизну JS-фреймворков.
И тут два выхода:
1. Заставить бизнес платить за ресурсы пользователя. Не знаю чем и как, но это бы сделало фактор реально важным. Минус- много игроков уйдут с рынка
2. Стандартизировать API или вообще заставить всех поддерживать JS. Но тут минусов еще больше:
Все перейдут на что-то типа Chrome OS и конкурировать останется мало чем.
Внезапно выяснится, что подход с реализацией интерпретируемого языка с нестрогой типизацией сам по себе затратен. Ведь для системы уже нет разницы между Boolean и String. Экономить просто не на чем. Плюс в JS придется вводить много жизненного цикла сущностей, к чему он просто не готов. На выходе получаем неповоротливую тупую монстро-ось, но зато да- в JS локально можно будет из коробки, да. И бизнесу обойдется в копейки.
Вывод прост- в мире пишется много хороших, быстрых и экономных софтин. Но если общество привыкло естьфекалиикактус- то и вам придется. Иначе вы окажетесь отрезаны от благ общества частично или полностью.Dimash2
22.10.2018 02:13Как JS разработчик, я считаю, что скорости JS достаточно для реализации большинства софта информационного типа, типа базы, выборки, складской контроль, общение. Но вот конкретная реализация губит, потому что вход в JS слишком простой и видимо реализуют приложения без должного уровня. Вы же, наверное, знаете Java, раз андройд разработчик, то вы, думаю понимаете, что на определенном уровне для Десктопов Java тоже медленная, но на самом деле — нет.
Вот интересно, когда JS, NodeJS и С работют вместе передавая все координаты с тачскрина телефона на Windows и управляют курсором, управлением текста и тд, то разве этого может быть мало для написания чатика? Slack тормозит, потому что сделан плохо, а не потому что Electronadvance
22.10.2018 02:51На самом деле давно уже не писал на Java- проекты довольно необычные, часто приходится переключаться на C, а в основе уже везде Kotlin.
И я написал это потому, что дожился до написания собственных интерпретаторов и виртуальных машин (не для JS. проприетарщина). И примерно с этого момента начинаешь понимать, что реализации слабой типизации без ЖЦ, или, например stateless- они все имеют ряд именно концептуальных проблем.
Да, разные реализации софта на JS будут показывать разную производительность. И на машине с i5 и выше, Вы, скорее всего, не заметите разницы в работе одной и той же простой логики на JS и Java и нативе. Но, чем логика жирнее, и чем машина слабее- тем больше будет проявляться разница.
Факт в том, что так или иначе- чтобы JS вращался нужно больше ресурсов. Ведь JS-примитив содержит больше информации, чем, например, C-примитив. Плюс нужно больше компонент, чтобы этот примитив обслуживать, адресовать. И это всё добро, призванное облегчить жизнь разрабу, надо где-то хранить. Конечно же, в оперативе пользователя.
Так что нет- одна и та же логика не может работать одинаково быстро на JS\Java\C чисто математически.
Со Slack другая проблема- ни Electron ни JS сам по себе не могут корректно работать с ЖЦ Win\Mac\etc… И не смогут- JS разработан дня веба, для него предназначен, и в нем должен оставаться. Попытки запихнуть JS в приложение- это как ехать на санках по асфальту летом- это реально, но не эффективно. Но дешево, если под рукой только санки. Так что, люди в Slack не криворукие, просто (слишком) экономные
Alexufo
22.10.2018 02:19с 30:25
Dimash2
22.10.2018 02:36+1Я хотел бы напомнить, что в свое время Flash сыграл огромную роль в формировании интерактивного веба, и потому не нужно использовать Flash как ругательство. Он появился в удачное время, отслужил свое и умер.
Дождемся нативной поддержки JS и все )Fesor
22.10.2018 02:49Flux
22.10.2018 04:23Дождемся нативной поддержки JS и все )
Вот это и будет черным днем календаря, когда тысячи электрон-макак хлынут в десктоп. Проблемы — они всегда в кадрах, и если дать возможность плохим кадрам писать некачественный код — они ей непременно воспользуются.0xf0a00
22.10.2018 09:28Ахах… это будет началом смерти JS. В свое время за простоту поплатился Delphi, когда тысячи макак у которых из знаний только как Button1 на Form1 положить хлынули в десктоп.
ValdikSS
23.10.2018 22:14Эта Button1 на Form1 компилировалась в 400 КБ нативного кода, не тормозила и не потребляла памяти.
sentyaev
23.10.2018 23:01В те времена говорили, что 400КБ это нереально много для приложения с одной кнопкой.
Я к тому, что история повторяется и уже не первый раз.ValdikSS
24.10.2018 09:32+1Это действительно много, даже по нынешним меркам. В Delphi свой собственный графический фреймворк VCL, именно он дает такой размер файла. Он достаточно эффективен, поэтому ему прощалось.
Можно было писать без него, на чистом WinAPI, или с использованием сторонних фреймворков, тогда размер файла был от 12 КБ, насколько помню.
Современный Delphi очень продвинут, на нем можно графические программы под почти все ОС писать, а с помощью сторонней реализации Object Pascal — еще и под WebAssembly.
Scf
22.10.2018 18:54+1Меня заголовок статьи выморозил в обратную сторону — как будто они заявили, что электрон имеет все преимущества flash — компактность исполняемого файла, обратную совместимость, эффективность, малое потребление памяти...
Flash не просто так был стандартом для анимации и сложных веб приложений.
sumanai
22.10.2018 21:41Flash не просто так был стандартом для анимации и сложных веб приложений.
Другого в те времена просто не было.
YemSalat
24.10.2018 02:33> компактность исполняемого файла
если нe учитывать «компактность» самого плеера
> обратную совместимость
AS2->AS3 разве были обратно совместимыми?
> эффективность
как это определяется?
> малое потребление памяти…
и немалое потреблениe процессора
Это я не к тому что флэш «плохой», но своих проблем у него хватало.
porn
22.10.2018 02:52Есть проблема с отсутствием нормальных кроссплатформенных GUI фреймворков. Поставим целью написать лёгкое десктопное приложение на Rust — как реализуете GUI? Подтянем GTK/Qt/что ещё, либо сделаем API, с которым может работать много разработчиков.
some_x
22.10.2018 09:59Несколько вариантов:
1) Можно использовать подход Xamarin`а: пишем общую логику на Rust, а GUI реализуем нативно.
2) Если нам не нужно поддерживать старые платформы, то можно использовать гибридный подход: использовать для отрисовки стандартную для платформы WebView, а код отрисовки и логику напишем на Rust.
3) А что собственно не так с Qt, на мой взгляд этот тот самый «нормальный кроссплатформенный GUI фреймворк»Neikist
22.10.2018 10:02использовать для отрисовки стандартную для платформы WebView, а код отрисовки и логику напишем на Rust.
react native наоборот?))
PloAl
22.10.2018 04:11Статья оригинал не такая свежая.
Slack не пользуюсь, часто запущен Whatsapp десктоп, диспетчер задач постоянно на втором мониторе, потребления ресурсов Whatsapp не замечал, 300мб памяти занимает, соглашусь не мало. Также есть свое приложение на electron, нагрузки на процессор в свернутом режиме в фоне, тоже не замечал, памяти всего 111мб.
Также пользуюсь VS code, там порой видна в фоне какая то нагрузка, периодически бывает до 10%, но это совсем другое приложение.
staticmain
22.10.2018 09:47Статья оригинал не такая свежая.
Сейчас slack отъедает от 1.5 ГБ и выше на многоканальной переписке.Neikist
22.10.2018 10:01-1Ы, недавно себе edc ноут за копейки купил, чтобы например в деревню ездить, на природу взять, иногда на работу. Так там всего 3 гига памяти))
anttoshka
22.10.2018 09:23А не будет ли выходом написание PWA приложений? Браузер есть, API предоставляет. Для приложений-чатиков этого с головой должно хватать.
kemsky
22.10.2018 10:26Flash для десктопа был уже 10 лет назад и есть до сих пор, называется Adobe Air. Причем писать можно было и на js, точно так же как на электроне сейчас.
iLLuzor
22.10.2018 22:09AIR приложения никогда не жрали столько оперативки. Я когда-то писал игру под ios/android с кучей анимаций и физикой, и укладывался в 40 мегабайт оперативки.
Fesor
23.10.2018 00:10ну да, хай рез сплэш скрин для загрузки или крутой пак иконок под тот же хай рез туда не запихивали.
justboris
22.10.2018 11:21+2Справедливости ради, замечу, что в 2017 году (после выхода этой статьи) команда Slack провела работу по уменьшению потребления памяти, результаты которой изложены здесь: slack.engineering/reducing-slacks-memory-footprint-4480fec7e8eb
Интересно посмотреть на независимые результаты замеров после этих изменений.Static_electro
22.10.2018 18:16+1вот прямо сейчас на домашнем ноуте «десктоп» клиент слак съедает до гигабайта легко и непринужденно. А поскольку ноут старый и памяти там всего 4 га — то каждое разворачивание слака из «неактивного» режима превращается в повод сходить поставить чайник, например. Подгрузка истории и переключение каналов — тоже приключение, с тоской вспоминаешь, как раньше текстовые чаты были текстовыми чатами.
Мне менять ноут или слак? Даже не знаю… на ноуте я еще и поиграть могу, и поработать — visual studio и та себя отзывчивее ведет.justboris
22.10.2018 18:49Я бы сменил Slack. Ибо зачем кушать кактус, если он колется.
А если Slack – это требование для работы, то будет уместно попросить работодателя об апдейте рабочего железа.Static_electro
22.10.2018 19:19Не, слак домашний, не рабочий. Да и вопрос риторический, в общем-то. Я хотел ответить на
Интересно посмотреть на независимые результаты замеров после этих изменений.
ну и увлекся слегка, потому что горит)
Кратко — слабые машины умирают всё так же, как и раньше.
vladbarcelo
22.10.2018 12:46- Оф. поддержки реакт-нэйтив для чего-либо кроме мобильных ОС нет
- VSCode написан на электроне и каких-либо проблем с его производительностью (в том числе на маке) я не вижу
- Можно призывать жаловаться и отказываться от технологии, а можно её совершенствовать
Neikist
22.10.2018 13:04Стоит признать что тот же вим работает явно побыстрее)) Впрочем да, vs code наверно единственный более менее адекватный продукт на электроне, и то насколько слышал там ооочень многое в натив переписали.
Terras
22.10.2018 13:19-1Учитывая то, что Vs Code — это один из ключевых козырей Microsoft в борьбе с Java — там его так вылизывают, переписывают и полируют, что от самого электрона, там только одно название.
vladbarcelo
22.10.2018 13:41от самого электрона, там только одно название
VSCode на 90% написан на TS/JS, а не на нативщине.
river-fall
22.10.2018 14:22Помню, мы смеялись над Delphi 7, когда программа без кода с одним пустым окном интерфейса в скомпилированном виде занимала 500 килобайт.
Прошло 15 лет, и вот результат.0xf0a00
22.10.2018 15:44+2При этом «плохой» Delphi хоронят ежедневно, зато «хороший» JS (Electon) цветет и пахнет.
achekalin
22.10.2018 14:44Мне всегда «нравились» компании, выпускающие жутко неоптимальный софт, со словами: «а чего его оптимизировать, юзеры и так пользуются!»
Банально: то, что Slack висит в виде десктоп-клиента на каждой машине команды разработчиков, и жрет как не в себя — команду Slack не волнует?DracoL1ch
22.10.2018 17:50Пока разработчики сидят в слаке, слаку это волновать не будет. Вот если ВДРУГ начнется миграция на какой-то новый клиент, тогда и зашевелятся. Все гиганты такие, ВСЕ.
achekalin
22.10.2018 17:59Тут все упирается в то самое «а куда пойти?»
Другое дело что разработчики слаки, вероятно, в слаке же и сидят. Получается, «плачут, колются, но продолжаютпотреблять кактуссидеть в слаке»?DracoL1ch
22.10.2018 18:09Конкурентов нет, потому что рынок перенасыщен однотипными решениями, а разрабатывать что-то не из электрона могут себе позволить лишь ооочень богатые стартапы. Которым этот рынок уже слабо интересен, по первой причине.
Ну и проблем у разработчиков, я уверен, нет. Как те посты одного из разработчиков (или просто хорошего тестера) Chromium — habr.com/post/420579 habr.com/post/421153
Пока оптимизация стоит дороже плашки памяти — картина меняться не будет. Только голосование ногами, только хардкор. Скайп до сих пор остается корпоративным решением, потому что он у всех есть, а не потому что он хороший. Аналогичное зависание может постичь и слак, поэтому все спокойны.
k12th
22.10.2018 15:53Ни в коем случае не оправдываю прожорливость слака, но вот что меня удивляет — стремление инсталлировать себе в систему всякую ерунду. Что там такого есть в чатиках, какая такая функциональность, что надо ставить приложение? Что такого умеет десктопный электрон, чего нету в веб-версиях? Нотификации блимкают, гифки в #offtop крутятся, мессаги отправляются. Давайте еще джиру в webview завернем, а чо.
kuraga333
22.10.2018 17:00Почти по теме: Если приложение «течет», то не факт, что именно его, или языка, разработчики виноваты: sourceware.org/bugzilla/show_bug.cgi?id=14827. Да, да. И буду признателен, если подскажете, как привлечь к этому внимание.
А совсем по теме, ИМХО: разделяйте: JS, W3C APIs, browser's VM. Здесь ругают только последнее, вроде. Хотя и первые двое не идеальны, но все же — разделяйте!
Alex_ME
22.10.2018 17:44Мне тоже не нравится электрон, и, иногда смотря на современные тенденции, мне хочется горько произнести "что же с нами стало?". котэ
Но вот какие есть кроссплатформенные UI, пусть для windows/linux/mac (мобилки в расчет не берем, это целый отдельный мир)? Qt (есть биндинги к другим языкам, например pyqt), GTK (тоже есть биндинги, например GTK#), JavaFX, Swing, Mono WinForms, Avalonia (хоть и сырая). Тысячи их.
yuriyg_ua
22.10.2018 19:57Почему-то все стали обсуждать JS vs. Qt/Delphi/C#/Java как-то забывая, что, основная проблема не JS и не в Electron, а еще один инстанс Хрома. Главное преимущество JS в том, что в нынешних реалиях, браузер (а следовательно и JS) есть практически на любой платформе, чего не скажешь ни о Windows, ни о .Net, ни о JVM. Но это разумеется относится к UI. Поэтому, как только найдут решение как запускать JS приложение отдельным клиентом без дополнительной нагрузки в виде целого браузера (или же в Гугле что-то сделают с Хромом, т.к. будет расти количество приложений, использующих его) — пафос таких статей станет ненужным. Но когда это произойдет — это тот еще вопрос.
serf
22.10.2018 21:35Что-то странное пишете. Сам JS/движок запускается в виде node.js процесса (main process), то есть как раз «без дополнительной нагрузки в виде целого браузера». А вот уже UI часть требует браузера, потому что как ни странно UI это HTML страница отображением которой как раз браузер и должен заниматься.
yuriyg_ua
23.10.2018 11:19Т.е. вы предполагаете, что основную нагрузку создает на память нод процесс, а не браузерный? Очень сильно сомневаюсь, если не сказать больше.
serf
23.10.2018 11:25В моем комментарии никаких предположений нет, но есть указание на то что JS приложения и UI приложения это разные вещи. Нодовский JS процесс это относительно легковесная штука, при этом очевидно что UI процесс отвещающий за ренеринг HTML очевидно тяжелый как и сами браузеры тк это и есть по сути браузер. На самом деле никто не запрещает делать приложения на Electron без окон, то есть только с main процессом.
Alex_ME
22.10.2018 23:05Главное преимущество JS в том, что в нынешних реалиях, браузер (а следовательно и JS) есть практически на любой платформе
Поэтому, как только найдут решение как запускать JS приложение отдельным клиентом без дополнительной нагрузки в виде целого браузераНо ведь вы только что назвали (и верно) такое важное преимущество JS, как то, что браузер уже скорее всего установлен. Так зачем изобретать костыльный велосипед для запуска JS без браузера, когда есть браузер? Просто запускайте приложение в браузере, не скачивая и не запуская отдельный инстанс.
yuriyg_ua
23.10.2018 11:23Да, всё правильно. Но использование браузеров, как кросс-платформенного UI предполагает, что браузер уже запущен, и ваше приложение, как бы дополнительно запускается внутри данного инстанса. Если же для каждого приложения будет новый инстанс браузера — то это уже будет слишком. А вот когда таких приложений станет слишком много, то командам браузеров придется над этим задуматься и выпускать или легковесные варианты, либо же делать так, что такие приложение будут запускаться как бы «внутри» текущего инстанса браузера и не поднимать много разной ерунды для каждого инстанса. Но это только благие пожелание, наверняка всё ограничится тем, что «да, добавьте памяти».
PsyHaSTe
23.10.2018 13:18Это немного поможет потреблению памяти (60мб на процесс, полагаю), но гигабайты не вернет, и производительность будет примерно такая же. Зато если условный «слак» в такой архитектуре зависнет, как это часто бывает, то он может утянуть с собой все электроны и браузер с вкладками в придачу.
serf
22.10.2018 21:31+2Зачем сразу годную технологию хоронить, может просто дело в криворукости разработчиков десктоп клиента Slack. Посмотрите на Visual Studio Code, тормазит? У меня вот сейчас есть проект на котором местами WebStorm очень тормазит и зависает даже, а Visual Studio Code все пережевывает без заминок, летает просто.
vitaliy2
22.10.2018 23:56В статье сказано про JS, но JS не ест много памяти и не тормозит процессор. Да, инстанс действительно ест ~50 МБ памяти, но это далеко от указанного в статье гигабайта. Я потом напишу статью про это. Если вкратце, заставить потребить js много памяти практически нереально, если по крайней мере вы понимаете что делаете, а не новичок в языке.
А высокое потребление именно из-за инстанса браузера, HTML и встроенных технологий. С потребление процессора — скорее всего, разработчики программы что-то сделали не так. Если у нас нет задач, мы просто по идее должны спать до прерывания/окончания sleep.
Для сравнения, я пишу страничку (понимать как очень сложное веб-приложение), в которой js ест несколько мегабайт. Но в итоге при реальном открытии браузер может требовать и несколько сот мегабайт. Сделать что-то с этим нереально — твой код ест всего лишь несколько мегабайт. Дело не в js.
vitaliy2
23.10.2018 00:01В статье сказано про JS, но JS не ест много памяти и не тормозит процессор. Да, инстанс действительно ест ~50 МБ памяти, но это далеко от указанного в статье гигабайта. Я потом напишу статью про это. Если вкратце, заставить потребить js много памяти практически нереально, если по крайней мере вы понимаете что делаете, а не новичок в языке.
А высокое потребление именно из-за инстанса браузера, HTML (DOM, рендеринга и пр.) и встроенных технологий. С потребление процессора — скорее всего, разработчики программы что-то сделали не так. Если у нас нет задач, мы просто по идее должны спать до прерывания/окончания sleep.
Для сравнения, я пишу страничку (понимать как очень сложное веб-приложение), в которой js ест несколько мегабайт. Но в итоге при реальном открытии браузер может требовать и несколько сот мегабайт. Сделать что-то с этим нереально — твой код ест всего лишь несколько мегабайт. Дело не в js.
И да, кто считает, что дело в анимациях — нет, не в них. Они как раз работают быстро, т.?к. ускоряются видеокартой.Massacre
23.10.2018 05:26В статье сказано про Electron, это всё вместе, включая инстанс браузера. Вот если будут писать совсем standalone GUI софт на JS, без браузера, HTML и DOM… А пока что проблема комплексная.
Methos
23.10.2018 09:46-2давайте уж сразу вернемся к ассемблеру!
ну я начинал с асма, да.
страдал по поводу скорости и размеру, писал микропрограммы.
а толк?
все равно пришло время js и быстрой разработки
мне кажется, проблема в коде и разработчике, а не в технологии
если кодер не умеет оптимизировать, ему ничто не поможет
Splo1ter
23.10.2018 10:26+1Да хоть заоптимизируйся, так же скорости как в C/C++ не будет. К тому же всякого извиняюсь за выражения всякого г*на с собой тянуть незачем. Ладно бы еще можно было отключать api которые не нужно. Печально все это, когда в угоду бизнеса страдают конечные пользователи из за того что приложение написано на js и отжирает память (привет Slack).
Methos
23.10.2018 12:58-2вы наверное живете в каменном веке
свой ноут я купил в 2011, тогда купил и поставил 16 гигов памяти, недорого это стоило
ноут летает, памяти дохрена
сейчас, 7 лет спустя, не знаю что там на рынке ноутов, не слежу, ибо не нужно, ноут прекрасно работает, но догадываюсь, что наверняка уже по 32 или 64 гигов у всех
32 гига это ужас сколько памяти и стоит наверное копейки и если на ней запускать волковкоммандер в 64 кб, то наверное да, лишняя…
но на дворе вроде 2018 и отчего бы эту память не загрузить то?PsyHaSTe
23.10.2018 13:22+316 гигов памяти в 2011 году? Не знаю как вы, а я только в 2015 году себе купил комп с 16 гб на вырост. У большинства друзей до сих пор 4..8 гигов памяти, и на всё хватает (браузер/игрушки/...). Видимо как раз потому, что они не пользуются дома никакими электрон поделками. Скайп, телеграм, игрушки,…
Это не смешно, что установленные герои меча и магии со всей музыкой и ресурсами весит 700 мегабайт, столько же, сколько весит один только гмейл, и это в несколько раз меньше, чем слаки всякие… Неужели эта игра настолько проще, чем показать переписку с датами и рюшечками?sentyaev
23.10.2018 14:05Неужели эта игра настолько проще, чем показать переписку с датами и рюшечками?
Разве это не очевидно?
daggert
23.10.2018 14:24но догадываюсь, что наверняка уже по 32 или 64 гигов у всех
Более 4 гигов редко встречаются у обычных людей. Кроме того еще 2 в ходу. Надеюсь вы не разработчик сайтов или SPA? Ну или хотя-б тестите свои работы на планшетах с 2 гигами оперативки и атомом?
32 гига это ужас сколько памяти и стоит наверное копейки
Ну если для вас это копейки… прикупите мне пару планок кингстона на 16? для меня 32 гига DDR3 прикупить сложно финансово даже за пару месяцев.
Massacre
23.10.2018 13:06+1Время быстрой разработки пришло ещё с Delphi, а JS на десктопе сейчас никакие оптимизации не помогут, да. Разве что случится чудо и он станет компилируемым в нативный код и перестанет требовать браузер в качестве движка.
nedden
23.10.2018 10:43Вы забываете, что можно сделать кастомную сборку Electron, засунув туда кастомную сборку chromium, из которого можно выкинуть много лишнего.
Alexey2005
23.10.2018 15:39Часть проблемы заключается ещё и в том, что на данный момент попросту нет вменяемого нативного GUI. Единственное, что хоть как-то может претендовать на это звание — Qt, с которым вы вместо программирования будете заниматься трахотнёй со сборками и зависимостями. И где даже просто перенести проект на другую машину и заставить там собираться, особенно если перенос пойдёт транзитом через Github, то ещё удовольствие.
Нужна нормальная кросс-платформенная GUI-библиотека в стиле Delphi VCL, только под все платформы. Именно библиотека, из которой линкер сможет извлечь в бинарник только реально исполняемый код, а не убогий фреймворк, где в бинарник улетит всё вплоть до драйвера XBox и реально исполняемого кода будет хорошо если 1%.
Да что GUI, даже вменяемой кросс-платформенной TUI-библиотеки всемирный программерский гений так и не родил. Как-то вдруг выяснилось, что мол «консоль винды не умеет в цвет и всё сложно», в Linux «проблемы с зависимостями и всё сложно», а под Android просто «всё сложно».
И именно в этом заключается один из основных факторов популярности Electron. Потому что это единственное GUI, которое просто, блин, работает на всех платформах. Которое реально кроссплатформенное. Для которого по щелчку пальцев через npm подтягивается что угодно, а не как во всяких C++, где работа с зависимостями как бы не напряжнее собственно программирования.0xd34df00d
23.10.2018 16:48Единственное, что хоть как-то может претендовать на это звание — Qt, с которым вы вместо программирования будете заниматься трахотнёй со сборками и зависимостями.
А в чём проблема? Прописываете зависимости в CMakeLists.txt, и всё.
Alexey2005
23.10.2018 17:27Ну пока программирование идёт только под одну платформу, всё более-менее. А вот теперь представьте, что вы программируете в среде Linux, но вам требуется, чтобы при нажатии на кнопку «Build all» собирались бинарники ещё и под винду, под Android и под операционки от Apple. Вот тут-то и начинаются проблемы…
А теперь ваш коллега тоже хочет поработать над проектом, и клонит его с Github'а. Но вот незадача — он сидит под виндою и тоже хочет, чтоб из-под винды собирались бинарники под всё сразу…
И вот тут-то сразу начинаешь мечтать если не об Electron'е, то о чём угодно, лишь бы это был не C++ с его охрененно «удобными» кросс-компиляцией, системой сборки и менеджментом зависимостей. Сразу возникают ассоциации с древним авто, где вы больше времени проводите под машиной, чем в машине.0xd34df00d
23.10.2018 19:08Я б CI/CD настроил в любом случае. Неправильно это, деплоить нажатием кнопки Build all.
И вот тут-то сразу начинаешь мечтать если не об Electron'е, то о чём угодно, лишь бы это был не C++ с его охрененно «удобными» кросс-компиляцией, системой сборки и менеджментом зависимостей.
В C++ нет систем сборк и менеджмента зависимостей. А если у вас программа зависит только от Qt, то особых проблем не будет.
Это просто плата за производительность и нативность. Ну и немножко легаси, да, увы.
sentyaev
23.10.2018 19:57А если у вас программа зависит только от Qt
То скорее всего такая программа ничего интересного не делает. /sarcasm
0xf0a00
24.10.2018 13:02В Delphi последних так можно. Кроме линуксового десктопа. А так я лично один и тот же проект собирал под винду, под мак и под адроид. Был бы айфон, еще бы и на него собрал.
PurpleTentacle
23.10.2018 16:48+2Сравнение с Flash не совсем корректно. Шикарную технологию Флэш (предсказуемость и отсутствие проблем на любых платформах, аппаратное ускорение графики, мощный язык с версии AS3, богатые возможности мультимедиа, высокая скорость исполнения, модули, крохотный размер SWF и пр.) убило специфическое сочетание факторов на рынке: 1. Поглощение гигантом Adobe оригинального производителя Macromedia и потеря интереса к чужому продукту 2. Повсеместное использование флэша в интернет-рекламе стало синонимом баннеров (никто не верил, что баннеры на «быстром» html5 с обвязкой jquery будут жрать ресурсы куда больше скромного отключаемого плагина с единственным обращением к серверу за SWF-кой) 3. Как следствие пункта 1 в Adobe забили на оптимизацию флэша и после переговоров Джобс принял решение не поддерживать флэш на iOS, что вызвало цепную реакцию.
Как бывший разработчик игрушек на флэш я очень скорблю по временам, когда была простая крутая платформа Fash/Flex с богатейшими возможностями и кучей средств разработки для инди-разработчиков на рынке. Ненависть к Флэшу поддерживали в основном те, кто сейчас хэйтят php и jQuery – людям кажется, что повышение планки входа в технологию автоматически уменьшит число говнокодеров, что никак не мешает адовым тормозам «настоящих» систем на JAVA и .NET и гифкам по 30 МБ. Да хоть нативный ASM сделайте в браузере, десять анимированных баннеров + аналитика + выезжающие «мы вам перезвоним» убьют любую производительность. А виноват флеш. А до него были виноваты во всём апплеты Java, их восторженно выпилили, и для криптографии клиент-банков настали весёлые времена. В Hetzner управление их KVM до сих пор требует Java в браузере.
А в итоге для кучи кейсов применения, аналогов Флешу как не было, так и нет. Например, нормальный плеер стрима видео с мероприятия, которые требует реакции без задержек, написать на HTML5+JS в 2018 году без плясок с бубнами невозможно. Те же он-лайн аукционы, казино и игры, требующие видеопотока без тормозов. Когда у вас в стриминге видео между словами ведущего «десять тысяч евро РАЗ» и реакцией покупателя плавающая задержка в 3-7 секунд, вас покупатели матом пошлют нахрен за такой сервис. И им не объяснишь, что в их браузере нет нормальных средств, чтобы видеопоток не тормозил. Показывают, как работает сайт конкурентов из Европы, а там у них БАБАХ – Firefox с выключений безопасностью и в нём флеш-плеер видео. В 2018 году. Так и живём. Те же COUB'ы без флеша это больная боль из-за невозможности нормально загрузить и синхронизировать медиапотоки.JC_IIB
23.10.2018 16:54Как бывший разработчик игрушек на флэш я очень скорблю по временам, когда была простая крутая платформа Fash/Flex с богатейшими возможностями и кучей средств разработки для инди-разработчиков на рынке
Многие годы назад я чисто из интереса покуривал эту тему — FGL, вот это все. Ребята, писавшие на флэше, нормально так денег рубили, были оригиналы, получавшие, бывало и 10К баксов за одну игру. Ну это если верить прохладным историям из сети :)PurpleTentacle
23.10.2018 17:32На флеше была даже низкоуровневая обработка растра с доступом к пикселям. Это позволяло вообще забить на встроенный векторный движок и делать всю игру по-олдскульному, битмапами, применяя к ним разные интересные эффекты. Тормоза графики исчезали просто как класс. А встроенная обработка xml, mp3, сетевых протоколов… Это же просто мечта инди. Все усилия шли в код логики и оптимизацию, а не в выяснения сутками того, почему на платформе X у клиента нет соединения с сервером Y.
JC_IIB
23.10.2018 17:38Ну сейчас вроде инди на Unity фигачат. Я сам далек от темы Юнити и геймдева в общем, так что не знаю, хорошо ли, плохо ли это.
AquiHostStrider
24.10.2018 14:2323 абзаца текста (или 24?) — это очень много и долго читать. Поэтому статью можно сжать до одного предложения:
Slack — дерьмо для лохов, Electron не нужен.
Смысл не потерялся.
CuamckuyKot
Совершенно справедливая статья.
Многие восхищаются Electron, но не думаю о цене, которую приходиться платить пользователям за удобство разработчиков.
Dimash2
Те, кто говорят Электрону нет, писали ли софт под Электрон? Я придерживаюсь мнения, что тормоза из-за самой реализации кода на JS, от неумения или не желания балансировать с рендерингом и запросами. А то, что покдачивается весь Электрон, ну с другой стороны и всякие NET Framework-и тоже подкачиваются.
И хотел бы добавить про Оперативку, многие говорят, что типа JS — Браузер сам мусор убирает, потому память и растет, ну он очистит ее, но разработчики на самом деле могут предопределить количество нужной памяти, создав массив, в который бы сохраняли что хотели, а потом сами бы очищали. Грубо говоря, если вы хотите экономить оперативку и чаще ререндерить, то вы можете завести массив, к примеру из 20 ячеек и постоянно их переписывать актуальными данными для рендеринга, тогда сохраните оперативку, но нужно ли это )
Я так делал, когда для 4 айпада писал на JS интерактивную книгу на 100+ страниц (PDF трансформировался в PNG и накладывались звуковые и анимационные эффекты), так как на Айпаде было мало оперативки, а JS и Webview прожорливые — можете представить, но я справился. Считаю Электрон — удачная платформа, а Slack — не самый качественный софт. В тоже время мне не нравится React (субьективно), предпочитал EmberJS, сейчас на свежем Angular.
kalininmr
хром даже пустой прилично кушает. а память, как верно сказано — весьма не резиновая
pesh1983
Пожалейте своих пользователей, не пишите приложения на JS под мобильные устройства. Это тормозит, выглядит, как сайт в браузере и занимает неприлично много памяти. Это я вам как пользователь таких приложений говорю. Пользуюсь, потому что по работе надо.
Simplevolk
На это и расчет: вы не можете отказаться…
Sabubu
Вообще, это известный факт: в языках со сборкой мусора потребление памяти будет выше. Так как сборка обычно производится при достижении какого-то порога, а не постоянно. Но зато не надо тратить время на ручное управление и исключены всякие неприятные ошибки типа use-after-free.
amarao
В хороших языках нет обязательного ручного управления памяти и нет конкурентного GC, и ошибок вида use-after-free тоже нет. Привет, Rust.
PsyHaSTe
В хороших языках со сборкой мусора тоже не будет потребления памяти выше, потому что те же JVM/CLR не пытаются целый браузерный мир эмулировать.
Я не знаю, как надо считать, чтобы приложение на Electron у человека ело меньше, чем аналог на каком-нибудь Avalonia.
GrigoryPerepechko
>> В хороших языках со сборкой мусора тоже не будет потребления памяти выше
Будет и в разы. Но конечно не так сильно как с браузером.
0xd34df00d
Значит, будет выше потребление CPU.
Баланс между потреблением памяти и процессора для gc — давно известный факт в теории этих самых gc.
PsyHaSTe
Я сравнивал с cromium, а не с нативными языками, что из контекста должно было быть понятно. Прошу прощения, если криво написал.
dimaaan
NickyX3
Хаха, я тут видел одну поделку, назовем её «видеословарь». Так вот. В Win7 оно потянуло какой-то .net на полтора гига + захотело ms sql server express, потому что данные были типа в базе. И запускалось через раз даже после всего этого. Угробищность UI я вообще передать не смогу. Ну и понятно, на XP оно вообще не работало. От слова совсем.
Переделанный на nwjs вариант запускается везде, начиная от XP, кончая OS X. Ах, да, еще и на сайте работает на той же кодовой базе. Хотя там ее собственно 50 строк
dimaaan
Ну и какие выводы я должен сделать из этой истории?
NickyX3
Ну наверное, что не всегда .NET и вот это все бывает так хорошо
dimaaan
А я нигде не писал что .Net всегда хорошо, и даже что Электрон это всегда хорошо.
Я лишь пытался донести до человека, что можно сделать на нем компактное приложение под винду, которое не требует ничего предустановленного
NickyX3
Ну извините, мне показалось «восхваление .net»
PsyHaSTe
Это история про то, как кто-то взял микроскоп забивать гвозди, уж извините.
Во-первых .Net есть предустановленный.
Во-вторых .Net ставится один раз, как какой-нибудь DirectX или C++ Redistrutable. Нет ведь проблем с установкой игр из стима, которые требуют версии от 2008 до 2016 включительно?
В-третьих если у вас стоят AMD/NVidia драйверы, то наверняка у вас и их маркетингова тулза типа Experience стоит, что тоже доказывает, что можно писать удобные Net-приложения, которые ничего не выкачивают и просто работают.
NickyX3
Читайте ниже.
Какие-то не очень адекватные (с моей точки зрения) люди, сваяли продукт «на коленке». Используя для этого вот эти вот ваши MS технологии.
Другие люди, ЦА этого продукта и в некотором роде заказчики, попросили меня посмотреть что получилось. Ибо никто из получивших DVD с этой поделкой не смог его запустить и посмотреть.
Ввиду того, что у меня OS X, мне пришлось поставить в Parallels чистую Win7 Pro SP1. При установки продукта было предложено скачать и установить какие-то части .Net/C++ Redistrutable/MS SQL Server Express, что в сумме и набежало гиг-полтора со всеми сопутствующими обновлениями. Под WinXP оно так и не завелось.
Я не говорю, что .net это плохо, плохо то, что не все могут его использовать правильно. И данный пример лишь иллюстрирует, что и на .net можно написать гигантский кусок говна.
PsyHaSTe
s/.net/%techstackname% :)
Понятное дело, что серебрянной пули нет и сделать хрень можно на чем угодно.
imanushin
.Net 4.7.2 весит 80 Мб. Причем это самый новый из всех .Net'ов.
А можете дать ссылку на тот .Net в 1.5 Гб?
boblenin
Возможно это субъективное восприятие автора комментария. Во времена XP до первого сервиспака выкачивание 80мб с теми скоростями интернета было куда более серьезным испытанием чем 1.5Гб сегодня.
Вот кстати Volkov Commander занимал 64кб, а сколько будет весить его аналог на Electron или на .NET?
Fesor
Вы же понимаете что все эти электроны нужны тогда, когда у вас UI не текстовый?
boblenin
Не очень понял. На мой вкус по количеству графических элементов тот же VC не сильно отличается от VSCode или тот же centericq от slack.
Fesor
> На мой вкус
Это очень субьективно, если сравнивать vscode и какой-нибудь neovim + tmux то в целом я может быть и согласился бы что различия несуществественны, но вот слэк с стерминалом сравнивать…
По сути, вы либо слэком не пользуетесь (к слову, пользуетесь ли?) либо у вас очень интересные вкусы. Нет, если вы представите концепт того как слэк в терминале сделать — мне будет любопытно (даже очень). Повторюсь — слэк это не только чатики.
boblenin
Слаком { \?slak \ } увы пользуюсь — корпоративный стандарт. А вы пользовались centericq?
Да ради бога. В придачу поиск и медиаконент. Посмотрите на Far с conemu. Вы все еще считаете что гигабайт оперативки не перебор, даже с учетом всех ваших киллер-фич?
Politura
Там, скорее всего, инсталлер всех этих якобы бесплатных говнопрограмм, которые вместе с собой ставят всякие браузеры амиго, оптимизаторы винды и прочий сброд, никакого отношения все это к дотнету не имеет.
NickyX3
Там еще всякие SQL Server Express и все остальное, я не знаю на чем и как это было написано, что система предлагала скачать для запуска, то и качалось.
Ставилось на чистую Win 7 Pro SP1
imanushin
А причем тут .Net тогда? Для UI-only приложений достаточно .Net. Просто этому продукту требуется серьезная база данных (SQLite недостаточно).
NickyX3
Этому приложению не требовалась никакая серьезная база, да и вообще база.
Повторюсь — сейчас это так же «на коленке» для теста собрано мной на nwjs (тот же Electron, вид сбоку). Данные вообще в json в файлике лежат. И 50 строк универсального кода, работающего как под node, так и в чистом браузере с web-сервера. И при этом сборка под XP/Win7+/OS X вообще без проблем
Politura
Левое приложение, которому не требуется база, устанавливает SQL Server Express, который не имеет никакого отношения к дотнету, но во всем у вас дотнет виноват. Почему именно он, а не ящирики с планеты Нибиру?
NickyX3
Использование базы просто потому, что те, кто делал приложение сделали так. Я не знаю почему. Само приложение на .net. Выглядит как поделка левой пяткой секретарши.
PsyHaSTe
Что мешало Sql Server Express использовать в приложении на C++? Java?
imanushin
А что это за приложение такое, приведите ссылку, пожалуйста? Я не спорю, что иногда разработчики тянут ненужное, но чтобы устанавливать базу и не использовать — это что-то новое.
И непонятно, что вы отстаиваете? .Net весит немного, тут мы согласились. Если есть какая-то задача решается в 50 строчек на JS и требует аж целой базы на .Net — я с радостью бы посмотрел на неё, так как попахивает вымыслом.
Если же вы хотите сказать, что некоторые разработчики устанавливают много всего на комп — ну так Politura объяснил выше как минимум одну причину. Так Google Chrome изначально распространялся, т.е. Adobe Flash устанавливал этот самый хром, если не убрать галку.
NickyX3
Имелось ввиду, что приложение, изначально написанное на MS технологиях под Windows на .net использовало для своих данных базу MS SQL Express или как там ее. По факту оно запустилось только под Win7+ путем установки еще пачки софта. Ссылки не будет, оно давно стерто у меня, да и в интернет не выкладывалось. Я его получил на dvd чисто оценить и попробовать и принять решение, что так не годится и подумать над другими вариантами.
Мой быстрый прототип на 50 строчек js кода + html конечно никакую базу не использовал. Тупо грузится json и этого достаточно. Суть показать список слов-терминов и показать видео для каждого.
Politura
То есть вы по какому-то непонятному приложению, неизвесто кем и с какой целью написаному судите по всему дотнету. Дайте тогда уж оценку качеству всех веб-технологий вот по этому сайту, припример: www.constellation7.org/Constellation-Seven/Josiah/Index.htm (не знаю что это, гуглил уродливые сайты).
С большой долей вероятности то, что вы сделали на электроне в 50 строчек js кода можно сделать под дотнет со сравнимым количеством строчек кода и получить приложение, которое будет занимать десятки килобайт и работать на всех Windows начиная с XP с третьим сервис паком и заканчивая самой последней 10-кой без каких либо доустанавливаний чего-нибудь еще. Просто запускаете экзешник в десятки килобайт и он работает. Ну да, будет стандартный windows-интерфейс, если нужны будут украшательства, за счет картинок и прочего размер наверняка вырастет, но врядли будет больше сотен килобайт.
Simplevolk
Не, просто он на 50 строчек кода набросал прототип, ну и фигня ваш дотнет.
А если бы начал пилить уже полноценное приложение, тот тут был бы и электрон и БД какая-нибудь.
stavinsky
Насчет полтора гигабайта это конечно вопрос. Но в целом мне помнится (могу ошибаться) раньше дотнет надо было качать последовательно. На ту же XP. Просто 4й скажет что нужен 3й итд. Может отсюда и большие объемы? не берусь утверждать. Лет 5 сижу на маке. Дотнет вижу только когда время от времени пытаюсь родной keepass запустить на mono
ExplosiveZ
github.com/keepassxreboot/keepassxc
ValdikSS
А я пользуюсь HEX-редактором Bless, написанным на C# + GTK+. Запускается почти моментально, mono потребляет 17 мегабайт RAM, а сам bless — 200 кбайт.