Electron это Flash для десктопа +150


Почему в настольном приложении Slack, скорее всего, есть драйвер для работы игрового контроллера Xbox и чего, действительно, плохого в использовании Electron для построения настольных приложений.

image

На скриншоте ниже, согласно профайлеру, Slack занимает почти все ресурсы процессора. Интересно, чем это он там занимается?

image

Процесс был запущен в фоне когда это произошло. Я даже не взаимодействовал со 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 Гб в памяти моего ноутбука:

image

Come on. Это приложение для обмена текстом.

Другая вещь, которой всегда не хватает — заряд батареи. Современные процессоры сохраняют заряд путём остановки когда это возможно (когда нет никаких задач). Проклятие power management это программы, которые постоянно используют процессор всего на пару процентов. Они заставляют процессор постоянно просыпаться, разгоняться и снова останавливаться. Это идеальный способ уничтожить драгоценный заряд батареи. Если у кого-то есть время (просто оставьте их запущенными) — я бы посмотрел как сильно Spotify, Slack и Atom уменьшают время работы от батареи на современных ноутбуках. Это невероятно.

image

И нет, 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):

  1. CuamckuyKot
    /#19263311 / +3

    Совершенно справедливая статья.

    Многие восхищаются Electron, но не думаю о цене, которую приходиться платить пользователям за удобство разработчиков.

    • Dimash2
      /#19263447 / -1

      Те, кто говорят Электрону нет, писали ли софт под Электрон? Я придерживаюсь мнения, что тормоза из-за самой реализации кода на JS, от неумения или не желания балансировать с рендерингом и запросами. А то, что покдачивается весь Электрон, ну с другой стороны и всякие NET Framework-и тоже подкачиваются.

      И хотел бы добавить про Оперативку, многие говорят, что типа JS — Браузер сам мусор убирает, потому память и растет, ну он очистит ее, но разработчики на самом деле могут предопределить количество нужной памяти, создав массив, в который бы сохраняли что хотели, а потом сами бы очищали. Грубо говоря, если вы хотите экономить оперативку и чаще ререндерить, то вы можете завести массив, к примеру из 20 ячеек и постоянно их переписывать актуальными данными для рендеринга, тогда сохраните оперативку, но нужно ли это )

      Я так делал, когда для 4 айпада писал на JS интерактивную книгу на 100+ страниц (PDF трансформировался в PNG и накладывались звуковые и анимационные эффекты), так как на Айпаде было мало оперативки, а JS и Webview прожорливые — можете представить, но я справился. Считаю Электрон — удачная платформа, а Slack — не самый качественный софт. В тоже время мне не нравится React (субьективно), предпочитал EmberJS, сейчас на свежем Angular.

      • kalininmr
        /#19263495 / +2

        хром даже пустой прилично кушает. а память, как верно сказано — весьма не резиновая

      • pesh1983
        /#19264299

        Пожалейте своих пользователей, не пишите приложения на JS под мобильные устройства. Это тормозит, выглядит, как сайт в браузере и занимает неприлично много памяти. Это я вам как пользователь таких приложений говорю. Пользуюсь, потому что по работе надо.

        • Simplevolk
          /#19264453

          На это и расчет: вы не можете отказаться…

      • Sabubu
        /#19265149

        Вообще, это известный факт: в языках со сборкой мусора потребление памяти будет выше. Так как сборка обычно производится при достижении какого-то порога, а не постоянно. Но зато не надо тратить время на ручное управление и исключены всякие неприятные ошибки типа use-after-free.

        • amarao
          /#19265559 / +2

          В хороших языках нет обязательного ручного управления памяти и нет конкурентного GC, и ошибок вида use-after-free тоже нет. Привет, Rust.

          • PsyHaSTe
            /#19265855 / +1

            В хороших языках со сборкой мусора тоже не будет потребления памяти выше, потому что те же JVM/CLR не пытаются целый браузерный мир эмулировать.

            Я не знаю, как надо считать, чтобы приложение на Electron у человека ело меньше, чем аналог на каком-нибудь Avalonia.

            • GrigoryPerepechko
              /#19265949

              >> В хороших языках со сборкой мусора тоже не будет потребления памяти выше
              Будет и в разы. Но конечно не так сильно как с браузером.

            • 0xd34df00d
              /#19266837 / +4

              Значит, будет выше потребление CPU.

              Баланс между потреблением памяти и процессора для gc — давно известный факт в теории этих самых gc.

              • PsyHaSTe
                /#19270283

                Я сравнивал с cromium, а не с нативными языками, что из контекста должно было быть понятно. Прошу прощения, если криво написал.

      • dimaaan
        /#19266805 / +4

        А то, что покдачивается весь Электрон, ну с другой стороны и всякие NET Framework-и тоже подкачиваются.

        1. Необязательно. .Net Framework предустанавливается в ОС начиная с WindowsXP SP1. Если, например, в минимальных требованиях Windows 7, можно использовать .NET Framework 3.5.1. Приложения получаются очень компактные (например, окно с надписью Hello world на WPF — 4 кб)
        2. Все приложения .net разделяют общий фреймворк, а каждое Electron приложение включает в себя свой собственный инстанс хромиума. Отсюда разный размер и потребление памяти.
        3. Вообще сравнивать эти 2 платформы нечестно, т.к. .net framework работает только под windows (а .net core не имеет UI библиотек в составе). Кросплатформенный фреймворк всегда тяжелее нативного

        • NickyX3
          /#19267129

          Хаха, я тут видел одну поделку, назовем её «видеословарь». Так вот. В Win7 оно потянуло какой-то .net на полтора гига + захотело ms sql server express, потому что данные были типа в базе. И запускалось через раз даже после всего этого. Угробищность UI я вообще передать не смогу. Ну и понятно, на XP оно вообще не работало. От слова совсем.

          Переделанный на nwjs вариант запускается везде, начиная от XP, кончая OS X. Ах, да, еще и на сайте работает на той же кодовой базе. Хотя там ее собственно 50 строк

          • dimaaan
            /#19267177 / +1

            Ну и какие выводы я должен сделать из этой истории?

            • NickyX3
              /#19267269

              Ну наверное, что не всегда .NET и вот это все бывает так хорошо

              • dimaaan
                /#19267291

                А я нигде не писал что .Net всегда хорошо, и даже что Электрон это всегда хорошо.
                Я лишь пытался донести до человека, что можно сделать на нем компактное приложение под винду, которое не требует ничего предустановленного

                • NickyX3
                  /#19267311

                  Ну извините, мне показалось «восхваление .net»

              • PsyHaSTe
                /#19270299

                Это история про то, как кто-то взял микроскоп забивать гвозди, уж извините.

                Во-первых .Net есть предустановленный.
                Во-вторых .Net ставится один раз, как какой-нибудь DirectX или C++ Redistrutable. Нет ведь проблем с установкой игр из стима, которые требуют версии от 2008 до 2016 включительно?
                В-третьих если у вас стоят AMD/NVidia драйверы, то наверняка у вас и их маркетингова тулза типа Experience стоит, что тоже доказывает, что можно писать удобные Net-приложения, которые ничего не выкачивают и просто работают.

                • NickyX3
                  /#19270725

                  Читайте ниже.
                  Какие-то не очень адекватные (с моей точки зрения) люди, сваяли продукт «на коленке». Используя для этого вот эти вот ваши MS технологии.
                  Другие люди, ЦА этого продукта и в некотором роде заказчики, попросили меня посмотреть что получилось. Ибо никто из получивших DVD с этой поделкой не смог его запустить и посмотреть.
                  Ввиду того, что у меня OS X, мне пришлось поставить в Parallels чистую Win7 Pro SP1. При установки продукта было предложено скачать и установить какие-то части .Net/C++ Redistrutable/MS SQL Server Express, что в сумме и набежало гиг-полтора со всеми сопутствующими обновлениями. Под WinXP оно так и не завелось.

                  Я не говорю, что .net это плохо, плохо то, что не все могут его использовать правильно. И данный пример лишь иллюстрирует, что и на .net можно написать гигантский кусок говна.

                  • PsyHaSTe
                    /#19270891

                    s/.net/%techstackname% :)

                    Понятное дело, что серебрянной пули нет и сделать хрень можно на чем угодно.

          • imanushin
            /#19267963

            какой-то .net на полтора гига

            .Net 4.7.2 весит 80 Мб. Причем это самый новый из всех .Net'ов.


            А можете дать ссылку на тот .Net в 1.5 Гб?

            • boblenin
              /#19268085

              Возможно это субъективное восприятие автора комментария. Во времена XP до первого сервиспака выкачивание 80мб с теми скоростями интернета было куда более серьезным испытанием чем 1.5Гб сегодня.

              Вот кстати Volkov Commander занимал 64кб, а сколько будет весить его аналог на Electron или на .NET?

              • Fesor
                /#19268235 / +1

                Вы же понимаете что все эти электроны нужны тогда, когда у вас UI не текстовый?

                • boblenin
                  /#19272321

                  Не очень понял. На мой вкус по количеству графических элементов тот же VC не сильно отличается от VSCode или тот же centericq от slack.

                  • Fesor
                    /#19275681

                    > На мой вкус

                    Это очень субьективно, если сравнивать vscode и какой-нибудь neovim + tmux то в целом я может быть и согласился бы что различия несуществественны, но вот слэк с стерминалом сравнивать…

                    По сути, вы либо слэком не пользуетесь (к слову, пользуетесь ли?) либо у вас очень интересные вкусы. Нет, если вы представите концепт того как слэк в терминале сделать — мне будет любопытно (даже очень). Повторюсь — слэк это не только чатики.

                    • boblenin
                      /#19275745

                      Слаком { \?slak \ } увы пользуюсь — корпоративный стандарт. А вы пользовались centericq?


                      Повторюсь — слэк это не только чатики.

                      Да ради бога. В придачу поиск и медиаконент. Посмотрите на Far с conemu. Вы все еще считаете что гигабайт оперативки не перебор, даже с учетом всех ваших киллер-фич?

            • Politura
              /#19268097 / +1

              Там, скорее всего, инсталлер всех этих якобы бесплатных говнопрограмм, которые вместе с собой ставят всякие браузеры амиго, оптимизаторы винды и прочий сброд, никакого отношения все это к дотнету не имеет.

            • NickyX3
              /#19268719

              Там еще всякие SQL Server Express и все остальное, я не знаю на чем и как это было написано, что система предлагала скачать для запуска, то и качалось.
              Ставилось на чистую Win 7 Pro SP1

              • imanushin
                /#19271137

                А причем тут .Net тогда? Для UI-only приложений достаточно .Net. Просто этому продукту требуется серьезная база данных (SQLite недостаточно).

                • NickyX3
                  /#19271201

                  Этому приложению не требовалась никакая серьезная база, да и вообще база.
                  Повторюсь — сейчас это так же «на коленке» для теста собрано мной на nwjs (тот же Electron, вид сбоку). Данные вообще в json в файлике лежат. И 50 строк универсального кода, работающего как под node, так и в чистом браузере с web-сервера. И при этом сборка под XP/Win7+/OS X вообще без проблем

                  • Politura
                    /#19272061 / +2

                    Этому приложению не требовалась никакая серьезная база, да и вообще база.


                    Левое приложение, которому не требуется база, устанавливает SQL Server Express, который не имеет никакого отношения к дотнету, но во всем у вас дотнет виноват. Почему именно он, а не ящирики с планеты Нибиру?

                    • NickyX3
                      /#19272151

                      Использование базы просто потому, что те, кто делал приложение сделали так. Я не знаю почему. Само приложение на .net. Выглядит как поделка левой пяткой секретарши.

                      • PsyHaSTe
                        /#19273005

                        Что мешало Sql Server Express использовать в приложении на C++? Java?

                  • imanushin
                    /#19272073

                    Этому приложению не требовалась никакая серьезная база, да и вообще база.

                    А что это за приложение такое, приведите ссылку, пожалуйста? Я не спорю, что иногда разработчики тянут ненужное, но чтобы устанавливать базу и не использовать — это что-то новое.


                    И непонятно, что вы отстаиваете? .Net весит немного, тут мы согласились. Если есть какая-то задача решается в 50 строчек на JS и требует аж целой базы на .Net — я с радостью бы посмотрел на неё, так как попахивает вымыслом.


                    Если же вы хотите сказать, что некоторые разработчики устанавливают много всего на комп — ну так Politura объяснил выше как минимум одну причину. Так Google Chrome изначально распространялся, т.е. Adobe Flash устанавливал этот самый хром, если не убрать галку.

                    • NickyX3
                      /#19272193

                      Имелось ввиду, что приложение, изначально написанное на MS технологиях под Windows на .net использовало для своих данных базу MS SQL Express или как там ее. По факту оно запустилось только под Win7+ путем установки еще пачки софта. Ссылки не будет, оно давно стерто у меня, да и в интернет не выкладывалось. Я его получил на dvd чисто оценить и попробовать и принять решение, что так не годится и подумать над другими вариантами.
                      Мой быстрый прототип на 50 строчек js кода + html конечно никакую базу не использовал. Тупо грузится json и этого достаточно. Суть показать список слов-терминов и показать видео для каждого.

                      • Politura
                        /#19272521 / +1

                        То есть вы по какому-то непонятному приложению, неизвесто кем и с какой целью написаному судите по всему дотнету. Дайте тогда уж оценку качеству всех веб-технологий вот по этому сайту, припример: www.constellation7.org/Constellation-Seven/Josiah/Index.htm (не знаю что это, гуглил уродливые сайты).

                        С большой долей вероятности то, что вы сделали на электроне в 50 строчек js кода можно сделать под дотнет со сравнимым количеством строчек кода и получить приложение, которое будет занимать десятки килобайт и работать на всех Windows начиная с XP с третьим сервис паком и заканчивая самой последней 10-кой без каких либо доустанавливаний чего-нибудь еще. Просто запускаете экзешник в десятки килобайт и он работает. Ну да, будет стандартный windows-интерфейс, если нужны будут украшательства, за счет картинок и прочего размер наверняка вырастет, но врядли будет больше сотен килобайт.

                        • Simplevolk
                          /#19273877

                          Не, просто он на 50 строчек кода набросал прототип, ну и фигня ваш дотнет.
                          А если бы начал пилить уже полноценное приложение, тот тут был бы и электрон и БД какая-нибудь.

            • stavinsky
              /#19273177

              Насчет полтора гигабайта это конечно вопрос. Но в целом мне помнится (могу ошибаться) раньше дотнет надо было качать последовательно. На ту же XP. Просто 4й скажет что нужен 3й итд. Может отсюда и большие объемы? не берусь утверждать. Лет 5 сижу на маке. Дотнет вижу только когда время от времени пытаюсь родной keepass запустить на mono

          • ValdikSS
            /#19272839

            А я пользуюсь HEX-редактором Bless, написанным на C# + GTK+. Запускается почти моментально, mono потребляет 17 мегабайт RAM, а сам bless — 200 кбайт.

  2. kaleman
    /#19263313 / +3

    15 лет пишу под винду десктопный софт, но JS-приложения для десктопа… Не могу этого понять. Зачем? То есть нафига? Это такой способ поиздеваться над пользователяли? Троллинг? Или это полноя и окончательная победа Идиократии? У меня только непонимание и одни вопросы… Наверное безнадежно я устарел. Могу написать софтинку на VCL под Дельфи, или MFC. На нелюбимом WPF под шарпы. С Qt тоже знаком. Да хоть на голом WinAPI, сделаю вам красивый UI и все будет летать со скоростью блокнота. И даже в сотню кбайт скомпилированного EXE с зависимостями только виндовых библиотек. Но эти кривые и монструозные жс приложения в сотни мегабайт. Так и хочется крикнуть — Господь жги, тут уже нечего спасать…

    • evnuh
      /#19263327 / +2

      Может быть чтобы была одна кодовая база на все популярные ОС: win, macOS, linux, iOS, Android, web?
      Это же выбор между скорость и стоимостью разработки и количеством сжираемых ресурсов железа пользователя. Кто-то готов потратиться и пожалеть юзера, кто-то не готов. Особенно это становится актуально, во времена, когда «Мы носим суперкомпьютеры в наших карманах.» Почему бы не использовать бесплатно эти суперкомпьютеры и платить за разработку только одной программы, а не пяти?

      И уж тем более глупо советовать «подите выучите С или Rust, вы, веб-разработчики». Не думаю, что Slack пишут макаки, выбор писать на веб-стеке — это осознанный выбор, а не от того, что «ничего другого не умеем».

      • LexS007
        /#19263357 / +4

        Это просто экономия, в ущерб конечным пользователям.
        Разработчики написали одну веб-версию, и вместо того что бы написать нормальный десктопный клиент, обернули вебверсию электроном, Готово.
        Для стартапа это нормально, но Slack Technologies уже зрелая компания с огромной базой корпоративных клиентов, пора и о них подумать.

        Даже не вижу смысла качать их клиент, просто держу открытую вкладку Slack в браузере.

        • evnuh
          /#19263445 / +1

          Да, это экономия в ущерб конечным пользователям. Я это и сказал. Глупо ожидать от бизнеса, что он не будет снижать затраты, когда он может их снижать. Бизнес — не альтруизм.

          • Methos
            /#19269191

            я бы не сказал что в ущерб


            чтобы написать быструю прогу, нужны ресурсы, хорошие ресурсы и время


            это намного большие деньги, чем на js


            и если например чтобы пользоваться этой прогой вам нужно заплатить 100 баксов в месяц вместо например 10, вы заплатите?

            • Simplevolk
              /#19269349

              На самом деле, в конечном счете, мы заплатим по 100 баксов, так как программа будет отъедать все больше ресурсов на разработку и поддержку. И тариф будет увеличен.
              Ну или пользователь будет вынужден заплатить 100 баксов, чтобы купить дополнительную память\процессор\итд.

              • Methos
                /#19272487

                просто все те, кто ноют, что памяти мало и скорость мала, пусть вспомнят о том, что в 1995 году были спектрумы с 64 кб памяти

                а в 2000 году (18 лет назад) pentium с непомню-уже-сколько памяти (наверное 256 Мб), и windows 98 работала на этом компе, хотя и со скрипом.

                а сейчас компы такой же мощности, если не выше, умещаются в задний карман джинсов и можно в браузере запустить виртуальную windows 98 и в автобусе ехать и работать по несколько часов =)

        • YemSalat
          /#19264071

          Вот тоже умa нe приложу — нафига все качают Слаковское приложение (по сути запускают еще один хром)??
          Веб версия же всe умеет (кроме шаринга десктопа нa видеозвонках)

          • Neikist
            /#19264155 / +1

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

            • RifleR
              /#19264325

              PWA нас всех спасет.

              • Neikist
                /#19264403

                Чем именно? Даже если будет в отдельном окне — все равно та же унылая веб фигня. Ладно дома у меня i7, ссд и 16 гигов ддр4, а на ноуте, который покупался в дополнение к пк на сумму которую не жалко, двухядерный целерон и 3 гига памяти.

                • RifleR
                  /#19264539

                  Хотя бы тем, что не будет каждое приложение тащить отдельную копию хрома, все будут работать в одном.

                  • KaneUA
                    /#19265759

                    Хром выделяет по процессу на вкладку или их группу.

                    • dimaaan
                      /#19266811 / +1

                      Нативное приложение это тоже минимум 1 процесс

            • ImKremen
              /#19264491

              Ну так можно же ярлык добавить.

              • Neikist
                /#19264513

                Эм, ярлык на что? Как будто будет открыто отдельное окно которое не будет стакаться с окном огнелиса, не будет затирать последние открытые вкладки при неправильном порядке закрытия окон и т.д.

                • ImKremen
                  /#19264671

                  Я имел ввиду PWA, но да, лиса не умеет

                • unclechu
                  /#19268467

                  В Firefox есть профили, можно параллельно запускать несколько независимых инстансов с разными профилями. Например запуская:


                  firefox --new-instance -P foo

                  Где foo — произвольное имя профиля (если такого профиля ещё нет, откроется окно с управлением профилями).


                  Каждый профиль имеет свой набор расширений и настроек браузера.

            • YemSalat
              /#19268139

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

              Мне наоборот нравится поменьше открытых программ :)
              А вкладки вроде слака/почты и т.п. я обычно делаю «Pin Tab» тогда они занимают меньше горизонтального места и их труднее нечаянно закрыть.

          • ThunderCat
            /#19265617

            Веб версия же всe умеет (кроме шаринга десктопа нa видеозвонках)

            вроде и это реализуется через расширение устанавливаемое в браузер.

          • domix32
            /#19267309

            Потому что Маки например не умеют в нормальное переключение окон одного и того же приложения, например. Только «Показать все окна». Довольно неудобно на мой взгляд.

            • cadmi
              /#19267403

              Вы сейчас про Cmd+` или про что-то другое?

              • domix32
                /#19267975

                Вероятно оно. Я обычно через ПКМ по нужному приложению щелкаю

        • warranty_voider
          /#19264909 / +1

          Это просто экономия, в ущерб конечным пользователям.

          на минуточку, Slack это коммерческое приложение. Пользование им стоит денег. Вы готовы платить в 5 раз больше, чтобы получить быстрые и качественные нативные приложения под 5 платформ? Даже сейчас у слака не самая приятная ценовая политика, а за 5х никто им не будет пользоваться вообще

          • Neikist
            /#19264965

            Да не будет оно стоить x5. Уже поясняли что расходы на дизайн, логику работы, бэкенд часть одни.

            • dimaaan
              /#19266833

              А еще общие для все клиентов части можно вынести в переиспользуемый модуль/компонент

          • Ogra
            /#19265057

            Сейчас у Слака 193 открытые вакансии: slack.com/careers#openings Из них разработчиков два-три десятка от силы. Они могут прямо сейчас нанять по десять разработчиков на каждую платформу, из-за этого цена вырастет на 2%, не больше.

        • fiftin
          /#19267271

          Не пойму почему все приводят приложение Slack как пример насколько Electron плох. Скачайте приложение Discord, оно очень крутое, сделано на том же Electron.

          • khanid
            /#19267481

            Не пользовался слаком, но пользовался дискордом. И могу сказать, что, на мой взгляд сисадмина, он тормозит. А ещё лезет по процессам, да и вообще куда не просят.

          • neit_kas
            /#19267633 / +1

            Ок, VSCode. Функционально — круто. Можно быстро поднять себе удобную IDE под любой ЯП. Поднимал под C++. Я понятия не имею, что, но томозило оно знатно. Пустым (ну, м.б. с 1-3 плагинами) пользоваться ещё можно, но чуть больше и всё.

            • Fesor
              /#19268243

              может быть тупил какой-нибудь криво написанный плагин или может быть language server для вашего языка тупил. Мало ли.

              • Ogra
                /#19268569

                А вот Sublime предлагает отключать плагины, которые тупят.

              • neit_kas
                /#19271985

                Может и так конечно, но именно по этой причине пока забросил её в долгий ящик.

          • CheatEx
            /#19269873

            4790 проц, 16 Гб, эта хрень стартует секунд 15. Телега в которой у меня в 10 раз больше групп и каналов меньше секунды.

            Каким раком дискорд попал в крутые приложения?

      • Gorthauer87
        /#19264839 / +1

        Есть Slack, а есть к примеру Discord, оба на электроне, но просто сравните скорость их работы и отзывчивость интерфейса.

        • Neikist
          /#19264873

          Я пока видел только vs code из таких приложений которым хоть как то пользоваться можно. Дискорд тоже непозволительно много ресурсов сжирал для задач которые выполняет и не сказать что быстро на слабом железе работал.

          • DmitryMry
            /#19265781

            Меня больше всего убивает скорость запуска — что того, что другого.

          • jashcka
            /#19267071

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

          • neit_kas
            /#19267653

            Я пока видел только vs code из таких приложений которым хоть как то пользоваться можно.

            Несколько плагинов в него влепи и посмотри на результат.

            • Neikist
              /#19267715

              К счастью я вовремя одумался и вернулся к более нормальным IDE (тем более что это не IDE в общем то). А если просто редактор текста нужен то есть vim который и под виндой неплохо работает.

              • neit_kas
                /#19268117

                При допиливании плагинами её вполне можно считать IDE (позиционируется, на сколько знаю, тоже как универсальная IDE): дебаггер есть, подсветка есть, автодополнение есть, что ещё надо?
                Ну, судя по всему, под линукс нормальная IDE — это та, которую собрал по сути сам (тот же Emacs). Остальное мне не зашло. Основная фишка, которая мне нравилась в VSCode и которой не было в других IDE — это кастомные команды сборки и запуска. С учётом того, что мне не зашёл ныне популярный CMake, а зашёл Premake — это было очень весомой фичей.

                • encyclopedist
                  /#19274751

                  Основная фишка, которая мне нравилась в VSCode и которой не было в других IDE — это кастомные команды сборки и запуска.

                  Это ксть в абсолютно всех IDE, которые я видел.

          • boblenin
            /#19268115

            Насколько я помню VSCode на менее чем 8Gb оперативки, даже для маленьких проектов не вариант (в отличии от того же rider который на 4gb на мелких проектах вполне выживает), т.к. когда вышло — пробовал. Может быть сейчас уже не так.

            Самое неприятное, что все эти приложения на электроне из всех сил пытаются выглядеть как будто они легковесные, а по факту — очень тяжелые решения. Ну это как если взять Ford Granada Station Vagon 1982, прикрутить спойлер, покрасить красным тормозные колодки, раскрасить кузов яркими красками и налепить стикеры а-ля ралли. Нелепо.

        • PsyHaSTe
          /#19265881

          Отвратительно у обоих — имхо.

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

          • technic93
            /#19266689

            Да телеграм напомнил мне о старых временах, когда всё работало быстро, как в старом скайпе.

          • progman_rus
            /#19267365

            Так телеграмм Программисты писали, а не «программисты»

            • MikailBag
              /#19267415

              ТГ на c++ + qt написан. Чтобы программа на плюсах тормозила, надо очень сильно постараться)

              • progman_rus
                /#19268559

                Дай «программистам» титановый шар — они и его сломают

          • bodqhrohro
            /#19267419

            Telegram теперь тоже запускается минут 10, спасибо ломающим изменениям в Fontconfig 2.13 и ихним кастомным костылями ради отображения своих эмодзи — читает мимо кэша весь /etc/fonts. И оперативку жрёт будь здоров: если в чатах с кучей картиночек и стикеров обитать, почти до гигабайта подтекает за пару дней.

            • ValdikSS
              /#19272905

              FONTCONFIG_FILE=/etc/fonts/ telegram

              • bodqhrohro
                /#19273455

                Я с этой переменной и запускал, как только поломалось — без неё окно вообще не появлялось, и вроде даже процесс в итоге крашился, точно не помню. Причём с ней тоже стартовало долго, и большая часть диапазонов Юникода отваливалась, а в файловом диалоге вообще все символы квадратиками были, даже ASCII — выбирал вслепую или копипастил из автодополнения баша. Через несколько недель случайно запустил без переменной и обнаружил, что уже и так работает, причём лучше.

        • farcaller
          /#19266119

          Discord от релиза к релизу иногда течет просто ужасно:


          • OnelaW
            /#19266365 / +2

            Ой, выколете мне глаза, веб-общалка на 1 гиг? Что она такое делает что не могут другие? Нее, это безумие нужно остановить.

            • farcaller
              /#19266397

              Очевидно же, там анимированные аватарки и магазин с играми.

              • OnelaW
                /#19266453

                А зачем магазин?

                • farcaller
                  /#19266523

                  Чтобы привлекать платных пользователей через подписку.

                  • OnelaW
                    /#19266571

                    Это такая шутка?

                    • farcaller
                      /#19266787

                      Это такой маркетинг.


                      • OnelaW
                        /#19266895 / +1

                        Ohh, sh… Даже в кошмарном сне я не мог себе такое представить.

            • jashcka
              /#19267083

              видел тех у кого тек телеграм в оперативу на 14 ГБ

            • foldr
              /#19270033

              Например, сканирует список процессов, чтобы показывать в статусе, в какую игру играет пользователь, рисовать оверлей. Плюс собирает некоторую телеметрию

            • krab90
              /#19271189

              image

              Если открыть чаты и покликать по разным каналам то поднимается и держится в пределах 130-140 МБ (зависит от количества GIF). После закрытия окна через 5 секунд потребление 94-95 под вантузом. Всего скорее сабж на скриншоте выше под macOS течет по памяти сильно. Ну оно и очевидно это же JS/Electron.

          • Fracta1L
            /#19266743

            WindowServer это что за процесс?

            • PsyHaSTe
              /#19266759

              XWindows или его аналог, вестимо.

            • farcaller
              /#19266791

              OSX'овый аналог X11

              • Fracta1L
                /#19267141

                А это нормально для Макоси, что «иксы» жрут гиг оперативки?

                • farcaller
                  /#19267171

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

      • homocomputeris
        /#19267191

        Ну, VLC и LibreOffice как-то же на разных платформах существуют.

        • staticlab
          /#19267211

          У LibreOffice свой графический тулкит для этого.

          • homocomputeris
            /#19267241

            Так не весь же код переписывать надо.

            • staticlab
              /#19267273

              Ну так они когда-то заморочились и написали его.

          • Goodkat
            /#19267381

            А LibreOffice не на джаве написан? Он такой тормозной в сравнении с MS Office, что я на джаву грешил.

            • khim
              /#19268291 / +2

              Там есть много ньюансов:
              1. В OpenOffice.org Sun долго пытался напихать кучу Java в разнае места.
              2. После того, как LibreOffice отпочковался — они её выкорчевали и интерфейс стал быстрее.
              3. Главное: с тех пор вышло много новых версий MS Office — и они стали сильно тормознее.

              Так что про стереотип «тормозной LibreOffice» стоит забыть: он и в самый момент появления (то есть отпочковывания от OpenOffice.org) не был особо тормозным, а сейчас — так и вообще «летает». В основном за счёт пункта номер 3, правда…

      • progman_rus
        /#19267355

        по большому счету С++ это уже кодовая база на win, macOS, linux, iOS, Android.
        в 99 из 100 достаточно API вызовы для каждой из платформ в обертки завернуть не затрагивая основной код.

        • neit_kas
          /#19267663 / +3

          Чистый C++ и UI — это боль. Но Qt сильно спасает.

          • boblenin
            /#19268147 / +1

            Я попробовал вспомнить варианты где бы был чистый C++ и UI. Везде либо просто C, либо какие-то препроцессоры, либо другие виды C — не C++. Разве что WTL, который и правда удовольствием не назовешь. А вы что имели в виду?

            • neit_kas
              /#19271981

              По чистым C++ с UI — я понимаю использование наиболее нативных вариантов. С Windows всё ясно: WinAPI. Под Linux не так однозначно. Наиболее нативным думаю там является XLib. И вот без какой-то монструозной штуки слабо представляю, как это можно обернуть чем-то, сделав кроссплатформенным (как описал комментатор выше).

    • AEP
      /#19263375

      Оффтоп:

      Примерно 15 лет назад читал книжки, как писать софт под Windows. Про все эти оконные процедуры, windows-сообщения, объекты ядра, и еще упоминается MFC как красивая обертка над этим делом. Потом пересел на Linux и от этого дела отстал, но чувствую, что знания надо освежить. Но вот сейчас не могу найти современных книг по Windows-разработке, которые именно про нативные приложения, и которые начинают с азов. Не посоветуете ли чего толкового?

      • quwy
        /#19263387 / +1

        Так ничего не поменялось. WinAPI стабилен как пирамида Хеопса и это очень правильно. Сгодится даже учебник времен Windows 95.

        • kalininmr
          /#19263501

          некоторые новые веяния — появились.
          местами вполне удобные

          • quwy
            /#19266405

            Не спорю, но основы и вот это вот все:

            оконные процедуры, windows-сообщения, объекты ядра
            никуда не делось. А красивости можно потом уже изучить отдельно.

            • kalininmr
              /#19267119

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

        • Grief
          /#19263583

          А как же .NET? Выше его сравнили с Electron, но (сугубо имхо) — это реально крутая вещь, особенно учитывая то, что под linux есть mono. Я сам давно не писал под винду, но когда заканчивал, вроде был курс на уход от winapi в сторону .net для всего пользовательского софта, для которого это возможно.

          • Fedcomp
            /#19263747 / -1

            под Linux .NET будет выглядеть как flash под винду.

            • boblenin
              /#19268153

              gtk#/mono уже больше 10 лет зависимостью для gnome desktop modules был.

    • jacob1237
      /#19263417 / +2

      К сожалению программистов такая вещь как Electron пользуется спросом у бизнеса именно по причине оптимизации денежных трат. Сегодня количество веб разработчиков в разы превышает количество других прикладных программистов. Писать софт на JavaScript попросту быстрее и дешевле, чем использовать специализированные технологии.


      Electron действительно сжирает всю память и процессорное время. Однако это дает возможность бизнесу быстро вводить в строй новые продукты.


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


      Закон перехода количественного в качественное никто не отменял :)

      • Fesor
        /#19263457 / +1

        Закон перехода количественного в качественное никто не отменял :)

        напомните мне примеры выполнения этого закона.

        • jacob1237
          /#19263499 / -2

          Пример: язык Go. Раньше все писали сетевые сервисы на чем попало, то есть Python, Perl, Node.js, C++ и т.д. Сегодня для этого берут Go. Компилируемый язык со встроенной кооперативной (а также вытесняющей) многозадачностью.


          Посмотрите на проект Сentrifugo: https://github.com/centrifugal/centrifugo
          Раньше был написан на Python (Tornado), теперь на Go. В итоге производительность увеличилась на порядки, а потребление памяти снизилось, не сильно при этом потеряв в простоте поддержки кода.

          • Fesor
            /#19263515 / +1

            Простите, но где тут количество и о каком качестве идет речь?


            Если говорить о количестве и качестве — посмотрите на увеличение количества разработчиков на Go. А теперь проанализируйте тренд уровня этих разработчиков.


            То что у нас появился компилируемый эрланг (да, я сейчас ооооочень сильно утрировал, без децентрализации это все не сильно нужно) это замечательно, однако качественного скачка я не вижу. Люди как и раньше писали на Java/Perl/Python/Node/C++ так и продолжают писать. Просто теперь есть еще Go и Rust. А еще есть D, Elexir, Kotlin и многие другие штуки. Но что-то как-то люди продолжают писать микросервисы на php.


            p.s. центрифугу юзаю, и рад что кто-то ее написал. Но будь она написана на эрланге, хаскеле или ocaml — мое отношение к ней не сильно бы отличалось.

            • jacob1237
              /#19263529 / -2

              Качественный скачок — новый специализированный язык, поддерживающий многозадачность из коробки.
              Сетевые сервисы сейчас проще и быстрее писать на Go, не теряя в производительности и потреблении памяти.


              Написать сетевое приложение на Go значительно проще чем на C++. Касательно Java/Python и т.д. — все это языки, в которых для исполнения кода используется дополнительная абстракция (виртуальная машина/интерпретатор), так что по эффективности они априори проигрывают.


              По поводу D могу сказать что там не все так однозначно. Есть фреймворк vibe.d, но он из коробки не даст той же производительности как и Go. В vibe.d тоже используется кооперативная многозадачность, но там нет встроенного пула потоков, по которому раскидываются задачи (технически это возможно, но программисту все еще нужно понимать что происходит "под капотом").


              По поводу микросервисов могу сказать что эта архитектура скорее попытка адаптации к рынку труда, чем к решению технологических задач. Микросервисы можно писать на чем угодно, и этот факт позволяет компаниям охватывать при найме гораздо большую часть рынка, чем просто "PHP Developer" или "Erlang Developer" (и т.д.).


              Rust же совсем не про сетевые сервисы. Это С на стероидах. В будущем приложения, которые раньше писали на C, будут писать на Rust, т.к. этот язык конкурирует именно с C и его производными.


              Так что Go на мой взгляд именно что качественный скачок применительно к написанию сетевых сервисов. А на Ваш взгляд?

              • Fedcomp
                /#19263769

                Rust же совсем не про сетевые сервисы


                Это почему еще? он еще и производительнее Go будет.

                • unclechu
                  /#19268489 / +1

                  И абстракций и выразительности там ощутимо больше для их описания.

                • Kirhgoff
                  /#19273853

                  И там нет такой боли с прописыванием полного пути к переменным когда сильно все вложено

              • Szer
                /#19263875

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

                Поддерживающий только ОДНУ парадигму многозадачности (корутины) из коробки, и оберачивающий весь синтаксис на фоне в монадку Async, чтобы блокирующие вызовы байндились на континуейшн как будто это императивный код.


                Любой нормальный язык даст вам на выбор другие парадигмы многозадачности: треды, корутины, фиберы. Монадки конечно же любые на выбор (без дженериков в Го их не сделать, поэтому захардкожена одна), на выбор вытесняющие или кооперативные юзер-спейс планировщики.


                Это всё из Го убрали чтобы среднему гоферу не надо было мучаться проблемами выбора.

              • Fesor
                /#19265655 / +3

                Написать сетевое приложение на Go значительно проще чем на C++

                Согласен. Написать его эффективно — не сильно проще чем на C++. Просто язык дает меньше возможностей по стрельбе по ногам.


                так что по эффективности они априори проигрывают.

                Напомню что в го рантайм тоже не бесплатный. GC, распределение корутин, все это довольно жиное и в целом приводит к тому что грамотно написанное приложение на Java будет примерно так же эффективно работать. Другой момент что с Go будет проще. Однако тот же rust уделает их всех, хотя посадить студента на раст будет проблематичнее да.


                Это С на стероидах.

                Тогда Go это С на седативах.


                А на Ваш взгляд?

                На мой взгляд Go, это ответ на проблему низкой квалификации разработчиков. Урезанный по самое немогу язык (не считаю что это плохо, если что), который максимально защищает человека от вопросов применения воображения. Все делается примитивно и в лоб. Идеально для массовой разработки.


                Является ли это качественным скачком? Нет. С точки зрения качества разница не велика. Опять же — основная проблема го — хайп, в свете которого все кому не лень начали на нем писать. И с каждым годом квалифицированность среднего разработчика на Го вызывает вопросы. Сейчас идет процесс усложнения языка, что в купе с наплывом слабых разработчиков скорее всего отбросит его успех назад.


                Если же для вас Го это качественный скачек — задумайтесь. Это скачек для вас или для индустрии в целом?

                • jacob1237
                  /#19267287

                  Создается ощущение, что Вы нарочно опускаете контекст дискуссии. Ключевое слово "сетевые сервисы" почему-то осталось незамеченным Вами и остальными комментаторами этой ветки.


                  Как и обычно бывает в рунете (и на Хабре в частности) — сначала закидывают шапками, а потом разбираются.


                  Я говорил не про сам язык программирования Go, а лишь привел его в пример в качестве иллюстрации закона перехода количественного в качественное (по Вашей же просьбе). Контекстом этого перехода является именно предметная область написания сетевых сервисов (network applications), а не проблемы отрасли, парадигмы программирования или вселенской справедливости.


                  Причем под количеством и качеством я понимал термины из философии (Диалектика Гегеля / Диалектический Материализм), а не количество как число (уж тем более число разработчиков) и качество как качество ПО.


                  Сам пример перехода я подрузамевал так:


                  1. Появляется проблема написания сетевых сервисов и приложений;
                  2. Появляются разрозненные решения: зачастую библиотеки/фреймворки к существующим языкам для работы над проблемой;
                  3. Возрастает сложность проблемы, возрастает нагрузка на приложения;
                  4. Постепенно продолжают происходить количественные изменения: предлагаются новые варианты решения — multi-threading (Java, Apache HTTP server, etc.), fork (CGI, FastCGI, *CGI), async concurrency (libevent, libev, libuv, etc. и основанные на них решения — NGINX, NodeJS и т.д.)
                  5. Происходит качественный скачок — появление и позиционирование языка Go для решения этих проблем. Язык заточен исключительно под предметную область: объединяет модель multi-threading и async concurrency — программа запускается в несколько потоков, которые в свою очередь обрабатывают очередь задач (goroutines), позволяя еще более эффективно использовать процессорные ядра.
                    Стандартная библиотека позволяет написать мощный и быстрый HTTP сервер в пару строк кода за несколько десятков минут. На решение подобной задачи с точно такой же эффективностью в других языках уйдет просто уйма времени (особенно в C++).

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


                  За сим позвольте откланяться. Считаю данную дискуссию исчерпанной и вышедшей за рамки данной статьи.

                  • Szer
                    /#19268191 / +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
                      /#19268385 / -1

                      Смешались в кучу кони, люди.

                      Сочувствую. Но не переживайте, все у Вас наладится, я в это верю, правда.


                      Я понимаю что гоферам застилает глаза божественность Пайка, но неплохо мы обзнакомиться с теорией.

                      Полностью согласен! Осталось только предложить это самим гоферам, а не писать это под моими комментариями. =)


                      Что нового привнёс Go?

                      Go популярен, поэтому я упомянул именно его, для того чтобы говорить с людьми на одном языке, принимая во внимание то что я не знаком с Fesor лично и не знаю его бэкграунда. Это считается нормальным в диалоге — переходить от общего к частному.


                      А вот то что у Вас от этого бомбануло (наверное), не сказать чтобы прямо моя вина. Тем более что дискутировал изначально я не с Вами =)


                      Языки, в которых в самом синтаксисе была селективная асинхронность с синхронным общением между легковесными тредами и корутинами:

                      СSP модель в Go не является чем-то новым и захватывающим, но вот то что язык специализировали под определенные задачи, сделали при этом его компилируемым в машинный код, приспособили под современный рынок труда а затем правильно отпозиционировали — вот это как раз является.


                      Я не вижу смысла продолжать дискуссию, потому что мы с Вами, судя по-всему, говорим несколько о разных вещах.


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

                      • Szer
                        /#19268659 / +1

                        Я не вижу смысла продолжать дискуссию… ответьте, какие из перечисленных Вами языков кроме Haskell компилируются в машинный код и почему все они достаточно маргинальны по сравнению с Go?

                        Противоречивые параграфы вижу я, но ладно :)


                        GHC у Хаскеля умеет компилировать как в натив, так и под LLVM
                        FSC в F# умеет компилировать только под CLR, но есть такая штука как .NET Native, которая сразу полученный код для CLR гонит в натив. Не пользовался за ненадобностью.
                        В JVM тоже есть способ гнать байткод в натив — Excelsior например.


                        Не буду скрывать, нативный бинарник Go получится крайне маленьким по размеру по сравнению с любым из вышеперечисленных, но это из-за скудности стандартной либы Go (и это слабо сказано), а не потому что там какие-то ядерные оптимизации происходят.


                        По поводу маргинальности — PHP и Питон тоже популярнее Haskell, F# и Clojure. Да и вообще всех ФП языков. Возможно даже вместе взятых.


                        Делает ли это Haskell, F# или Clojure плохими языками? Для тех кто не осилил их освоить — несомненно.

                        • jacob1237
                          /#19270309

                          GHC у Хаскеля умеет компилировать как в натив, так и под 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
                            /#19270367

                            Вам бы тендеры устраивать. Вы берете список особенностей, под которые попадает только Go, говорите, что это самые важные качества в ЯП, и побеждает… Go. Какая внезапность.

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

                            • jacob1237
                              /#19270533

                              Вам бы тендеры устраивать

                              А Вам бы с таким аватаром только в дискуссиях про ЯП участвовать =)


                              Не вижу смысла спорить «какой язык более гошный, чем го»

                              Что значит более "гошный"? Когда Go появился, сначала его позиционировали как конкурента и замену языку C, но не найдя на этом поприще признания, его просто специализировали под написание сетевых приложений. И в этом ключе он уже обрел популярность.


                              Создается впечатление что Вы упорно не хотите видеть какую проблему он решает и уводите все в плоскость сравнения языков по их возможностям.


                              Можете объяснить зачем среднестатистическому HTTP серверу (к примеру) аппликативные функторы, монады и монадные трансформеры (в общем их виде)?


                              Вот перепишем Nginx на Haskell, вот тогда уж точно заживем!

                              • PsyHaSTe
                                /#19270567 / +1

                                А Вам бы с таким аватаром только в дискуссиях про ЯП участвовать =)

                                Еще и гадать по аватарке будете, неплохо )


                                Создается впечатление что Вы упорно не хотите видеть какую проблему он решает и уводите все в плоскость сравнения языков по их возможностям.

                                Можете объяснить зачем среднестатистическому HTTP серверу (к примеру) аппликативные функторы, монады и монадные трансформеры (в общем их виде)?

                                Затем же, зачем и в любой другой программе — чтобы описать пайплайн обработки запроса в удобном виде. А может и не нужны, это ведь просто инструмент. Во-первых есть много промежуточных сценариев, а во-вторых вопрос аналогичен "зачем среднестатистическому HTTP серверу нужны continue и break".

                                • jacob1237
                                  /#19270629

                                  Зачем среднестатистическому HTTP серверу нужны continue и break

                                  Ну, наверное затем, чтобы, как минимум, можно было более удобно построить конечный автомат для парсинга HTTP запроса, нет?


                                  Хотя да, что уж там, с монадами-то процесс парсинга значительно ускорится и потребит меньше памяти! Это ж как можно будет распараллелить процесс, если парсить заголовки и тело запроса отдельными pure функциями, завернутыми в монаду. Ого-го!

                                  • PsyHaSTe
                                    /#19270887

                                    Не вижу повода для сарказма, так что поддержу общий воодушевленный настрой: так ведь оно и есть.

                                    • jacob1237
                                      /#19271065 / -2

                                      Поддержите. Ведь это все что Вам остается в отсутствии объективных аргументов.

                                  • 0xd34df00d
                                    /#19271581

                                    Не понимаю ваших ужимок. attoparsec'ом (а он монадический) парсить одно удовольствие. В плюсах всем дерет задницу почему-то boost.spirit, который тоже, по большому счёту, монадический (особенно x3).


                                    Ну и если вы пишете ваш парсер на аппликативных функторах, а не на монадах, то это сразу, автоматически (а, главное, статически) значит, что парсер не может принимать решения на основе уже распаршенных значений, что позволяет генерировать более эффективный код.


                                    Ну, это к вашему вопросу о том, зачем знать разницу между монадой и аппликативным функтором.

                                    • jacob1237
                                      /#19271661

                                      Не понимаю ваших ужимок

                                      Давайте я Вам объясню:


                                      Я не пишу на Go. Для моих задач он не имеет достаточной выразительности и удобства. Я упомянул Go в качестве ответа на вопрос Fesor.


                                      Посыл мой заключался в том, что сегодня все пишут GUI на Electron, а завтра есть вероятность появления какой-либо более оптимизированной по памяти и скорости технологии, согласно закону перехода количественного в качественное.


                                      Я упомянул Go специально, т.к. это всем понятный пример, который на слуху у большинства, в отличие от более маргинальных здесь приведенных языков (F#, Racket, CML и т.д.), и упомянул его в совершенно конкретном контексте — сетевых приложений.


                                      Вместо того чтобы прочитать мои сообщения внимательно, люди, заметив упоминание Go, решили наброситься на меня и начать выяснять чем Go лучше или хуже других технологий (еще и попутно выставляя меня фанатиком Go).


                                      Скажите, Вы тоже не видите изначального посыла моих комментариев?

                                      • 0xd34df00d
                                        /#19271709

                                        Тогда тем более не понимаю, причём тут монады и прочие профункторы и написание парсеров на них.


                                        Говоря об изначальном посыле — на мой взгляд (и, вероятно, на взгляд прочих ваших оппонентов, особенно апеллирующих к тому, что это уже давно было в Симпсонах других языках), в случае Go как раз видно количественный рывок, а не качественный.

                                    • jacob1237
                                      /#19271703

                                      Ну, это к вашему вопросу о том, зачем знать разницу между монадой и аппликативным функтором.

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

                                      • 0xd34df00d
                                        /#19271715

                                        Этот комментарий подразумевает, что автору сервера имеет смысл об этих вещах знать (ну или не знать).

                              • 0xd34df00d
                                /#19271563

                                Можете объяснить зачем среднестатистическому HTTP серверу (к примеру) аппликативные функторы, монады и монадные трансформеры (в общем их виде)?

                                Чтобы управлять эффектами и гарантировать на уровне типов, что вы не полезете в /etc/shadow, не пустите неавторизованного пользователя куда не надо, не проинтерпретируете число как строку или наоборот и так далее.


                                Посмотрите servant.


                                Вот перепишем Nginx на Haskell, вот тогда уж точно заживем!

                                nginx не надо, а вот какой-то гошный бенчмарк я ради интереса пару лет назад на хаскеле переделал (тут ещё на хабре разные люди на свои любимые языки пытались его переписать), и работало оно быстрее.

                          • 0xd34df00d
                            /#19271551

                            Потому что обслуживать, скажем, торговые сети или интернет магазины дешевле и целесообразнее при помощи вчерашних студентов или переквалифицировавшихся профессионалов, чем при помощи PhD и профессоров из вузов Ivy League. Ибо масштаб проблемы слегка не тот.

                            А зачем для магазинов всякая хардкорная конкурентность и всё такое? Да и для торговых сетей, судя по тому, что там тоже студенты полезнее, тоже.

                            • jacob1237
                              /#19271605

                              Думаю это вопрос не ко мне. Лучше об этом спросить у Ozon: https://vc.ru/ozon/45542-go или у Zalando, или у остальных пользователей.


                              В основном они применяют Go для инфраструктурных моментов (насколько мне известно).


                              Также есть всякие рекламные биржи и т.д.

                            • Alexey2005
                              /#19272531

                              Кодеры СДЭК (одной из крупнейших курьерских компаний в России) видимо тоже так думали. А потом случилось страшное: после апгрейда внезапно выяснилось, что система немасштабируема.
                              На тестовых серверах всё ОК, а вот реальные нагрузки мгновенно кладут систему на обе лопатки, причём даже добавление серверных мощностей не позволяет справиться с проблемой.
                              Всё упало 26 сентября, прошёл уже почти месяц, всё это время программисты пафосно превозмогают проблему, но безуспешно. Завязанные на них интернет-магазины терпят убытки, франчайзи разоряются, техподдержка убита напрочь наплывом разгневанных пользователей.
                              А система лежит. И если продолжит лежать ещё недельки три, то есть неплохой шанс увидеть банкротство крупной курьерской компании исключительно по вине IT.

                              • 0xd34df00d
                                /#19272583 / +2

                                То есть, если эту систему бы пилили и обслуживали студенты, но на Go, то она магически бы заработала?

                                Ну ок, магический язык, действительно. Надо переходить.

                                • jacob1237
                                  /#19275439

                                  Думаю что ответ на Ваш комментарий был связан с вопросом: "А зачем для магазинов всякая хардкорная конкурентность и всё такое?".


                                  Про Go упоминаний не было. Но Вы опять про Go и про студентов, хотя я, например, использовал сочетание "вчерашних студентов", что подразумевает то что человек все-таки закончил обучение в ВУЗе.


                                  И такое происходит на протяжении всей ветки со всеми комментаторами.


                                  "Чукча не читатель, чукча писатель!" ©


                                  Очень жаль что русскоязычное комьюнити сильно уступает в адекватности цивилизованным странам.

                                  • Szer
                                    /#19275685

                                    Очень жаль что русскоязычное комьюнити сильно уступает в адекватности цивилизованным странам.

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

                                    • jacob1237
                                      /#19275821

                                      здорово что вы всё русскоязычное комьюнити назвали нецивилизованным

                                      Ну вот видите как оно получается. Я же написал что русскоязычное комьюнити уступает в адекватности, а не то что оно нецивилизованно.


                                      Говорю же, "Чукча не читатель, чукча писатель".


                                      И уж точно не Вам на это мое высказывание обижаться, тем более что Вы тут совсем недавно пытались выставить меня фанатиком Go, говоря что "гоферам застилает глаза божественность Пайка, но неплохо бы ознакомиться с теорией." и позволяя себе прочие фривольности (при весьма забавном обстоятельстве, что я на Go НЕ пишу).


                                      Так что давайте закроем тему. Здесь больше нечего обсуждать.

                        • PsyHaSTe
                          /#19270335 / +1

                          Да тут проще можно сказать — PHP популярнее самого Go. Значит ли это, что PHP лучше?

          • mkshma
            /#19266745 / +1

            Сегодня для этого берут Go.

            Разве что смузи стартапы. Ему еще версий 5 развиваться до момента, когда им можно будет безболезненно пользоваться.

            • Fesor
              /#19267161

              А какие у вас критерии для безболезненного использования?

              • mkshma
                /#19267319

                Нет нормальной обработки ошибок, нет шаблонов, нет перегрузки функций и операторов, зависимость от единого настроенного воркспейса (бить палками того, кто подумал однажды, что GOROOT — хорошая идея). Еще кто-то подумал, что это отличная идея — добавить в язык указатели и отобрать возможность проводить над ними арифметические операции. Зачем-то сделали неявную реализацию интерфейсов. Это так, по верхам прошлись. Знаете что из всего этого собираются решить во второй версии? Шаблоны. А обработку ошибок умудрились сделать еще хуже. Хотя в идеале ошибки должны стать языковой конструкцией, а не возвращаемым параметром. А совсем в идеале добавить кейворд, заставляющий в любом случае ошибку эту обрабатывать, иначе кидать compile error. Но Go-коммьюнити настолько консервативное, что году к 25 мы может половину из этого и увидим. В лучшем случае. Правда решение всех этих проблем приведет нас к ситуации с питоном и его версионированием — к такому сектантское коммьюнити Go просто не готово. Так что я бы просто закопал этот язык сразу, а не ждал, пока не окажется слишком поздно для лечения отстреленной ноги.

                • boblenin
                  /#19268187

                  > Нет нормальной обработки ошибок

                  Такая же или чуть-чуть получше чем в 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
                    /#19268263

                    Какую бы вы хотели? Надеюсь не исключения, которые в том же C++ весьма не редко отключают?

                    Монадическую + изредка экзепшоны.


                    Так же как их нет во множестве языков, например в Java

                    В джаве есть дженерики, да и вообще джава — не образец с точки зрения их реализации.


                    Зато они есть в C++

                    И это типа плохо для C++ или хорошо для Go?

                    • Fesor
                      /#19268443

                      В джаве есть дженерики

                      ну дженерики и метапрограммирование на темплейтах это все же разные немного вещи.

                      • 0xd34df00d
                        /#19268463 / +1

                        Между «никаких средств реализации параметрического полиморфизма» и «ещё один тьюринг-полный язык в языке» есть достойные позиции, и дженерики в стиле Java (а лучше — без стирания типов, в стиле C#) там вполне себе находят себе место. Говорю как любитель обмазаться темплейтами.

                      • PsyHaSTe
                        /#19270421

                        Темплейты как по мне довольно злые. Бытие определяет сознание, и то, что на плюсах можно делать крутые штуки через темплейты не означает, что это лучший способ метапрограммирования. Для примера гляньте тот же const genetics в Rust — много интересных вещей можно сделать на генериках, и которые будут работать для любого типа T, а не то, что мы код написали, про который в лучшем случае можно сказать «в тех случаях, где мы этот шаблон инстанцируем, код компилируется и корректно отрабатывает».

                        • 0xd34df00d
                          /#19271595

                          Далеко не лучший, конечно.


                          Дженерики в другом смысле куда лучше, если вам нужно просто анализировать структуры данных и, скажем, генерировать код для сериализации, либо полноценный доступ к AST, да, как Template Haskell.

                    • boblenin
                      /#19272385

                      Это типа зачем из Go делать C++, если уже есть C++? В этом и проблема с C#, Java, C++, JS — что они все более и более похожие, типа Pepsi vs Coca Cola. Странно было бы в упрек Lisp ставить то, что он не похож на Basic или SQL то, что он не похож на Mathematica? Один язык для решения общих задач, множество специализированных для решения узких задач.

                      • 0xd34df00d
                        /#19272553

                        Я из всех перечисленных языков более-менее знаю только C++, и на мой такой ограниченный взгляд они все совершенно не становятся всё более и более похожими.

                        • boblenin
                          /#19272709

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

                          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
                            /#19272777

                            из того что внедряли в каждый из них не так давно

                            Какое-то расплывчатое у вас понятие «не так давно» :)
                            Эксепшены в C# от рождения, генерики, со второй версии, где-то начало нулевых годов, var по-моему тоже где-то в то-же время появился, ну может лямбды не так давно, но кажется еще до рождения Typescript языка.

                          • PsyHaSTe
                            /#19273029

                            Для любой пары языков можно найти даже больше похожих вещей, чем ваш перечень.


                            1. в js тоже есть var, как и в куче других языков. Ладно, предположим вы имели ввиду только вывод типов, но он есть в куче других языков. Стал ли C# похож на Haskell?
                            2. В питоне тоже есть лямбды, питон похож на C#/C++/Java?
                            3. В хачкеле есть генерики, в расте есть генерики, даже в го теперь есть генерики. Похож ли C#/Typescript на Go?
                            4. Эксепшны есть в повершелле. Стала ли Java похожа на Powershell?..



                            Теперь давайте про ченджлоги. Посмотрим что у C# 8.X:


                            1. Not null reference types
                            2. Records
                            3. HKT
                            4. Type classes
                            5. Defalt interface methods
                            6. Code generation extension
                            7. Method contracts
                              ...

                            Приведите ченджлог другого языка, который похож на данный.

                          • staticlab
                            /#19273193

                            Справедливости ради, lambda expressions (arrow functions) появились не в TS, а в JS (ES2015). При этом функции как объекты первого класса (с поддержкой захвата лексического окружения) существуют чуть ли не изначально. Обработка же исключений try/catch/finally тоже появилась давным давно, ещё в стандарте JS 1.4 (1999 год).

                  • PsyHaSTe
                    /#19270411 / +1

                    Такая же или чуть-чуть получше чем в ANSI C. Какую бы вы хотели? Надеюсь не исключения, которые в том же C++ весьма не редко отключают?


                    Как насчет ADT? Но нет, это слишком сложно. А еще замедляет компилятор.

                    Так же как их нет во множестве языков, например в Java

                    Только в жабе есть генерики, а в го — простите. Видел Go2 — это больше на издевательство похоже. Такое ощущение, чтобы людей тошнило от генериков, а Пайк будет к каждому подходить и говорить «я же говорил, что генерики это плохо, а вы требовали… Нате, получайте».

                    Зато они есть в C++

                    А при чем тут Go? Аргумент «потому что пароход».

                    Зато все единообразно и чинно-благородно. Разве не к этому пытается куча фреймворков на JS, Python прийти?

                    У вас нет нормальных зависимостей, и все, что предлагает го коммьюнити в качестве решения — смириться.

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

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

                    Так ведь уже есть множество языков, где все что вы хотите — сделано. А вот языка, который практически не нужно учить — больше нет. Зачем нужен еще один JS/C#/C++/Java?

                    Хороший вопрос. Отсюда кстати следует вывод, что если Go1 еще полезен компаниям, которые хотят сэкономить на кадрах и отказываются их обучать (что хорошо для компании, но плохо для самих разработчиков и коммьюнити в целом), то Go2 — это такая вот ни рыба, ни мясо — сложно для освоения простым людям, а непростым просто ненужная солянка идея из 60х в довольно плохом изложении.

                  • mkshma
                    /#19270461 / +1

                    Такая же или чуть-чуть получше чем в ANSI C.

                    И сильно лучше, чем в ассемблере. Как уже упомянули, монадическая выглядит неплохо, хотя очень уж из стиля Go выбиваться будет. Что в принципе даже неплохо, наверно.

                    Так же как их нет во множестве языков, например в Java

                    Язык без шаблонов обрекает себя на очень узкую область применения. Исключением могут быть разве что языки старше меня, но тут дело в специфике.

                    Зато они есть в C++

                    И поэтому пока нет никакого смысла менять C++ на Go.

                    Зато все единообразно и чинно-благородно. Разве не к этому пытается куча фреймворков на JS, Python прийти?

                    Это тот python, для которого люди придумали virtualenv, чтобы как раз эти воркспейсы и поделить? В том-то и дело, что зачастую не надо единообразно. Нужен разный зоопарк версий под разных заказчиков и возиться со всем этим в одном воркспейсе не самая тривиальная задача.

                    Затем, чтобы не делать в очередной раз явную.

                    И в итоге не понятно, во-первых, а какие интерфейсы мы вообще реализуем, а, во-вторых, нет ну вообще никаких гарантий, что мы его реализовали.

                    Вы какой-то rust хотите сделать из Go.

                    Ну, на мой вкус, не самый плохой вариант развития событий.

                    А вот языка, который практически не нужно учить — больше нет

                    У нас есть JS. SO-ориентированное программирование цветет и пахнет на нем. Код тоже пахнет. Изучение того же C++ на достаточном уровне либо отобьет у вас желание программировать, либо научит нормально распоряжаться ресурсами. Если начинать с Go, то без умного чувака рядом человек скорее всего будет гнать мусор тоннами.

                    • boblenin
                      /#19272445

                      > Как уже упомянули, монадическая выглядит неплохо, хотя очень уж из стиля Go
                      > выбиваться будет. Что в принципе даже неплохо, наверно.

                      Даже представить не могу как бы это выглядело. Можете попробовать на псевдокоде примерчик написать?

                      > Язык без шаблонов обрекает себя на очень узкую область применения.
                      > Исключением могут быть разве что языки старше меня, но тут дело в
                      > специфике.

                      Так ведь это и хорошо, разве нет? Узкоспециализированый язык, заточеный под эту специальную задачу позволит решать эту задачу более эфективно. А очередной монстр никаких преимуществ перед другими такими же языками широкого профиля иметь не будет. А недостатки — будет, в виде меньшей библиотеки инструментов, меньшего коммьюнити итд

                      > И поэтому пока нет никакого смысла менять C++ на Go.

                      И я о том же. Не надо C++ менять на Go. Кесарю кесарево.

                      > Нужен разный зоопарк версий под разных заказчиков и возиться со всем этим в
                      > одном воркспейсе не самая тривиальная задача.

                      Ну на это жаловаться во времена докера — как-то странно.

                      > И в итоге не понятно, во-первых, а какие интерфейсы мы вообще реализуем, а,
                      > во-вторых, нет ну вообще никаких гарантий, что мы его реализовали.

                      Вот с первым согласен. И считаю, что это прекрасно. А второе — действительно проблема, но ведь это и не важно. Если код потребителя изменился так, что ему перестал подходить уже реализованый интерфейс — то и проблему можно решать там, где ее проще всего решить — в коде клиента.

                      > Ну, на мой вкус, не самый плохой вариант развития событий.

                      А зачем, если уже есть rust?

                      > Изучение того же C++ на достаточном уровне либо отобьет у вас желание
                      > программировать, либо научит нормально распоряжаться ресурсами. Если
                      > начинать с Go, то без умного чувака рядом человек скорее всего будет гнать
                      > мусор тоннами.

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

                      • 0xd34df00d
                        /#19272555

                        Даже представить не могу как бы это выглядело. Можете попробовать на псевдокоде примерчик написать?

                        Что именно, монадическую обработку вообще или конкретно на Go?

                      • mkshma
                        /#19273553

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

                        Так пусть вкатываются, кто ж им мешает. Вот только вкатываться в IT они должны через боль и страдания, а то потом у нас Gmail лагает и на Хабре страница с 2к комментов минуту грузится. Таких вот тут не надо.

      • YemSalat
        /#19264119 / -2

        Electron действительно сжирает всю память и процессорное время.

        Не путайте слаковский клиент и электрон. Сам электрон ничего нe «сжирает».
        Недавно писал нa нем тулзу для трея — занимает 25МБ, процессор вообще не трогает фактически. Скажете 25МБ для мелкой трейной проги — это много? Я скажу что она работает на всех популярных операционках и написана нa языке без прямого управления памятью.

        • daggert
          /#19264189 / +1

          Как человек писавший утилиту для трея в xp и убунте 6.04 — да, 25 метров это дичь для мелкой трейной проги. После всяких борландовских с++ старых, где можно было влезть в мегабайт (прога смотрящая смб шары в локалке) — электрон это жир жирный.

          • fatronix
            /#19264247

            У меня в XFCE каждый плагин для трея примерно столько же ест, две панели (по одной на экран) в сумме съедают мегабайт 200.

            • Sabubu
              /#19264919

              Может они тоже на Яваскрипте? В Гноме 3 gnome-shell написана на JS + нативный код (по типу React Native, только без потерь производительности на реакт). Ест 100-200 Мб, правда она всем занимается, и панельки выводит, и поиск, и окнами управляет.

              • fatronix
                /#19265379

                Нет, почти всё написано на Си либо других компилируемых языках.

                Хотя, справедливости ради, эти плагины обычно плотно завязаны на иксы или вообще являются модифицированными либами для иксов (libxcb, например, который в момент написания комментария кушает 37 мегабайт).

        • xRay
          /#19264229

          Без информации о функционале сложно согласится с тем что всего-то 25Мб. Что ваша программа делает?
          К примеру клиент Telegram потребляет 47МБ.

          • YemSalat
            /#19270637

            Без информации о функционале сложно согласится с тем что всего-то 25Мб. Что ваша программа делает?

            Ничего почти не делает, показывает иконку + статистику кое-какую.
            25МБ весит просто обертка.

            Я понимаю что в отрыве от контекста — 25МБ — это много.
            Но надо учитывать, во-первых, что это всего 0.15% от современных средних 16ГБ.
            А во-вторых, что за ~50 строк кода и 25МБ памяти мы получаем программу, которая работает везде без плясок с бубном.

            И 25МБ не будут просто так расти в геометрической прогрессии с ростом функционала, все зависит от прямоты рук разработчиков.
            Не стоит брать слак в пример, он просто коряво сделан. Я ужe вышe писал что сам юзаю веб версию вместо клиента.

            • PsyHaSTe
              /#19270897

              У меня в пиках 33 гигабайта из 16 физических, потому что автор каждого из сотни процессов, что постоянно запущены в ОС исходили из той же логики. А ничего, что браузер по крайней мере четверть этого места занимает? Какой-нибудь докер еще половину. И тут остается, что у пользователя всего 4 гига свободной памяти, которую надо как-то поделить между системными процессами, каким-нибудь офисом, скайпом, и электрон-поделиями.

            • Neikist
              /#19270987 / +1

              современных средних 16ГБ

              Вы забыли уточнить: средние 16 гигов на машине программиста. Потому что в реальности 16 гигов это ни разу не среднее значение. Обычно сейчас 4 и 8 встречаются. На совсем дешевом железе 2-3. На совсем-совсем дешевом и того меньше.

              • JC_IIB
                /#19271215

                На совсем дешевом железе 2-3. На совсем-совсем дешевом и того меньше.


                Это что ж за дешевое железо-то такое? В том же ДНСе компов меньше, чем с 4 гигами нету в продаже. Я бы сказал, средние машины сейчас как раз 8, реже — 16.

                • Neikist
                  /#19271339

                  Я допустим буквально несколько месяцев назад взял ноут простенький где 3 гига. Просто в деревню ездить или на природу. Дома то понятно нормальные 16 гигов на ПК.
                  Притом я еще видел варианты с 2 и 1 гигом (да и сейчас есть в том же днс двухгиговые варианты за 10к примерно). И не надо забывать что есть еще и БУ железо которое покупают люди с невысоким достатком.

                  • Simplevolk
                    /#19271391

                    Вот именно, что «нормальные» 16 гигов. Собирал комп 4 года назад и поставил как раз 16 гигов «на вырост». И если раньше в среднем у меня уходило по 6-8 гигов после старта системы, то сейчас уже 10-12… Инфляция?

                    • JC_IIB
                      /#19271431

                      Инфляция


                      Скажите спасибо Electron-у.
                      Но чет 10 гиг после старта — это очень дофига. Может, все же какой софт запускается? :)

                      • PsyHaSTe
                        /#19271695

                        Докер на автозапуске спокойно даст такой профиль.

                        • Simplevolk
                          /#19273891

                          да, докер в машине включен (но не используется)

                  • JC_IIB
                    /#19271397

                    Ну, если речь идет о ноутах, то тут возможны варианты, да. Я, прежде чем написать свое предыдущее сообщение, открыл сайт ДНСа и проверил — десктопные варианты у них начинаются с 4мя гигами, меньше нет.

                    И не надо забывать что есть еще и БУ железо которое покупают люди с невысоким достатком.


                    4 гб модуль DDR4 новый по ценам ДНСа — в районе 2500 р, на авито бэушные они по 2000 у барыг, стало быть у частников можно купить по 1600-1700 где-то.

                    • Neikist
                      /#19271601

                      Угу, а на том же авито при желании можно ноут или нетбук взять за 3-4.

                    • ainoneko
                      /#19274365

                      И не надо забывать что есть еще и БУ железо которое покупают люди с невысоким достатком.
                      4 гб модуль DDR4 новый по ценам ДНСа — в районе 2500 р, на авито бэушные они по 2000 у барыг, стало быть у частников можно купить по 1600-1700 где-то.
                      Осталось уточнить, в какое место БУ железа можно засунуть DDR4. («Более старая» память дороже.)
                      (Для «носить с собой в автобусе» у меня нетбук, в который больше 2ГБ просто «по инструкции» не ставится (да, говорят, в некоторые можно ставить больше, чем положено, и оно даже работает).)

                      • JC_IIB
                        /#19274491

                        Осталось уточнить, в какое место БУ железа можно засунуть DDR4

                        В такое БУ, которое не старше 4-х лет, DDR4 была представлена в 2014м.

                        «Более старая» память дороже.

                        ДНС, новый модуль G.Skill 4GB DDR3 = 2 тыщи рублей, Patriot 2100 р. Есть даже дешевле.

                        Авито первые попавшиеся предложения: Ddr3 4gb Hynix 2Rx8 PC3-10600 1250 рублей, 4гб ddr3 рс-12800/10600 — 1700 рублей.

                        • Neikist
                          /#19274937

                          Ну 4 года всего это почти новье)) Так то народ и железки вроде asus eeepc на авито покупает/продает. Я допустим сам недавно покупал, но решил что железо посовременней все же нужно и опять же продал несколько месяцев как.

        • batyrmastyr
          /#19264711

          На языке без прямого управления памятью дедушка Вирт ещё в 1989 году забахал свою оконную ОС с гибридом из среды разработки, Word Pad и ActiveX. Уж не знаю сколько оперативки она жрала, на 25 мегагерц процессора ей хватало.

        • zeronice
          /#19265225

          25Mb?!?!
          Прям сейчас на .net запустил форму с треем: бинарник — 42кб и в памяти 3,5 мб. И да, вот оно процессор не трогает.

          • GrigoryPerepechko
            /#19266051

            .net либо Windows-only, либо опять же тянуть целый mono на macOS/linux а это уже не 42кб.

            По памяти 3.5мб для иконки в трее тоже звучит жирновато, вам не кажется?
            К примеру зачем вам 1МиБ памяти для стека основного потока?

            • zeronice
              /#19266639

              ну все же, .net это еще и рантайм, и спорить с нативным кодом, содержащим только winapi я не буду. по поводу 1мб на поток — это не к нам, это более древний вопрос. Каюсь в неопытности, я не знаю как указать рантайму есть меньше по дефолту, но вроде бы iis ест в 4 раза меньше.ну и этот 1м — не реально съеденный, а всего лишь обозначенный в виртуальной памяти.

            • PsyHaSTe
              /#19266751

              Во-первых mono не в моде уже года четыре.
              Во-вторых то, что у вас сишный рантайм встроен в большинство ОС никого не расстраивает. C++ redistrutable на гигабайты люди охотно ставят, а вот 50мб фреймворка это чересчур. Как-то не очень честно.

              Отвечая товарищу zeronice, IIS тоже кроме как в легаси проектах не используется, kestrel + nginx наше все.

              • zeronice
                /#19266783

                IIS касался только вопроса STACKSIZE, чисто теоретически.

        • OnelaW
          /#19266385

          25 метров это очень много.
          Сможет ли утилита при том же умении отжирать памяти намного меньше?

        • mkshma
          /#19266769

          Скажете 25МБ для мелкой трейной проги — это много?

          Это серверная убунта.

        • progman_rus
          /#19267395

          25 метров для трея?
          Она что сворачиваемость белка еще при этом считает?
          PS мою молодость за такое выписывали пожизненный эцих с гвоздями

          • YemSalat
            /#19270727

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

      • unclechu
        /#19268491 / +1

        Сегодня количество веб разработчиков в разы превышает количество других прикладных программистов. Писать софт на JavaScript попросту быстрее и дешевле, чем использовать специализированные технологии.

        Давайте честно назовём вещи своими именами. Сейчас много не "веб-разработчиков", а много просто плохих/слабых/неопытных разработчиков. Дефицит хороших специалистов.

    • Fesor
      /#19263451

      И даже в сотню кбайт скомпилированного 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
        /#19263487

        Все верно. Но процессоры подходят к финалу эволюции. Вы видели последние i7, точнее, уже i9? Там везде частота 4.6-4.9. 5.2 является пределом сегодня. Нельзя вечно наращивать частоты и ядра, а ядра так вообще мало помогают с однопоточными приложениями.
        Рано или поздно придется отложить костыли и взяться за решение этой проблемы.

        • Fesor
          /#19263509

          Но процессоры подходят к финалу эволюции

          во первых не к финалу эволюции а к ограничениям элементной базы. А во вторых — причем тут процессоры?


          Если что — основная проблема на сегодняшний день не процессоры, а скорость доступа к памяти и I/O. Пока вы ходите в оперативку за списком тредов вашего чатика, процессор может много чего сделать. Очень много всякого.


          И выливается это все в распаралеливание и асинхронную работу. А учитывая уровень среднестатистического разработчика сегодня расчитывать на эффективную работу не приходится.


          Напомню, что некие ребята из компании Mozilla дабы решить эту проблему хотя бы частично свой язык программирования придумали (именно что бы распаралелить рендринг страничек в своем браузере и при этом не свихнуться).


          Что до вопроса с электроном и намеки что приложение на электроне потребляет ресурсов неадекватно больше чем нативное решение — пока это все пустые домыслы. Попробуйте реализовать какой-либо продукт нативно и в электроне. Причем так что бы функционал был идентичен и исходники открыты (дабы можно было объективно проверить насколько качественно реализовано).


          Я бы не сказал что все это кастыли. Скорее это попытка компенсировать низкий уровень разработчиков.

          • iproger
            /#19266771

            Да, вы правильнее написали. Финал для текущей архитектуры.

            Я думаю что проблема именно в скорости цп. Это заметно когда даже 8700k 5.0ггц открывает программы с небольшим пролагом. Ту же phpstorm он открывает 5-10 секунд. И вряд ли дело в диске: m2 samsung 970 pro — один из быстрейших ssd. Мне видится что проблема именно в скорости ядер. Даже если поставить ramdisk то все равно не будет нужной скорости. Тот же тяжелый скрипт выполняется за 300мс под всеми оптимизациями (я про мадженту).

            Рзработчики игр, например, все больше уходят в многопоточность: для последних игр уже необходимы 4, а желательно 6 иди 8 ядер.

            • Fesor
              /#19267205

              Это заметно когда даже 8700k 5.0ггц открывает программы с небольшим пролагом.

              и пролаг этот связан с тем что ваш процессор ждет пока данные загрузятся (из кэша, потом из памяти при кэш мисе, и если что еще на файловую систему сгонять).


              Ту же phpstorm он открывает 5-10 секунд.

              И как вы думаете, какой процент этого времени уходит на ожидание I/O? Или вы думаете оно там яростно что-то считает?


              один из быстрейших ssd
              Даже если поставить ramdisk то все равно не будет нужной скорости.

              image


              Рзработчики игр, например, все больше уходят в многопоточность

              Ну вы сравнили, объемы вычислений игрушки какой и объем вычислений требуемый тому же шторму.


              Шторм упирается в I/O. Да, есть нюансы, типа специализированный софт для симуляций, визуализации и т.д. который можно развивать только за счет параллелизма вычислений, но это опять же маленький процент прикладного софта.

              • iproger
                /#19267347

                Так я не только о шторме. Все программы бы работали сильно быстрее если сделать у cpu условные 10ггц.
                Вот reindex проекта, использование диска было по-минимуму.
                image
                Качество не получилось, прошу прощения :)

                • Fesor
                  /#19267433

                  Все программы бы работали сильно быстрее если сделать у cpu условные 10ггц.

                  нет. Еще раз — проблема не в CPU у 90% приложений. Проблема в работе с памятью.


                  Вот вы PHP разработчик, да? Помните выход php7? Мол "теперь в 2-3 раза быстрее". Вы же понимаете что это "быстрее" было не потому что у вас вдруг дополнительно частот стало больше, а потому что сильно оптимизировали работу с памятью, повысили локальность данных, уменьшили количество кэш мисов процессора.


                  А потому ваш слэк или шторм будет педалить одинаково что на 5Ghz что на 10Ghz. А вот скажем рендринг картинки в каком vray будет да быстрее порядочно.


                  Вот reindex проекта, использование диска было по-минимуму.

                  А теперь попробуйте сделать так — понизьте частоты вашего процессора и повторите эксперемент. И попробуем найти корреляцию суммарного времени построения индекса от частот CPU.

                  • iproger
                    /#19268307

                    Вот вы смеетесь, а я не поленился и проверил. Хотя погрешности наверняка имеют место быть.
                    8700k 5.0 3600, ssd обычный: reindex 17:00 sec.
                    8700k 3.0 3600, ssd обычный: reindex 28:00 sec.

                    Предварительно несколько раз прогнал ради разогрева кэшей. Конечно, 3.0 — нижняя планка для настольных процессоров сейчас, но результат показательный.

                    При этом согласен что io тоже в равной степени медленное. И скорость действительно сильно зависит от оптимизации кода.
                    На тех же Райзенах очень важна частота и вид оперативы, разницу даже видно невооруженным глазом. А у Интела тащит кэш.
                    Ну это мое мнение.

                    • Neikist
                      /#19268315

                      Ну так то и целероны всякие в бюджетных железках используются.

                      • iproger
                        /#19268319

                        А каким боком они?
                        В тесте выше тогда надо было отключить 2-4 ядра и оставить 2. Тогда частота повлияла бы еще сильнее.

                        Я бы не стал сравнивать i7 с селеронами. Как минимум из-за большего кэша и большего числа ядер.
                        Да и во многих многоядерных процессорах частота часто в пределах 3.3-3.6.

                        • Neikist
                          /#19268625

                          Ну я к тому что на них еще как бы не на порядок все медленнее бы делалось. Так что я с вами согласен что не только I/O слабое место а процов давно хватает.

                    • PsyHaSTe
                      /#19270451

                      По двум точкам трудно судить. Сделайте замеров 20 с шагом 0.1, тогда корреляция будет четко видна. Если, конечно, это не слишком сильно вас затруднит.

          • Vilgelm
            /#19268431

            Что до вопроса с электроном и намеки что приложение на электроне потребляет ресурсов неадекватно больше чем нативное решение — пока это все пустые домыслы

            У Telegram есть нативный клиент и клиент в Electron (даже несколько). Можно сравнить. Но учитывая, что нативный клиент умещается в 47 MB (если там не миллион чатов), а сам по себе пустой процесс Chrome ест около 60, то сравнение будет явно не в пользу Electron.

      • remzalp
        /#19263835

        Ок, немного снизить потребности поможет Java или если совсем C++ — QT, оно работает уже много где, так что более половины перечисленных платформ (без учета тонкостей) смогут поддерживаться одной кодовой базой.

        • Fesor
          /#19265699 / +2

          поможет Java

          я сейчас смотрю на то сколько жрет IDEA и VSCode на одном и том же проекте (и да я понимаю что IDEA может делать много больше того, что я использую, но оно ж мне и не нужно) и как педалит их UI, и у меня возникают сомнения.


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


          QT

          Помню году так в 2009-ом ковырялся с их этим QtQuick. Мне идея дико нравилась и реализация была неплохой. Во всяком случае писать софт под десктоп не на QT мне тогда не хотелось. Однако, беря в расчет то как реализован Qt, сомневаюсь что получится что-то существенно лучшее.


          смогут поддерживаться одной кодовой базой.

          Вот только я не хочу писать ни на Java ни на C++. А хочу например на Rust всю бизнес логику писать. Потому что type safe и прочее и прочее. Или на хаскеле.


          На данный момент существуют два решения для интероп языков — webassembly (все компиляторы на базе LLVM в целом уже умеют в него компилить) и graalvm (оч интересный проект как по мне). А потому опять же — электрон выыигрывает тут так как в отличии от ораклавской graalvm все основано на открытом стандарте.

          • 0xd34df00d
            /#19266881

            Однако, беря в расчет то как реализован Qt, сомневаюсь что получится что-то существенно лучшее.

            Хм, почему? Да и старые добрые императивные qtwidgets никто не выпиливает.

            • Fesor
              /#19267447

              ну если мне память не изменяет, они просто все контролы на opengl запилили. Почти как это делают браузеры со своим html+css. Ну или вы можете сделать на webgl ;)

              • 0xd34df00d
                /#19267695

                Тормоза возникают-то не из-за OpenGL. Я бы ещё понял, если бы вы, например, на их V4 (который кастрированный V8 и который занимается выполнением их диалекта ecmascript) кивнули.

                • Fesor
                  /#19268255

                  Тормоза возникают-то не из-за OpenGL.

                  тормоза происходят из-за блокировки потока перерисовки этого UI. А заблокировать этот самый поток легко когда он один.


                  Всякие же сервис воркеры для фронтэндера это уже ух, сложна. Ну то есть требует уже уровня повыше среднего.

                  • 0xd34df00d
                    /#19268267

                    А заблокировать этот самый поток легко когда он один.

                    Вот как раз классический GUI-поток (с xlib) в иксах ровно один.


                    А если у вас синтаксис декларативный, модельки эти все там, и руками ничего императивного вы не пишете, то достаточно умный™ компилятор и рантайм могут это всё раскидать по потокам.

              • Alex_ME
                /#19268111

                Подождите, я правильно понял, что они берут браузер, который написан умными людьми на C++/Rust и который с помощью OpenGL хардверно ускоренно рисует всякий HTML-GUI, и затем из всего HTML-GUI используют canvas, в котором с помощью OpenGL на JS рисуют свои кнопочки?

                • Fesor
                  /#19268259 / +1

                  все так. Смысл в этом небольшой конечно, разве что полная свобода и полная независимость от вендора браузера.

          • poxvuibr
            /#19266885

            электрон выыигрывает тут так как в отличии от ораклавской graalvm все основано на открытом стандарте.

            Ну стандарта может и нет, но код то у GraalVM открытый

        • AllexIn
          /#19265731

          Не не не. Писал на QT под мобилки — очень специфично и уж точно «одной кодовой базой» не пахнет.

      • Simplevolk
        /#19263879

        Вот поэтому я использую Телеграм, а не Слак. Потому что телеграм не отъедает по гигабайту памяти. И легковесный. Сейчас, в 2018-м это ценно.

        • algotrader2013
          /#19263905

          Отличный пример, кстати. Слак, у создателей которого сейчас деньги не кончаются, а они жмотятся на портирование в нативный код. И телеграм, который с первой версии с намного меньшими ресурсами делался как надо (правда Дуров начинал с реально сильной командой олимпиадников, а не энтерпрайз макак). Но, к сожалению, инвесторы активно раздувают капитализацию слака, тем самым говоря, "красавчики, продолжайте в том же духе".

          • fatronix
            /#19264309

            Если бы в нём еще память не текла, было бы вообще замечательно. За неделю аптайма с 50 мегабайт жиреет до 500.

            • IgnisNoir
              /#19265495

              Это вы о Слаке или о Телеграме? О_О просто у меня ни та мни там не течет. А комп я не выключаю месяцами

              • fatronix
                /#19265585

                О телеграме. Сейчас он запущен с утра пятницы (3 дня) — уже съедено 220 мегабайт.

              • faiwer
                /#19265785 / +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.

                • stavinsky
                  /#19266993

                  что говорить у меня вкладка хрома с gmail может за сутки съесть 5-6 гиг

                • Vilgelm
                  /#19268437

                  Аналогичная ситуация, вы не одни.

                • Chamie
                  /#19271101

                  Может, просто кэши наполняют?

                  • faiwer
                    /#19271643

                    Думаю у каждого текущего приложения может быть своя проблема. Скажем какие там у tint2 (написан на C) могут быть кеши? А разпирает его порой больше 2 GiB. Shutter (python) растёт как на дрожжах с каждым новым скриншотом. Явно течёт память. Браузеры, те и правда могут что-то жесточайше кешировать. Потом текут отдельно взятые табы в них. Вот у меня открыт inoReader в Vivaldi. Кушает он сейчас немного не мало — 1400 MiB. Доходило и до 3+ GiB. В нём реклама течёт. Автор об этой проблеме знает — говорит покупайте премиум, там без рекламы. Skype и Slack текут потому что электронруки кривые, видимо, у авторов. Кто знает. Тут надо детективную история по каждому случаю проводить.

          • LexS007
            /#19265059

            Вот тут да, телеграм отличный пример, уже почти под каждую платформу вторые переписанные с нуля клиенты выпустили.

        • GrigoryPerepechko
          /#19266131

          Телеграмм под macOS после запуска и 5 минут использования отъел 650MB
          Он написан на плюсах и свифте, работает фантастически быстро. Но с памятью не всё гладко.

      • some_x
        /#19264117

        Но есть же нормальные кроссплатформенные инструменты: .NET core, xamarin, QT, java. Зачем выбирать выбирать тормозной WEB?

        • YemSalat
          /#19264139

          Покажите мнe кроссплатформенное приложение нa той же джаве, которое не «жрет» ресурсы.

          • PsyHaSTe
            /#19265925 / -1

            По сравнению с целым электроном оно не «жрет» ресурсы, а вежливо подъедает с уголка.

          • gotozero
            /#19266801

            Жор ресурсов не единственный компонент злобы на электрон.
            Оно при этом еще и тормозит.

            Я готов простить жор Идее например, если она выполняет важные задачи и довольно быстро.

            • YemSalat
              /#19275133

              Опять же это зависит в основном от прямоты рук разработчиков. Выше ужe приводили в пример VSCode, который IDE на электроне и работает пошустрее того же вебшторма например.

        • evnuh
          /#19267597 / +1

          кросплатформенные нынче — это обязательно +iOS и +Android. Ещё желательно +web.

      • kpakozz96pyc
        /#19264359

        я не верю что телеграмм ест 600мб, хоть убейте, ни разу не замечал ни единого лага в нем, в то время как slack жутко тупит просто при разворачивании его из трея.
        Вот сейчас я на них смотрю — слак — 500мб и 4 канала +8 чатов, телеграм 32мб 20 каналов и 30+ чатов.

        При умножении на 6 — вы тоже ошибаетесь — непосредственно написание кода — это не 100% разработки. Спецификации, дизайн и аналитика едят гораздо больше, при этом шарятся между платформами процентов на 90.

        • defaultvoice
          /#19264689

          Да нет, было такое несколько раз. Но они буквально в течение пары дней выпускали апдейт, который это фиксил (загадочные надписи в чейнджлогах на манер «Performance improvements» были как раз об этом)

        • Vilgelm
          /#19268439

          Telegram начинает столько есть когда в нем около 1000 активных чатов и под 10 млн непрочитанных сообщений. Проверено лично.

          • PsyHaSTe
            /#19270477

            > 1000 активных чатов
            > 10 млн непрочитанных сообщений
            > Проверено лично.

            Хм…

            У меня только один вопрос — вы вообще спите?

            • sumanai
              /#19272563

              10 млн непрочитанных сообщений

              вы вообще спите

              Судя по всему не просыпается.

      • pansom
        /#19264371

        Телеграм отжирает 7мб оперативы. ЧТО Я ДЕЛАЮ НЕ ТАК?

        • khanid
          /#19267547

          В зависимости от. Допускаю, что у него память течь может где-то, но я не сталкивался. Основные цифры потребления телеги у меня умещаются в 100 Мб (да данный момент 87540 Кб) — у меня куча картинок и анимации, типа гифок, в общении обычно. В любом случае. Для телеги 600 Мб и больше — явно не норма. А вот для слэка, судя по комментариям, вариант нормы.

      • AlexTest
        /#19265147

        вот у меня пред глазами 2 приложения. Телеграм и слэк. Обе отжираютт 600 метров памяти
        Telegram 600 метров — жесть, что вы с ним делаете если не секрет?
        У меня 50-70 метров максимум:
        image

        • Neikist
          /#19265167

          Только что под виндой глянул — вообще 10 метров.

        • Fesor
          /#19265725 / +2

          image


          был запущен 12 дней. После перезапуска сходу сьел 190 метров.

          • Vilgelm
            /#19268445

            У вас точно нативный клиент, а не один из тех, что на Electron? Или сколько у вас чатов\каналов?

            • Fesor
              /#19268459

              групповых чатов штук 20, приватных — штук 100, может больше, не знаю где посмотреть. сообщений в день прилетает под пару сотен (почти все в мьюте). Нет не электрон — тот который официальный нативный на плюсах и все такое.

        • Self_Perfection
          /#19267297

          Я когда-то давно поставил у себя на мониторинг процесс telegram-desktop, так что могу показать

          график использования памяти telegram-desktop 1.3.14
          graph of telegram desktop RSS memory usage

      • PsyHaSTe
        /#19265901

        Эм, что вы с телеграмом делаете, что он 600мб ест? Я больше 100 в жизни не видывал, хотя у меня полсотни разных чатов и каналов с кучей картинок и гифок.

        Для сравнения, вкладка гмейла ест как раз те 600мб.

        • GrigoryPerepechko
          /#19266151

          На винде и macOS по разному.
          На macOS меньше 300 со старта у меня не получается — snag.gy/nlQiEX.jpg

          • unclechu
            /#19268499

            А с .jpg — это они ничего так придумали, прямо как вирусы .jpg.exe:
            image

      • unclechu
        /#19268495

        Они там свои тарифы просто так нарисовали?

        Маленький инсайд, — зачастую ответ на этот вопрос — да (без шуток).

      • Massacre
        /#19268541

        Это просто конкретно Телеграм течёт по памяти, его надо перезапускать через некоторое время и будет снова мегабайт 50-60. Слаку же это вряд ли поможет. Правильнее сравнивать с Мирандой.

    • Sabubu
      /#19263803

      Только не будет ли ваша софтинка выглядеть как серое окно с кнопками из 90-х? Посмотрите на мобильные приложения — пользователи привыкли немного к другому дизайну. Сможет ли ваше приложение асинхронно работать со всякими HTTP API, получать и передавать данные, синхронизировать их локально?

      Что касается C#, это хороший язык (типизируемый, компилируемый, со сборкой мусора и с ООП), но не знаю, насколько легко на нем писать не привязанные к винде приложения. Вы пишете, WPF, но это будет работать только под виндой.

      Что касается дельфи… он как бы немного устаревший.

      • j_wayne
        /#19264095

        > Только не будет ли ваша софтинка выглядеть как серое окно с кнопками из 90-х? Посмотрите на мобильные приложения — пользователи привыкли немного к другому дизайну.

        Но это же не проблема. Telegram Desktop имеет вполне обычный «web desktop app» вид. Но к ресурсам не сильно требователен, отзывчивость GUI тоже адекватная. На Qt написан.

        HTTP API, вебсокеты — все это в Qt есть. Для этого не обязателен браузер)

      • Solexid
        /#19264103

        .net standart + Avalonia.Ui. Одна кодовая база, работать будет на всём.

        • staticlab
          /#19264819

          А есть на Авалонию какая-нибудь адеватная демка, чтобы потыкать на разных платформах?

          • KvanTTT
            /#19265029

            Например AvaloniaILSpy, дизассемблер .NET.

            • staticlab
              /#19265187

              Если честно, контролы довольно мерзкие, причём на всех платформах сразу. Выглядят нисколько не нативно. На Убунте, к тому же, дропдауны в настройках не работают от клавиатуры. Рендеринг шрифтов ужасен. Копипаст через контекстное меню не работает. Активаторы по Alt в линуксе не работают. Контекстное меню по соответствующей клавише на клавиатуре нигде не работает. Вангую также большие проблемы с accessibility.


              Помимо прочего, разработчики приложения забыли, что на линуксе регистрозависимая файловая система, из-за чего приложение падает при правом клике на сборку (идёт запрос файла images\Delete.png, а директория называется Images).


              Вердикт: пока что крайне сырая библиотека, и использовать её для реального кроссплатформенного приложения не стоит.

              • staticlab
                /#19265405

                На Убунте, к тому же, дропдауны в настройках не работают от клавиатуры.

                Поправка: не работают с мышкой, только с клавиатуры.

      • kin63camapa
        /#19265293

        пусть мое приложение будет выглядеть как окно с кнопками из 98 винды, пускай оно будет на псевдографике (а лучше просто текстовое, я так и не сумел сделать так чтобы на мой 25 дюймовый монитор помещалось больше десятка сообщений), но если меседжер жрет 300 мегабайт памяти то в топку такой меседжер

        • Smokin
          /#19269227

          И кто будет пользоваться таким приложением?

        • Fesor
          /#19269903

          Вы же понимаете что телеграм это не просто текстоый меседжер? Стикеры, аттачи аудио, различные графические ресурсы (аватарки), форматирование текста, ну и webrtc, шифрование всего этого дела.

          Невидимая рука рынка так решила, что месенджеры отжирающие по 300 метров памяти нужны, значит они нужны. Иначе спроса бы небыло.

          Другой вопрос что возможно рынок так решил потому что качественно лучше ничего нет. Может быть вам стоит сделать свой продукт качественно лучше чем все что есть на рынке, и возможно на ваш продукт будет высокий спрос.

          • Massacre
            /#19273093

            Альтернативы-то нет уже (был скайп, убили). Если вы считаете, что пользователям нужны именно тормознутые и жрущие мессенджеры, то вы это зря. И почему именно webrtc?

    • biseptol
      /#19267187

      Сколько времени и денег будет стоить написать и поддерживать Slack на 1) WinAPI, 2) Cocoa, 3) Cocoa для iOS и еще 4) на Java/Kotlin для Андроида? И 5) веб версию? И чтобы это все красиво и одинаково выглядело?

      Поставьте себя на место даже не владельцев бизнеса, а менеджера разработки, перед которым стоит выбор: логистический и управленческий ад синхронизации пяти разных codebases и содержание команды в (как минимум) пять человек на мартышкин труд писать одно и то же на разных языках. Либо взять проверенный и работающий для 99% Electron и бурно развивающийся и богатый возможностями JS+React+HTML5+CSS, в которых JSON можно загрузить одной строчкой, а анимацию сделать двумя.

      Electron — это, возможно, крайность, но тот же React Native — это вполне себе способ кросс-платформенной разработки, если есть задача сделать продукт, который можно развивать и поддерживать.

      • iPilot
        /#19267341

        Epic Games (создатели Unreal Engine) срубили сотни миллионов бабла на Fortnite, и вдруг снизили цену на лицензию этого самого Unreal Engine. Тот случай, когда денег слишком много для конкретной группы лиц. Видимо, другие намного жаднее.

      • khanid
        /#19267585

        За различные платформы в части UI не скажу, но вот вопрос у меня возникает. А что, логика приложения принципиально от этого будет отличаться? Я просто не могу представить, какой функционал WinAPI может логике программы-чатика понадобиться?
        Переписывал тут старое одно своё приложение года 2 назад с win7+mysql на centos + mariadb. Всё, что мне пришлось поправить, это работу с сокетами и БД — по странице кода на каждый. Различия в ОС, да. Но вот в остальной части ничего не трогал — стандарты c++ не от ОС же зависят.
        Но у меня нет графики. Даже если графика задействована, то она, по-прежнему, обёртка над логикой, прослойка между пользователем и логикой. Если же логика привязана к специфическим для ОС элементам управления, то я глубоко задумался бы.

      • Simplevolk
        /#19268777

        А потом в один прекрасный момент, выходит легковесный и быстрый аналог слака\скайпа и все с радостью в одно мгновенье пересаживаются на него (WhatsApp,Telegram vs Скайп).

        • Neikist
          /#19268813

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

          • Fesor
            /#19269913

            звонки у слэка тотго же тоже неплохие, как и шаринг экрана. Так что остается только инерция корпоративного сектора.

            p.s. за последние 3 года пользовался скайпом исключительно через web.

            • Neikist
              /#19270041

              Так слак та же хрень, единственное чем лучше скайпа — наличием пары доп функций. А тормозит также.

            • faiwer
              /#19270145

              Несколько раз пробовал пользоваться звонками slack-а. Не смогли. То не заводится, то не слышно, то приложение уходит в какой-то вечный цикл, то ещё какая-то чертовщина. Так ни разу не удалось нормально воспользоваться им. А desktop-версия под linux у меня даже "взять трубку" ни разу не смогла (в отличии от браузерной).

    • fiftin
      /#19267223

      Можете скинуть ссылку на ваше приложение? Хотел бы оценить насколько крут UI написанный на MFC.

    • ivan386
      /#19268269

      Ну десктопное приложение на JS можно было писать под Windows со времён IE 5. Но единственное которым я пользовался это был интерфейс для ffmpeg или подобного конвертера видео.


      Интересно в современой винде работают hta или нет?

      • Fesor
        /#19268329

        HTA все еще должны работать если запускаются в режиме совместимости с 9-ым IE.

    • Anton131313
      /#19275869

      Красивый UI на винапи, поржал с быдлокодера.

  3. quwy
    /#19263381 / +1

    Гораздо уместнее было бы сравнение с раковой опухолью.

  4. Dimash2
    /#19263405 / +2

    А я хотел бы защитить Электрон. Я запускал под электрон бету версию пульта управления Windows с Айфона. Писал для себя, в продакшн не запустил, потому что были баги. Имел не малый опыт по написанию JS софта под еще старые ipad при помощи webview, но окружение тогда было запрограммировано Xcode программистом.

    Мое личное мнение, что Slack тормозит, потому что именно его код написан плохо, а не потому что он на Electron. Так как я часто пишу разный высоконагруженный код в браузер, собственно я пишу разный софт, который работает из под браузера и с большими данными и с разными анимациями, то я вас уверяю, что да, запуская софт при помощи Электрон — вы подтягиваете много в оперативку, но не он прямо ответственен за баги, а именно реализация.

    Я искренне, вообще не понимаю, как разработчики уровня Slack позволяют такие тормоза, ведь это всего-лишь управление текстовыми данными и так как js позволяет все делать асинхронно, то нагрузку можно прекрасно балансировать.

    Может меня заминусуют, но я люблю писать JS софт, это невероятно просто, но я знаю как писать его так, чтобы он работал быстро и даже парюсь, чтобы он не мучал батарейку, но мне не нравится, когда просто плохой софт выдают за проблему платформы.

    Тот же Atom, давным давно был достаточно быстрым, но сегодня — он на столько тормознутый, что им невозможно пользоваться, но пробелма там же не с Electron, а именно с реализацией подсветки синтаксиса. На сколько я помню, все Webview редакторы используют одну и ту же библиотеку подсветки, что и приводит к абсолютно одинаковым тормозам, что Atom, что Adobe. Отсюда у меня простейший вопрос, кто те разработчики, которые это планировали и решили, что и такие редакторы стоит выводить в продакшн да еще и не фиксить столько лет? Но многие люди всеравно опользуются, не смотря на то, что редактировать уже даже стандартный файл не является возможным.

    Я посмотрел свой диспетчер задач, никакой безумной активности в простое (именно активности) я не заметил, но из Electron софта у меня только Slack. Но знаете, что больше всего сжирает ресурсов в Скайпе? (Сейчас найти не могу, но раньше так было) — рекламный Баннер ), приходилось раньше открывать другой окно Скайпа, чтобы баннер ушел и нагрузка на CPU ушла.

    • PsyHaSTe
      /#19265935

      Может меня заминусуют, но я люблю писать JS софт, это невероятно просто, но я знаю как писать его так, чтобы он работал быстро и даже парюсь, чтобы он не мучал батарейку, но мне не нравится, когда просто плохой софт выдают за проблему платформы.

      На сколько я помню, все Webview редакторы используют одну и ту же библиотеку подсветки, что и приводит к абсолютно одинаковым тормозам, что Atom, что Adobe. Отсюда у меня простейший вопрос, кто те разработчики, которые это планировали и решили, что и такие редакторы стоит выводить в продакшн да еще и не фиксить столько лет?

      Есть подозрение, что если никто не смог написать библиотеку лучше Webview, то может это проблема платформы и написать такую производительную библиотеку невозможно? По чисто объективным причинам, примерно тем же, почему хорошо структурированное нормализованное апи сталкивается с проблемой N+1.

  5. advance
    /#19263421 / +1

    Это, конечно, всё очень далеко от реальности…
    Не поймите не верно- я сам android-разраб и пишу исключительно натив, и у меня JS-приложения тоже вызывают негодование.
    Но IT правит бизнес. И только бизнес. И он двигает индустрию, разработчики к этому не причастны.
    И вот когда начинаешь считать деньги- выясняется, что JS-приложения очень дешево обходятся. В том числе и с косяками. А еще выясняется, что время разработчика стоит дороже вычислительных ресурсов пользователя. Точнее эти ресурсы для бизнеса бесплатны почти совсем. И этими ресурсами бизнес расплачивается за скорость и дешевизну JS-фреймворков.
    И тут два выхода:
    1. Заставить бизнес платить за ресурсы пользователя. Не знаю чем и как, но это бы сделало фактор реально важным. Минус- много игроков уйдут с рынка
    2. Стандартизировать API или вообще заставить всех поддерживать JS. Но тут минусов еще больше:
    Все перейдут на что-то типа Chrome OS и конкурировать останется мало чем.
    Внезапно выяснится, что подход с реализацией интерпретируемого языка с нестрогой типизацией сам по себе затратен. Ведь для системы уже нет разницы между Boolean и String. Экономить просто не на чем. Плюс в JS придется вводить много жизненного цикла сущностей, к чему он просто не готов. На выходе получаем неповоротливую тупую монстро-ось, но зато да- в JS локально можно будет из коробки, да. И бизнесу обойдется в копейки.

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

    • Dimash2
      /#19263431

      Как JS разработчик, я считаю, что скорости JS достаточно для реализации большинства софта информационного типа, типа базы, выборки, складской контроль, общение. Но вот конкретная реализация губит, потому что вход в JS слишком простой и видимо реализуют приложения без должного уровня. Вы же, наверное, знаете Java, раз андройд разработчик, то вы, думаю понимаете, что на определенном уровне для Десктопов Java тоже медленная, но на самом деле — нет.

      Вот интересно, когда JS, NodeJS и С работют вместе передавая все координаты с тачскрина телефона на Windows и управляют курсором, управлением текста и тд, то разве этого может быть мало для написания чатика? Slack тормозит, потому что сделан плохо, а не потому что Electron

      • advance
        /#19263479

        На самом деле давно уже не писал на Java- проекты довольно необычные, часто приходится переключаться на C, а в основе уже везде Kotlin.
        И я написал это потому, что дожился до написания собственных интерпретаторов и виртуальных машин (не для JS. проприетарщина). И примерно с этого момента начинаешь понимать, что реализации слабой типизации без ЖЦ, или, например stateless- они все имеют ряд именно концептуальных проблем.
        Да, разные реализации софта на JS будут показывать разную производительность. И на машине с i5 и выше, Вы, скорее всего, не заметите разницы в работе одной и той же простой логики на JS и Java и нативе. Но, чем логика жирнее, и чем машина слабее- тем больше будет проявляться разница.
        Факт в том, что так или иначе- чтобы JS вращался нужно больше ресурсов. Ведь JS-примитив содержит больше информации, чем, например, C-примитив. Плюс нужно больше компонент, чтобы этот примитив обслуживать, адресовать. И это всё добро, призванное облегчить жизнь разрабу, надо где-то хранить. Конечно же, в оперативе пользователя.
        Так что нет- одна и та же логика не может работать одинаково быстро на JS\Java\C чисто математически.
        Со Slack другая проблема- ни Electron ни JS сам по себе не могут корректно работать с ЖЦ Win\Mac\etc… И не смогут- JS разработан дня веба, для него предназначен, и в нем должен оставаться. Попытки запихнуть JS в приложение- это как ехать на санках по асфальту летом- это реально, но не эффективно. Но дешево, если под рукой только санки. Так что, люди в Slack не криворукие, просто (слишком) экономные

  6. Alexufo
    /#19263439

    с 30:25

  7. Dimash2
    /#19263465 / +1

    Я хотел бы напомнить, что в свое время Flash сыграл огромную роль в формировании интерактивного веба, и потому не нужно использовать Flash как ругательство. Он появился в удачное время, отслужил свое и умер.

    Дождемся нативной поддержки JS и все )

    • Flux
      /#19263565

      Дождемся нативной поддержки JS и все )

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

      • 0xf0a00
        /#19263997

        Ахах… это будет началом смерти JS. В свое время за простоту поплатился Delphi, когда тысячи макак у которых из знаний только как Button1 на Form1 положить хлынули в десктоп.

        • ValdikSS
          /#19272983

          Эта Button1 на Form1 компилировалась в 400 КБ нативного кода, не тормозила и не потребляла памяти.

          • sentyaev
            /#19273105

            В те времена говорили, что 400КБ это нереально много для приложения с одной кнопкой.
            Я к тому, что история повторяется и уже не первый раз.

            • ValdikSS
              /#19274125 / +1

              Это действительно много, даже по нынешним меркам. В Delphi свой собственный графический фреймворк VCL, именно он дает такой размер файла. Он достаточно эффективен, поэтому ему прощалось.
              Можно было писать без него, на чистом WinAPI, или с использованием сторонних фреймворков, тогда размер файла был от 12 КБ, насколько помню.

              Современный Delphi очень продвинут, на нем можно графические программы под почти все ОС писать, а с помощью сторонней реализации Object Pascal — еще и под WebAssembly.

    • Scf
      /#19267115 / +1

      Меня заголовок статьи выморозил в обратную сторону — как будто они заявили, что электрон имеет все преимущества flash — компактность исполняемого файла, обратную совместимость, эффективность, малое потребление памяти...


      Flash не просто так был стандартом для анимации и сложных веб приложений.

      • sumanai
        /#19267809

        Flash не просто так был стандартом для анимации и сложных веб приложений.

        Другого в те времена просто не было.

      • YemSalat
        /#19273569

        > компактность исполняемого файла
        если нe учитывать «компактность» самого плеера

        > обратную совместимость
        AS2->AS3 разве были обратно совместимыми?

        > эффективность
        как это определяется?

        > малое потребление памяти…
        и немалое потреблениe процессора

        Это я не к тому что флэш «плохой», но своих проблем у него хватало.

  8. porn
    /#19263481

    Есть проблема с отсутствием нормальных кроссплатформенных GUI фреймворков. Поставим целью написать лёгкое десктопное приложение на Rust — как реализуете GUI? Подтянем GTK/Qt/что ещё, либо сделаем API, с которым может работать много разработчиков.

    • some_x
      /#19264161

      Несколько вариантов:
      1) Можно использовать подход Xamarin`а: пишем общую логику на Rust, а GUI реализуем нативно.
      2) Если нам не нужно поддерживать старые платформы, то можно использовать гибридный подход: использовать для отрисовки стандартную для платформы WebView, а код отрисовки и логику напишем на Rust.
      3) А что собственно не так с Qt, на мой взгляд этот тот самый «нормальный кроссплатформенный GUI фреймворк»

      • Neikist
        /#19264181

        использовать для отрисовки стандартную для платформы WebView, а код отрисовки и логику напишем на Rust.

        react native наоборот?))

  9. PloAl
    /#19263553

    Статья оригинал не такая свежая.
    Slack не пользуюсь, часто запущен Whatsapp десктоп, диспетчер задач постоянно на втором мониторе, потребления ресурсов Whatsapp не замечал, 300мб памяти занимает, соглашусь не мало. Также есть свое приложение на electron, нагрузки на процессор в свернутом режиме в фоне, тоже не замечал, памяти всего 111мб.
    Также пользуюсь VS code, там порой видна в фоне какая то нагрузка, периодически бывает до 10%, но это совсем другое приложение.

    • staticmain
      /#19264093

      Статья оригинал не такая свежая.

      Сейчас slack отъедает от 1.5 ГБ и выше на многоканальной переписке.

      • Neikist
        /#19264169 / -1

        Ы, недавно себе edc ноут за копейки купил, чтобы например в деревню ездить, на природу взять, иногда на работу. Так там всего 3 гига памяти))

  10. anttoshka
    /#19263985

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

  11. kemsky
    /#19264293

    Flash для десктопа был уже 10 лет назад и есть до сих пор, называется Adobe Air. Причем писать можно было и на js, точно так же как на электроне сейчас.

    • iLLuzor
      /#19267915

      AIR приложения никогда не жрали столько оперативки. Я когда-то писал игру под ios/android с кучей анимаций и физикой, и укладывался в 40 мегабайт оперативки.

      • Fesor
        /#19268261

        ну да, хай рез сплэш скрин для загрузки или крутой пак иконок под тот же хай рез туда не запихивали.

  12. justboris
    /#19264675 / +2

    Справедливости ради, замечу, что в 2017 году (после выхода этой статьи) команда Slack провела работу по уменьшению потребления памяти, результаты которой изложены здесь: slack.engineering/reducing-slacks-memory-footprint-4480fec7e8eb

    Интересно посмотреть на независимые результаты замеров после этих изменений.

    • Static_electro
      /#19266963 / +1

      вот прямо сейчас на домашнем ноуте «десктоп» клиент слак съедает до гигабайта легко и непринужденно. А поскольку ноут старый и памяти там всего 4 га — то каждое разворачивание слака из «неактивного» режима превращается в повод сходить поставить чайник, например. Подгрузка истории и переключение каналов — тоже приключение, с тоской вспоминаешь, как раньше текстовые чаты были текстовыми чатами.
      Мне менять ноут или слак? Даже не знаю… на ноуте я еще и поиграть могу, и поработать — visual studio и та себя отзывчивее ведет.

      • justboris
        /#19267101

        Я бы сменил Slack. Ибо зачем кушать кактус, если он колется.

        А если Slack – это требование для работы, то будет уместно попросить работодателя об апдейте рабочего железа.

        • Static_electro
          /#19267239

          Не, слак домашний, не рабочий. Да и вопрос риторический, в общем-то. Я хотел ответить на


          Интересно посмотреть на независимые результаты замеров после этих изменений.

          ну и увлекся слегка, потому что горит)
          Кратко — слабые машины умирают всё так же, как и раньше.

  13. vladbarcelo
    /#19265263

    • Оф. поддержки реакт-нэйтив для чего-либо кроме мобильных ОС нет
    • VSCode написан на электроне и каких-либо проблем с его производительностью (в том числе на маке) я не вижу
    • Можно призывать жаловаться и отказываться от технологии, а можно её совершенствовать

    • Neikist
      /#19265351

      Стоит признать что тот же вим работает явно побыстрее)) Впрочем да, vs code наверно единственный более менее адекватный продукт на электроне, и то насколько слышал там ооочень многое в натив переписали.

      • Terras
        /#19265429 / -1

        Учитывая то, что Vs Code — это один из ключевых козырей Microsoft в борьбе с Java — там его так вылизывают, переписывают и полируют, что от самого электрона, там только одно название.

        • vladbarcelo
          /#19265543

          от самого электрона, там только одно название

          VSCode на 90% написан на TS/JS, а не на нативщине.

  14. river-fall
    /#19265727

    Помню, мы смеялись над Delphi 7, когда программа без кода с одним пустым окном интерфейса в скомпилированном виде занимала 500 килобайт.

    Прошло 15 лет, и вот результат.

    • 0xf0a00
      /#19266135 / +2

      При этом «плохой» Delphi хоронят ежедневно, зато «хороший» JS (Electon) цветет и пахнет.

  15. achekalin
    /#19265819

    Мне всегда «нравились» компании, выпускающие жутко неоптимальный софт, со словами: «а чего его оптимизировать, юзеры и так пользуются!»
    Банально: то, что Slack висит в виде десктоп-клиента на каждой машине команды разработчиков, и жрет как не в себя — команду Slack не волнует?

    • DracoL1ch
      /#19266831

      Пока разработчики сидят в слаке, слаку это волновать не будет. Вот если ВДРУГ начнется миграция на какой-то новый клиент, тогда и зашевелятся. Все гиганты такие, ВСЕ.

      • achekalin
        /#19266877

        Тут все упирается в то самое «а куда пойти?»

        Другое дело что разработчики слаки, вероятно, в слаке же и сидят. Получается, «плачут, колются, но продолжают потреблять кактус сидеть в слаке»?

        • DracoL1ch
          /#19266931

          Конкурентов нет, потому что рынок перенасыщен однотипными решениями, а разрабатывать что-то не из электрона могут себе позволить лишь ооочень богатые стартапы. Которым этот рынок уже слабо интересен, по первой причине.
          Ну и проблем у разработчиков, я уверен, нет. Как те посты одного из разработчиков (или просто хорошего тестера) Chromium — habr.com/post/420579 habr.com/post/421153
          Пока оптимизация стоит дороже плашки памяти — картина меняться не будет. Только голосование ногами, только хардкор. Скайп до сих пор остается корпоративным решением, потому что он у всех есть, а не потому что он хороший. Аналогичное зависание может постичь и слак, поэтому все спокойны.

  16. k12th
    /#19266189

    Ни в коем случае не оправдываю прожорливость слака, но вот что меня удивляет — стремление инсталлировать себе в систему всякую ерунду. Что там такого есть в чатиках, какая такая функциональность, что надо ставить приложение? Что такого умеет десктопный электрон, чего нету в веб-версиях? Нотификации блимкают, гифки в #offtop крутятся, мессаги отправляются. Давайте еще джиру в webview завернем, а чо.

  17. kuraga333
    /#19266573

    Почти по теме: Если приложение «течет», то не факт, что именно его, или языка, разработчики виноваты: sourceware.org/bugzilla/show_bug.cgi?id=14827. Да, да. И буду признателен, если подскажете, как привлечь к этому внимание.

    А совсем по теме, ИМХО: разделяйте: JS, W3C APIs, browser's VM. Здесь ругают только последнее, вроде. Хотя и первые двое не идеальны, но все же — разделяйте!

  18. Alex_ME
    /#19266807

    Мне тоже не нравится электрон, и, иногда смотря на современные тенденции, мне хочется горько произнести "что же с нами стало?". котэ


    Но вот какие есть кроссплатформенные UI, пусть для windows/linux/mac (мобилки в расчет не берем, это целый отдельный мир)? Qt (есть биндинги к другим языкам, например pyqt), GTK (тоже есть биндинги, например GTK#), JavaFX, Swing, Mono WinForms, Avalonia (хоть и сырая). Тысячи их.

  19. yuriyg_ua
    /#19267399

    Почему-то все стали обсуждать JS vs. Qt/Delphi/C#/Java как-то забывая, что, основная проблема не JS и не в Electron, а еще один инстанс Хрома. Главное преимущество JS в том, что в нынешних реалиях, браузер (а следовательно и JS) есть практически на любой платформе, чего не скажешь ни о Windows, ни о .Net, ни о JVM. Но это разумеется относится к UI. Поэтому, как только найдут решение как запускать JS приложение отдельным клиентом без дополнительной нагрузки в виде целого браузера (или же в Гугле что-то сделают с Хромом, т.к. будет расти количество приложений, использующих его) — пафос таких статей станет ненужным. Но когда это произойдет — это тот еще вопрос.

    • serf
      /#19267789

      Что-то странное пишете. Сам JS/движок запускается в виде node.js процесса (main process), то есть как раз «без дополнительной нагрузки в виде целого браузера». А вот уже UI часть требует браузера, потому что как ни странно UI это HTML страница отображением которой как раз браузер и должен заниматься.

      • yuriyg_ua
        /#19269709

        Т.е. вы предполагаете, что основную нагрузку создает на память нод процесс, а не браузерный? Очень сильно сомневаюсь, если не сказать больше.

        • serf
          /#19269749

          В моем комментарии никаких предположений нет, но есть указание на то что JS приложения и UI приложения это разные вещи. Нодовский JS процесс это относительно легковесная штука, при этом очевидно что UI процесс отвещающий за ренеринг HTML очевидно тяжелый как и сами браузеры тк это и есть по сути браузер. На самом деле никто не запрещает делать приложения на Electron без окон, то есть только с main процессом.

    • Alex_ME
      /#19268103

      Главное преимущество JS в том, что в нынешних реалиях, браузер (а следовательно и JS) есть практически на любой платформе

      Поэтому, как только найдут решение как запускать JS приложение отдельным клиентом без дополнительной нагрузки в виде целого браузера

      Но ведь вы только что назвали (и верно) такое важное преимущество JS, как то, что браузер уже скорее всего установлен. Так зачем изобретать костыльный велосипед для запуска JS без браузера, когда есть браузер? Просто запускайте приложение в браузере, не скачивая и не запуская отдельный инстанс.

      • yuriyg_ua
        /#19269727

        Да, всё правильно. Но использование браузеров, как кросс-платформенного UI предполагает, что браузер уже запущен, и ваше приложение, как бы дополнительно запускается внутри данного инстанса. Если же для каждого приложения будет новый инстанс браузера — то это уже будет слишком. А вот когда таких приложений станет слишком много, то командам браузеров придется над этим задуматься и выпускать или легковесные варианты, либо же делать так, что такие приложение будут запускаться как бы «внутри» текущего инстанса браузера и не поднимать много разной ерунды для каждого инстанса. Но это только благие пожелание, наверняка всё ограничится тем, что «да, добавьте памяти».

      • PsyHaSTe
        /#19270511

        Это немного поможет потреблению памяти (60мб на процесс, полагаю), но гигабайты не вернет, и производительность будет примерно такая же. Зато если условный «слак» в такой архитектуре зависнет, как это часто бывает, то он может утянуть с собой все электроны и браузер с вкладками в придачу.

  20. xFFFF
    /#19267537

    Полностью согласен с автором)

  21. serf
    /#19267771 / +2

    Зачем сразу годную технологию хоронить, может просто дело в криворукости разработчиков десктоп клиента Slack. Посмотрите на Visual Studio Code, тормазит? У меня вот сейчас есть проект на котором местами WebStorm очень тормазит и зависает даже, а Visual Studio Code все пережевывает без заминок, летает просто.

    • sumanai
      /#19267829

      Сравнивать WebStorm и VS Code как-то это, некорректно.

      • Fesor
        /#19268265

        В целом да, но пока в webstorm не будет полноценной поддержки language server я предпочту использовать vscode для всяких там typescript-ов.

  22. vitaliy2
    /#19268223

    В статье сказано про JS, но JS не ест много памяти и не тормозит процессор. Да, инстанс действительно ест ~50 МБ памяти, но это далеко от указанного в статье гигабайта. Я потом напишу статью про это. Если вкратце, заставить потребить js много памяти практически нереально, если по крайней мере вы понимаете что делаете, а не новичок в языке.

    А высокое потребление именно из-за инстанса браузера, HTML и встроенных технологий. С потребление процессора — скорее всего, разработчики программы что-то сделали не так. Если у нас нет задач, мы просто по идее должны спать до прерывания/окончания sleep.

    Для сравнения, я пишу страничку (понимать как очень сложное веб-приложение), в которой js ест несколько мегабайт. Но в итоге при реальном открытии браузер может требовать и несколько сот мегабайт. Сделать что-то с этим нереально — твой код ест всего лишь несколько мегабайт. Дело не в js.

  23. vitaliy2
    /#19268239

    В статье сказано про JS, но JS не ест много памяти и не тормозит процессор. Да, инстанс действительно ест ~50 МБ памяти, но это далеко от указанного в статье гигабайта. Я потом напишу статью про это. Если вкратце, заставить потребить js много памяти практически нереально, если по крайней мере вы понимаете что делаете, а не новичок в языке.

    А высокое потребление именно из-за инстанса браузера, HTML (DOM, рендеринга и пр.) и встроенных технологий. С потребление процессора — скорее всего, разработчики программы что-то сделали не так. Если у нас нет задач, мы просто по идее должны спать до прерывания/окончания sleep.

    Для сравнения, я пишу страничку (понимать как очень сложное веб-приложение), в которой js ест несколько мегабайт. Но в итоге при реальном открытии браузер может требовать и несколько сот мегабайт. Сделать что-то с этим нереально — твой код ест всего лишь несколько мегабайт. Дело не в js.

    И да, кто считает, что дело в анимациях — нет, не в них. Они как раз работают быстро, т.?к. ускоряются видеокартой.

    • Massacre
      /#19268555

      В статье сказано про Electron, это всё вместе, включая инстанс браузера. Вот если будут писать совсем standalone GUI софт на JS, без браузера, HTML и DOM… А пока что проблема комплексная.

  24. Methos
    /#19269131 / -2

    давайте уж сразу вернемся к ассемблеру!


    ну я начинал с асма, да.


    страдал по поводу скорости и размеру, писал микропрограммы.


    а толк?


    все равно пришло время js и быстрой разработки


    мне кажется, проблема в коде и разработчике, а не в технологии


    если кодер не умеет оптимизировать, ему ничто не поможет

    • Splo1ter
      /#19269353 / +1

      Да хоть заоптимизируйся, так же скорости как в C/C++ не будет. К тому же всякого извиняюсь за выражения всякого г*на с собой тянуть незачем. Ладно бы еще можно было отключать api которые не нужно. Печально все это, когда в угоду бизнеса страдают конечные пользователи из за того что приложение написано на js и отжирает память (привет Slack).

      • Methos
        /#19270377 / -2

        вы наверное живете в каменном веке
        свой ноут я купил в 2011, тогда купил и поставил 16 гигов памяти, недорого это стоило
        ноут летает, памяти дохрена


        сейчас, 7 лет спустя, не знаю что там на рынке ноутов, не слежу, ибо не нужно, ноут прекрасно работает, но догадываюсь, что наверняка уже по 32 или 64 гигов у всех


        32 гига это ужас сколько памяти и стоит наверное копейки и если на ней запускать волковкоммандер в 64 кб, то наверное да, лишняя…
        но на дворе вроде 2018 и отчего бы эту память не загрузить то?

        • PsyHaSTe
          /#19270537 / +3

          16 гигов памяти в 2011 году? Не знаю как вы, а я только в 2015 году себе купил комп с 16 гб на вырост. У большинства друзей до сих пор 4..8 гигов памяти, и на всё хватает (браузер/игрушки/...). Видимо как раз потому, что они не пользуются дома никакими электрон поделками. Скайп, телеграм, игрушки,…

          Это не смешно, что установленные герои меча и магии со всей музыкой и ресурсами весит 700 мегабайт, столько же, сколько весит один только гмейл, и это в несколько раз меньше, чем слаки всякие… Неужели эта игра настолько проще, чем показать переписку с датами и рюшечками?

          • sentyaev
            /#19270855

            Неужели эта игра настолько проще, чем показать переписку с датами и рюшечками?

            Разве это не очевидно?

        • daggert
          /#19270965

          но догадываюсь, что наверняка уже по 32 или 64 гигов у всех

          Более 4 гигов редко встречаются у обычных людей. Кроме того еще 2 в ходу. Надеюсь вы не разработчик сайтов или SPA? Ну или хотя-б тестите свои работы на планшетах с 2 гигами оперативки и атомом?


          32 гига это ужас сколько памяти и стоит наверное копейки

          Ну если для вас это копейки… прикупите мне пару планок кингстона на 16? для меня 32 гига DDR3 прикупить сложно финансово даже за пару месяцев.

    • Massacre
      /#19270419 / +1

      Время быстрой разработки пришло ещё с Delphi, а JS на десктопе сейчас никакие оптимизации не помогут, да. Разве что случится чудо и он станет компилируемым в нативный код и перестанет требовать браузер в качестве движка.

  25. nedden
    /#19269461

    Вы забываете, что можно сделать кастомную сборку Electron, засунув туда кастомную сборку chromium, из которого можно выкинуть много лишнего.

    • quwy
      /#19270865

      Это лишнее только на десяток мегабайт уменьшит размер дистрибутива. В плане потребления ресурсов не изменится НИЧЕГО.

      • nedden
        /#19271037

        Да, я поспешил немного.

  26. Alexey2005
    /#19271341

    Часть проблемы заключается ещё и в том, что на данный момент попросту нет вменяемого нативного GUI. Единственное, что хоть как-то может претендовать на это звание — Qt, с которым вы вместо программирования будете заниматься трахотнёй со сборками и зависимостями. И где даже просто перенести проект на другую машину и заставить там собираться, особенно если перенос пойдёт транзитом через Github, то ещё удовольствие.
    Нужна нормальная кросс-платформенная GUI-библиотека в стиле Delphi VCL, только под все платформы. Именно библиотека, из которой линкер сможет извлечь в бинарник только реально исполняемый код, а не убогий фреймворк, где в бинарник улетит всё вплоть до драйвера XBox и реально исполняемого кода будет хорошо если 1%.
    Да что GUI, даже вменяемой кросс-платформенной TUI-библиотеки всемирный программерский гений так и не родил. Как-то вдруг выяснилось, что мол «консоль винды не умеет в цвет и всё сложно», в Linux «проблемы с зависимостями и всё сложно», а под Android просто «всё сложно».
    И именно в этом заключается один из основных факторов популярности Electron. Потому что это единственное GUI, которое просто, блин, работает на всех платформах. Которое реально кроссплатформенное. Для которого по щелчку пальцев через npm подтягивается что угодно, а не как во всяких C++, где работа с зависимостями как бы не напряжнее собственно программирования.

    • 0xd34df00d
      /#19271647

      Единственное, что хоть как-то может претендовать на это звание — Qt, с которым вы вместо программирования будете заниматься трахотнёй со сборками и зависимостями.

      А в чём проблема? Прописываете зависимости в CMakeLists.txt, и всё.

      • Alexey2005
        /#19271829

        Ну пока программирование идёт только под одну платформу, всё более-менее. А вот теперь представьте, что вы программируете в среде Linux, но вам требуется, чтобы при нажатии на кнопку «Build all» собирались бинарники ещё и под винду, под Android и под операционки от Apple. Вот тут-то и начинаются проблемы…
        А теперь ваш коллега тоже хочет поработать над проектом, и клонит его с Github'а. Но вот незадача — он сидит под виндою и тоже хочет, чтоб из-под винды собирались бинарники под всё сразу…
        И вот тут-то сразу начинаешь мечтать если не об Electron'е, то о чём угодно, лишь бы это был не C++ с его охрененно «удобными» кросс-компиляцией, системой сборки и менеджментом зависимостей. Сразу возникают ассоциации с древним авто, где вы больше времени проводите под машиной, чем в машине.

        • 0xd34df00d
          /#19272329

          Я б CI/CD настроил в любом случае. Неправильно это, деплоить нажатием кнопки Build all.


          И вот тут-то сразу начинаешь мечтать если не об Electron'е, то о чём угодно, лишь бы это был не C++ с его охрененно «удобными» кросс-компиляцией, системой сборки и менеджментом зависимостей.

          В C++ нет систем сборк и менеджмента зависимостей. А если у вас программа зависит только от Qt, то особых проблем не будет.


          Это просто плата за производительность и нативность. Ну и немножко легаси, да, увы.

          • sentyaev
            /#19272513

            А если у вас программа зависит только от Qt

            То скорее всего такая программа ничего интересного не делает. /sarcasm

        • 0xf0a00
          /#19275183

          В Delphi последних так можно. Кроме линуксового десктопа. А так я лично один и тот же проект собирал под винду, под мак и под адроид. Был бы айфон, еще бы и на него собрал.

  27. PurpleTentacle
    /#19271649 / +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
      /#19271711

      Как бывший разработчик игрушек на флэш я очень скорблю по временам, когда была простая крутая платформа Fash/Flex с богатейшими возможностями и кучей средств разработки для инди-разработчиков на рынке


      Многие годы назад я чисто из интереса покуривал эту тему — FGL, вот это все. Ребята, писавшие на флэше, нормально так денег рубили, были оригиналы, получавшие, бывало и 10К баксов за одну игру. Ну это если верить прохладным историям из сети :)

      • PurpleTentacle
        /#19271843

        На флеше была даже низкоуровневая обработка растра с доступом к пикселям. Это позволяло вообще забить на встроенный векторный движок и делать всю игру по-олдскульному, битмапами, применяя к ним разные интересные эффекты. Тормоза графики исчезали просто как класс. А встроенная обработка xml, mp3, сетевых протоколов… Это же просто мечта инди. Все усилия шли в код логики и оптимизацию, а не в выяснения сутками того, почему на платформе X у клиента нет соединения с сервером Y.

        • JC_IIB
          /#19271865

          Ну сейчас вроде инди на Unity фигачат. Я сам далек от темы Юнити и геймдева в общем, так что не знаю, хорошо ли, плохо ли это.

  28. AquiHostStrider
    /#19275639

    23 абзаца текста (или 24?) — это очень много и долго читать. Поэтому статью можно сжать до одного предложения: Slack — дерьмо для лохов, Electron не нужен.
    Смысл не потерялся.