Pull to refresh

Comments 462

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

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

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

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

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

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

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

Я не знаю, как надо считать, чтобы приложение на Electron у человека ело меньше, чем аналог на каком-нибудь Avalonia.
>> В хороших языках со сборкой мусора тоже не будет потребления памяти выше
Будет и в разы. Но конечно не так сильно как с браузером.
Значит, будет выше потребление CPU.

Баланс между потреблением памяти и процессора для gc — давно известный факт в теории этих самых gc.
Я сравнивал с cromium, а не с нативными языками, что из контекста должно было быть понятно. Прошу прощения, если криво написал.
А то, что покдачивается весь Электрон, ну с другой стороны и всякие 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 библиотек в составе). Кросплатформенный фреймворк всегда тяжелее нативного
Хаха, я тут видел одну поделку, назовем её «видеословарь». Так вот. В Win7 оно потянуло какой-то .net на полтора гига + захотело ms sql server express, потому что данные были типа в базе. И запускалось через раз даже после всего этого. Угробищность UI я вообще передать не смогу. Ну и понятно, на XP оно вообще не работало. От слова совсем.

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

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

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

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

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

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

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


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

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

Вот кстати Volkov Commander занимал 64кб, а сколько будет весить его аналог на Electron или на .NET?
Вы же понимаете что все эти электроны нужны тогда, когда у вас UI не текстовый?
Не очень понял. На мой вкус по количеству графических элементов тот же VC не сильно отличается от VSCode или тот же centericq от slack.
> На мой вкус

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

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

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


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

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

нет.
запустить под облочкой winpty-agent.exe и cmd.exe — это не терминал. При том, что сожрала эта поделка 50 мб поверх 0,8 того, что спрятала под себя…
А еще при запуске стандратного виндового ssh до сервера не смогла нормально при изменении окна отрисовать запущенный mс.
Сравните это с ConEmu, что ли....

Я говорил про другое, и не особо намерен выяснять продвинутость и каноничность Hyper как, собственно, терминала. Исходный комментарий постулировал, что Electron нужен, когда UI не текстовый, на что я дал пример программы с текстовым UI, которая сделана через Electron, несмотря ни на что. И да, жрёт память. Как и всё на электроне. Зато можно темки писать на CSS. Прогресс, что.
Так стили и Qt и GTK поддерживает.
Там, скорее всего, инсталлер всех этих якобы бесплатных говнопрограмм, которые вместе с собой ставят всякие браузеры амиго, оптимизаторы винды и прочий сброд, никакого отношения все это к дотнету не имеет.
Там еще всякие SQL Server Express и все остальное, я не знаю на чем и как это было написано, что система предлагала скачать для запуска, то и качалось.
Ставилось на чистую Win 7 Pro SP1

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

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


Левое приложение, которому не требуется база, устанавливает SQL Server Express, который не имеет никакого отношения к дотнету, но во всем у вас дотнет виноват. Почему именно он, а не ящирики с планеты Нибиру?
Использование базы просто потому, что те, кто делал приложение сделали так. Я не знаю почему. Само приложение на .net. Выглядит как поделка левой пяткой секретарши.
Что мешало Sql Server Express использовать в приложении на C++? Java?
Этому приложению не требовалась никакая серьезная база, да и вообще база.

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


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


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

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

С большой долей вероятности то, что вы сделали на электроне в 50 строчек js кода можно сделать под дотнет со сравнимым количеством строчек кода и получить приложение, которое будет занимать десятки килобайт и работать на всех Windows начиная с XP с третьим сервис паком и заканчивая самой последней 10-кой без каких либо доустанавливаний чего-нибудь еще. Просто запускаете экзешник в десятки килобайт и он работает. Ну да, будет стандартный windows-интерфейс, если нужны будут украшательства, за счет картинок и прочего размер наверняка вырастет, но врядли будет больше сотен килобайт.
Не, просто он на 50 строчек кода набросал прототип, ну и фигня ваш дотнет.
А если бы начал пилить уже полноценное приложение, тот тут был бы и электрон и БД какая-нибудь.
Насчет полтора гигабайта это конечно вопрос. Но в целом мне помнится (могу ошибаться) раньше дотнет надо было качать последовательно. На ту же XP. Просто 4й скажет что нужен 3й итд. Может отсюда и большие объемы? не берусь утверждать. Лет 5 сижу на маке. Дотнет вижу только когда время от времени пытаюсь родной keepass запустить на mono
Так это апдейт всего лишь, минорный
А я пользуюсь HEX-редактором Bless, написанным на C# + GTK+. Запускается почти моментально, mono потребляет 17 мегабайт RAM, а сам bless — 200 кбайт.
15 лет пишу под винду десктопный софт, но JS-приложения для десктопа… Не могу этого понять. Зачем? То есть нафига? Это такой способ поиздеваться над пользователяли? Троллинг? Или это полноя и окончательная победа Идиократии? У меня только непонимание и одни вопросы… Наверное безнадежно я устарел. Могу написать софтинку на VCL под Дельфи, или MFC. На нелюбимом WPF под шарпы. С Qt тоже знаком. Да хоть на голом WinAPI, сделаю вам красивый UI и все будет летать со скоростью блокнота. И даже в сотню кбайт скомпилированного EXE с зависимостями только виндовых библиотек. Но эти кривые и монструозные жс приложения в сотни мегабайт. Так и хочется крикнуть — Господь жги, тут уже нечего спасать…
Может быть чтобы была одна кодовая база на все популярные ОС: win, macOS, linux, iOS, Android, web?
Это же выбор между скорость и стоимостью разработки и количеством сжираемых ресурсов железа пользователя. Кто-то готов потратиться и пожалеть юзера, кто-то не готов. Особенно это становится актуально, во времена, когда «Мы носим суперкомпьютеры в наших карманах.» Почему бы не использовать бесплатно эти суперкомпьютеры и платить за разработку только одной программы, а не пяти?

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

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

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

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


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


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


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

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

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

а сейчас компы такой же мощности, если не выше, умещаются в задний карман джинсов и можно в браузере запустить виртуальную windows 98 и в автобусе ехать и работать по несколько часов =)
Вот тоже умa нe приложу — нафига все качают Слаковское приложение (по сути запускают еще один хром)??
Веб версия же всe умеет (кроме шаринга десктопа нa видеозвонках)
Слаком не пользуюсь, но все же удобнее когда есть разные приложения на панели задач, чем куча вкладок в браузере.
Чем именно? Даже если будет в отдельном окне — все равно та же унылая веб фигня. Ладно дома у меня i7, ссд и 16 гигов ддр4, а на ноуте, который покупался в дополнение к пк на сумму которую не жалко, двухядерный целерон и 3 гига памяти.

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

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

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

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

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


firefox --new-instance -P foo

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


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

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

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

вроде и это реализуется через расширение устанавливаемое в браузер.
Потому что Маки например не умеют в нормальное переключение окон одного и того же приложения, например. Только «Показать все окна». Довольно неудобно на мой взгляд.
Вы сейчас про Cmd+` или про что-то другое?
Вероятно оно. Я обычно через ПКМ по нужному приложению щелкаю
Ну то есть не умеете «вы», а не «Маки»
Разница между переключением окон и навигацией по всем окнам сразу несколько отличается, так что нет, это именно маки не умеют.
UFO just landed and posted this here
Это просто экономия, в ущерб конечным пользователям.

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

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

Сейчас у Слака 193 открытые вакансии: slack.com/careers#openings Из них разработчиков два-три десятка от силы. Они могут прямо сейчас нанять по десять разработчиков на каждую платформу, из-за этого цена вырастет на 2%, не больше.
Не пойму почему все приводят приложение Slack как пример насколько Electron плох. Скачайте приложение Discord, оно очень крутое, сделано на том же Electron.
Не пользовался слаком, но пользовался дискордом. И могу сказать, что, на мой взгляд сисадмина, он тормозит. А ещё лезет по процессам, да и вообще куда не просят.
Ок, VSCode. Функционально — круто. Можно быстро поднять себе удобную IDE под любой ЯП. Поднимал под C++. Я понятия не имею, что, но томозило оно знатно. Пустым (ну, м.б. с 1-3 плагинами) пользоваться ещё можно, но чуть больше и всё.
может быть тупил какой-нибудь криво написанный плагин или может быть language server для вашего языка тупил. Мало ли.
А вот Sublime предлагает отключать плагины, которые тупят.
Может и так конечно, но именно по этой причине пока забросил её в долгий ящик.
4790 проц, 16 Гб, эта хрень стартует секунд 15. Телега в которой у меня в 10 раз больше групп и каналов меньше секунды.

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

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

Я пока видел только vs code из таких приложений которым хоть как то пользоваться можно. Дискорд тоже непозволительно много ресурсов сжирал для задач которые выполняет и не сказать что быстро на слабом железе работал.
Меня больше всего убивает скорость запуска — что того, что другого.
UFO just landed and posted this here
Я пока видел только vs code из таких приложений которым хоть как то пользоваться можно.

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

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

Увы, но нет. Точнее есть, но путём написания плагинов. Какие смотрел особо подробно:
  • QtCreator — autotools, qmake, cmake (м.б. что-то ещё). Для premake есть знатно протухший плагин (время от времени искоса поглядываю на него с целью обновить до текущих версий). Опять же, всё это плагины, да расширения.
  • Eclipse — условно из коробки видел только cmake. Есть тонны плагинов, но это опять таки плагины. Для premake не находил.
  • Anjuta — дико под GTK заточенная IDE и довольно минималистична. Систему сборки не помню (м.б. и кастомные были), но много чего не хватало.
  • KDevelop — аналогично Anjuta.


Code::Blocks и CodeLite ещё смотрел, но что в них было не так — не помню. NetBeans честно не глядел.

Geany, Emacs (vim ещё некоторые рекомендуют) — по сути, как и VSCode — нужно потрать сколько-то времени, дабы настроить под себя. Собственно, чем и хочу заняться как-нибудь в свободное время.

Если знаете ещё какие, поделитесь пожалуйста.

Так вот, с VSCode получилась какая-то удобная середина: с одной стороны сильно кастомизуема без написания плагинов (в отличие от Eclipse, QtCreator и др.), с другой стороны проста в освоении и кастомизации (в отличии от Emacs).

Возможно, я вас как-то не так понял, но кастомные команды для сборки и запуска в QtCreator задать конечно же можно безо всяких плагинов. Идёте на страницу Projects -> Build & Run -> Build -> Build steps. Там можно задавать свои шаги сборки. Точно также с запуском. Я так работал с проектом, который использовал совершенно самописную систему сборки.


Если же вы имеете ввиду, чтобы IDE сама распознала вашу систему сборки и автоматически запускала бы её, то тут да, кроме Cmake, qmake, qbs ничего из коробки вроде нет.

Что-то не натыкался на эту настройку. Спасибо. Попробую. Единственное, совсем маленький минус: как понимаю, будет всё равно использовать pro файл для учёта файлов, которые являются частью проекта. Или можно настроить так, что бы файлами проекта считались все файлы в каталоге проекта и его подкаталогах?

В корне проекта нужно создать файлы <имя_проекта>.files и <имя_проекта>.includes в кторых поместить просто список всех файлов исходников и список всех инклюд-директорий, соответственно. Я их создавал с помощью чего-то вроде find -name *.C > myproject.files.


Upd: проект нужно создавать с помощью File -> New File or Project -> Import Project -> Import existing project

Ясно. Спасибо. Очень помогли. Если с этим никаких более проблем не возникнет, надеюсь закончу странствия от IDE к IDE.
UFO just landed and posted this here
В этом одновременно проблема поддержки множества утилит сборки. По крайней мере, когда я последний раз пробовал qtcreator, он поддерживал cmake скорее для галочки: конфигурацию выбрать нельзя, один конкретный таргет (и уж тем более их подмножество, а это киллер-фича kdevelop) выбрать нельзя, и так далее.
Насколько я помню VSCode на менее чем 8Gb оперативки, даже для маленьких проектов не вариант (в отличии от того же rider который на 4gb на мелких проектах вполне выживает), т.к. когда вышло — пробовал. Может быть сейчас уже не так.

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

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

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

UFO just landed and posted this here

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

UFO just landed and posted this here
Telegram теперь тоже запускается минут 10, спасибо ломающим изменениям в Fontconfig 2.13 и ихним кастомным костылями ради отображения своих эмодзи — читает мимо кэша весь /etc/fonts. И оперативку жрёт будь здоров: если в чатах с кучей картиночек и стикеров обитать, почти до гигабайта подтекает за пару дней.
Я с этой переменной и запускал, как только поломалось — без неё окно вообще не появлялось, и вроде даже процесс в итоге крашился, точно не помню. Причём с ней тоже стартовало долго, и большая часть диапазонов Юникода отваливалась, а в файловом диалоге вообще все символы квадратиками были, даже ASCII — выбирал вслепую или копипастил из автодополнения баша. Через несколько недель случайно запустил без переменной и обнаружил, что уже и так работает, причём лучше.
А может лучше с Miranda сравнивать? там и телеграмм пролетает мимо.
Миранду толком не видел; я с винды слез раньше, чем начал активно пользоваться жаббером.

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


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

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

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

Ohh, sh… Даже в кошмарном сне я не мог себе такое представить.
UFO just landed and posted this here

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

image

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

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

Макось сама явно больше винты жрёт оперы, у меня MBP в 8 гигами ОЗУ в режиме просмотра веб страниц, всегда на подкачке сидит в районе ещё одного гига.
Ну, VLC и LibreOffice как-то же на разных платформах существуют.
UFO just landed and posted this here
UFO just landed and posted this here

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

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

Так что про стереотип «тормозной LibreOffice» стоит забыть: он и в самый момент появления (то есть отпочковывания от OpenOffice.org) не был особо тормозным, а сейчас — так и вообще «летает». В основном за счёт пункта номер 3, правда…
Если у вас стокгорьмский синдром и вы уже ничего не замечаете, то есть простой способ: примените тот же метод, что и автор статьи. На Raspberri Pi MS Office не встанет, но можно использовать Pentium MMX 233MHz (да, там работает и Windows 7 и последний офис). Если нет железного — возьмите PMem и запустите всё хозяйство там.

То, что вы «не видите» тормозов не обозначает, что их нет, увы. Проихводители софта за последний лет 20 приучили большинство пользователей к тому, что весь софт работает катастрофически медленно.

Даже исключений (типа того же Хрома) хватает ненадолго: да, 10 лет назад, когда Хром только появился — он был реально быстрым и маленьким. Но к современному монстру слова «быстрый» и «маленький» неприменимы от слова «совсем».
UFO just landed and posted this here
Чистый C++ и UI — это боль. Но Qt сильно спасает.
Я попробовал вспомнить варианты где бы был чистый C++ и UI. Везде либо просто C, либо какие-то препроцессоры, либо другие виды C — не C++. Разве что WTL, который и правда удовольствием не назовешь. А вы что имели в виду?
По чистым C++ с UI — я понимаю использование наиболее нативных вариантов. С Windows всё ясно: WinAPI. Под Linux не так однозначно. Наиболее нативным думаю там является XLib. И вот без какой-то монструозной штуки слабо представляю, как это можно обернуть чем-то, сделав кроссплатформенным (как описал комментатор выше).
Ну так и WinAPI и XLib сами по себе кроссплатформенные уже.

WinAPI — через wine
XLib — в принципе есть на многих платформах нативно.

Но и то и другое опять же именно плюсов не требует. Обычный C, можно даже pascal
Wine — это уже по сути костыль. Плюс мне интересно, как вы собрались используя WinAPI собрать тот же ELF.
Касательно XLib, где-то когда-то слышал про реализацию XLib для Windows, но сам не наталкивался.

>Но и то и другое опять же именно плюсов не требует
А кто и где говорил, что обязательно требует?
> Плюс мне интересно, как вы собрались используя WinAPI собрать тот же ELF.

Я не собираюсь. Нужды такой не было. Я пользовался тем, что другие делали, если интересно как — вот нашел вам пару ссылок.
wiki.winehq.org/Winelib_User%27s_Guide#What_is_Winelib.3F
www.drdobbs.com/dropping-windows-with-winelib/184401635

> Касательно XLib, где-то когда-то слышал про реализацию XLib для Windows, но
> сам не наталкивался.

Если хочется без гемороя, то проще всего конечно будет либо wsl либо docker, но это читерство; X11 сервер есть например в виде Xming или VcXsrv. Исходники, собирающиеся VS есть например здесь sourceforge.net/u/mikedep333/vcxsrv/ci/master/tree/libX11

Ну и кроме того есть cygwin и mingw

> А кто и где говорил, что обязательно требует?

Ну я так понимаю «Чистый C++» — значит с плюсами. Ну потому, что он C++.
Про библиотеки гляну. Про winelib что-то не подумал. И за X-ы для Windows спасибо. Про cygwin'овские X-ы тоже что-то забыл. А вот в mingw — не припомню X-ов. Помню что-то из линуксового пытался собрать для msys2. Оно в зависимости тянуло xlib. В конечном итоге в это и упёрся.
Но по факту — это уже дополнительные библиотеки. В этом случае обычно проще уже взять что-то более подходящее. Тот же Qt.

Под «Чистый C++» я понимаю C++ с STL и какой-нибудь C библиотекой. Т.е. без использования дополнительных зависимостей, в т.ч. и сборочных.
C++ — это нынче всё же не расширение C, а вполне независимый язык с частичной поддержкой C.
К чистому C++ в рамках конкретно взятой платформы логично добавляется какой-нибудь её интерфейс (без этого уж точно далеко не уедешь, т.к. UI в языки редко тащится). На Windows — это WinAPI, в котором есть UI. На Linux — боль. Если совсем честно, то только голый шлюз. Если чуть менее честно, то glibc, который тоже далёк от UI. Таким образом, честно в Linux с UI не выйдет. Поэтому опять же сделал допущение в виде X-ов (плохо знаком с wayland, поэтому тут не смотрю на него), т.к. более низкоуровневого UI в Linux не припоминаю (хот.
В рамках таких рассуждений я и пришёл к двум интерфейсам: xlib и WinAPI, притягивание за уши которых к чему-то общему то ещё занятие. В данном случае реальнее и выгоднее взять что-то более абстрактное.
> Помню что-то из линуксового пытался собрать для msys2.

На мой взгляд для такого — wsl или docker. Конечно это доп. зависимость в OS.

> В этом случае обычно проще уже взять что-то более подходящее. Тот
> же Qt.

Я вообще после появления QT воспринимаю его как часть языка. Очень уж хорошие у них интерфейсы классов, документация и даже инструментарий. Если доведется что-то писать на C++ нынче, то у меня даже мысли нет делать это на STL или на чем-то другом. Контейнеры, многопоточность, сериализация, UI, регулярные выражения, скрипты, даже html/css — все в одной упаковке и все унифицировано. Бери и делай. Даже если платформа одна.
>На мой взгляд для такого — wsl или docker. Конечно это доп. зависимость в OS.
Дело было на работе. Там админских прав нет. Мне когда-то для чего-то (уже не помню) поставили msys2. Собственно, его и взял. В принципе, wsl вообще не тыкал палкой. Docker тоже, но на сколько понял, это виртуалка. Их без большой необходимости обхожу стороной, ибо оверхед.

С Qt да. STL ещё использую в совокупности, но скорее по привычки и только если для себя. С Qt познакомился при переходе с windows на linux. На windows выбор не такой сильный. В те времена вообще использовал C++ Builder. У него с UI проблем нет, поэтому и не рыпался. При переходе на linux возник серьёзный вопрос, а чем здесь вообще пользоваться? Вопрос касался и IDE и UI. Что там, что там тонны пересмотрел, что-то даже пробовал. Вот например накопанный мной список UI библиотек или фреймворков, имеющих UI, для C++:
Qt
GTK/gtkmm
wxWidgets
FLTK
FOX toolkit
LessTif, Motif, Open Motif (ныне уже дохлые или почти дохлые)
Xaw
GLUI
Elementary
IUP
Juce
CPPTk
Ultimate++
EFL
Nana
TnFOX (форк FOX Toolkit)
XVT
MyGUI
µGFX
Nuklear, ImGUI, CEGUI, Flat UI, Zahnrad (Immediate mode)

Некоторые даже пробовал тыкать палкой (в частности Nana, FLTK, и совсем немного FOX). Но то функций мало, то доки скудные. Так я и остановился на Qt. В принципе, если мне будет нужен UI уровня «две строчки и две кнопочки», то Qt брать не стану, т.к. тяжеловесно как-то. В таком случае думаю хорошо пойдёт что-нибудь из FLTK, FOX, Nana и подобных.
Immediate mode UI оказались довольно интересной темой, например для игр. Собственно, это UI библиотеки без рендера. Для десктопного UI по большей части бессмысленно, но вот игры и какие-нибудь хитрые архитектуры — самое оно. Особо приятно то, что некоторые из них вообще не имеют каких-либо зависимостей.
Оффтоп:

Примерно 15 лет назад читал книжки, как писать софт под Windows. Про все эти оконные процедуры, windows-сообщения, объекты ядра, и еще упоминается MFC как красивая обертка над этим делом. Потом пересел на Linux и от этого дела отстал, но чувствую, что знания надо освежить. Но вот сейчас не могу найти современных книг по Windows-разработке, которые именно про нативные приложения, и которые начинают с азов. Не посоветуете ли чего толкового?
UFO just landed and posted this here
некоторые новые веяния — появились.
местами вполне удобные
UFO just landed and posted this here
основы, конечно, прежние.
но многое стало можно делать гораздо удобнее
А как же .NET? Выше его сравнили с Electron, но (сугубо имхо) — это реально крутая вещь, особенно учитывая то, что под linux есть mono. Я сам давно не писал под винду, но когда заканчивал, вроде был курс на уход от winapi в сторону .net для всего пользовательского софта, для которого это возможно.
под Linux .NET будет выглядеть как flash под винду.
gtk#/mono уже больше 10 лет зависимостью для gnome desktop modules был.
А в версии 3.0 обещают завезти WPF. Но, думаю, только под виндой. Есть еще проект Авалония — кроссплатформенная WPF.
Кор это круто, но тут речь про десктоп — в коре нет и пока не будет UI при поддержки Microsoft. WPF в core — это скорее убийство FullFramework с переездом самого нужного в кор. Как выше заметили есть AvaloniaUI, что отлично подойдет для пет проджекта, но я бы поостерегся писать на ней что то для бизнеса.

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


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


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


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

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

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

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


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

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


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


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


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

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


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


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


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


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


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

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


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

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

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

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


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


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

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

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


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

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


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

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


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

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


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


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

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


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


Я говорил не про сам язык программирования 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++).

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


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

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


Происходит качественный скачок — появление и позиционирование языка 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 я просто молчу, старый язык уж очень, хотя он до сих пор где-то в продакшне телекома юзается по слухам.

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

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


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

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


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

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


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


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

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


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


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

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

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


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


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


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


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

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? =)

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

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

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


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

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


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


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


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

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

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


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

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

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

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

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


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

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

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

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


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


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

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

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


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


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


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


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


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

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


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

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

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

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

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

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


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


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

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

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

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

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


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


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

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

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

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


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


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


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


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

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

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

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

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


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


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


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

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

Ну, вообще говоря, это следует из формулировки «уступает в адекватности цивилизованным странам» и из того, что «уступать» — антирефлексивное отношение.

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

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


Мне про это отвечают что-то там про СДЭК. Ну, если у них тоже бывшие вчерашние студенты работают...

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

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

Такая же или чуть-чуть получше чем в 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?
Какую бы вы хотели? Надеюсь не исключения, которые в том же C++ весьма не редко отключают?

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


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

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


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

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

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

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

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

Милая статья, спасибо.


Сабтайпинг традиционно всё ломает.

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

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


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

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

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.
из того что внедряли в каждый из них не так давно

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

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


  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
    ...

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

Ладно, предположим вы имели ввиду только вывод типов, но он есть в куче других языков. Стал ли C# похож на Haskell?

Ну это ж принципиально разные выводы типов.


HKT

Higher-kinded types? Ради интереса, как оно выглядит в C#?


Type classes

И это тоже интересно как выглядит.


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

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

Higher-kinded types? Ради интереса, как оно выглядит в C#?

Никак, это фантазии на уровне пропозала. Как и тайп классы.
Даже не факт что рекорды въедут в C#8

Higher-kinded types? Ради интереса, как оно выглядит в C#?

public static T<A> To<T, A>(this IEnumerable<A> xs)
    where T : <>, new(), ICollection<> 
{
    var ta = new T<A>();
    foreach(var x in xs) {
        ta.Add(x);
    }
    return ta;
}

...
{
    var data = Enumerable.Range(0, 20);

    var set = data.To<HashSet<>, int>();
    var linkedList = data.To<LinkedList<>, int>();
    var list = data.To<List<>, int>();
}


И это тоже интересно как выглядит.

github.com/dotnet/csharplang/issues/110

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

Это слабо подходит под определение «дежавю» :)

По первому — это типа как template template arguments в плюсах? Ну,


template<template<typename T, typename... Rest> typename Template>

(или моё любимое).


github.com/dotnet/csharplang/issues/110

А фундепы будут? :)


Стрёмно оно всё выглядит в ООП-языке, конечно. Интересно, будут ли этим в продакшене пользоваться.


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

Ну, кмк должно выглядеть сильно лучше. По крайней мере в примере я такого ужаса не наблюдаю.
UFO just landed and posted this here

Я знаю другие языки на уровне «могу прочитать хелловорлд». Хотя на сишарпе лет 10 назад что-то писал, эх, но не суть.


auto в плюсах — это просто мелочь. Я бы скорее посмотрел бы на аналог constexpr-функций или готовящейся компилтайм-рефлексии.


А про другие языки я поэтому судить не могу.

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

Так всякие while, for и if вообще во всех этих языках есть. if-то даже в моём родном хаскеле есть!

Ну а вот в Go, например нет while. А так же в C++ долгое время не было foreach, а вот в SQL:2003 тоже нет FOR и WHILE.
в Go, например нет while

Нет отдельного кейворда, да, просто потому что for уже это покрывает.


А так же в C++ долгое время не было foreach

а еще C++ довольно долгое время крайне медленно развивался. Ну и добавление for_each лишь пример миграции фич из разных языков.


SQL:2003 тоже нет FOR и WHILE.

Насколько я помню, стандарт SQL он как бы только про декларативные штуки, а императивщина это про SQL/PSM который вроде как расширение спецификации. Но я не разбирался.

А так же в C++ долгое время не было foreach

Его и сейчас там нет. Есть range-based for loop, который, во-первых, всё ещё for, а, во-вторых, производная форма, сиречь прямо в стандарте написано, в какой код со старым добрым for она дешугарится.


а вот в SQL:2003 тоже нет FOR и WHILE

Ну вы бы ещё хаскель взяли, там тоже for и while нет.

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

UFO just landed and posted this here
Может они тоже на Яваскрипте? В Гноме 3 gnome-shell написана на JS + нативный код (по типу React Native, только без потерь производительности на реакт). Ест 100-200 Мб, правда она всем занимается, и панельки выводит, и поиск, и окнами управляет.
UFO just landed and posted this here
Без информации о функционале сложно согласится с тем что всего-то 25Мб. Что ваша программа делает?
К примеру клиент Telegram потребляет 47МБ.
Без информации о функционале сложно согласится с тем что всего-то 25Мб. Что ваша программа делает?

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

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

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

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


Это что ж за дешевое железо-то такое? В том же ДНСе компов меньше, чем с 4 гигами нету в продаже. Я бы сказал, средние машины сейчас как раз 8, реже — 16.
Я допустим буквально несколько месяцев назад взял ноут простенький где 3 гига. Просто в деревню ездить или на природу. Дома то понятно нормальные 16 гигов на ПК.
Притом я еще видел варианты с 2 и 1 гигом (да и сейчас есть в том же днс двухгиговые варианты за 10к примерно). И не надо забывать что есть еще и БУ железо которое покупают люди с невысоким достатком.
Вот именно, что «нормальные» 16 гигов. Собирал комп 4 года назад и поставил как раз 16 гигов «на вырост». И если раньше в среднем у меня уходило по 6-8 гигов после старта системы, то сейчас уже 10-12… Инфляция?
Инфляция


Скажите спасибо Electron-у.
Но чет 10 гиг после старта — это очень дофига. Может, все же какой софт запускается? :)
Докер на автозапуске спокойно даст такой профиль.
да, докер в машине включен (но не используется)
Ну, если речь идет о ноутах, то тут возможны варианты, да. Я, прежде чем написать свое предыдущее сообщение, открыл сайт ДНСа и проверил — десктопные варианты у них начинаются с 4мя гигами, меньше нет.

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


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

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

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

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

Авито первые попавшиеся предложения: Ddr3 4gb Hynix 2Rx8 PC3-10600 1250 рублей, 4гб ddr3 рс-12800/10600 — 1700 рублей.
Ну 4 года всего это почти новье)) Так то народ и железки вроде asus eeepc на авито покупает/продает. Я допустим сам недавно покупал, но решил что железо посовременней все же нужно и опять же продал несколько месяцев как.
На языке без прямого управления памятью дедушка Вирт ещё в 1989 году забахал свою оконную ОС с гибридом из среды разработки, Word Pad и ActiveX. Уж не знаю сколько оперативки она жрала, на 25 мегагерц процессора ей хватало.

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

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

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

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

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

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

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

25 метров это очень много.
Сможет ли утилита при том же умении отжирать памяти намного меньше?
Скажете 25МБ для мелкой трейной проги — это много?

Это серверная убунта.
UFO just landed and posted this here
Да епрст, я ж говорю в ней 50 строк кода и она работает везде.
Понятно дело что можно заморочиться и написать отдельно для каждой платформы и сэкономить ресурсы.
Интереснее было бы посмотреть пример подобной программы например на Джаве, и сравнить количество кода / расход памяти.
Сегодня количество веб разработчиков в разы превышает количество других прикладных программистов. Писать софт на JavaScript попросту быстрее и дешевле, чем использовать специализированные технологии.

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

И даже в сотню кбайт скомпилированного 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, и то и то — электрон, вот только в том как это все работает какая-то разница все же есть.

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

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


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


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


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


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


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

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

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

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

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


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

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


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

image


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

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


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

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

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


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


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


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

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

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

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

При этом согласен что io тоже в равной степени медленное. И скорость действительно сильно зависит от оптимизации кода.
На тех же Райзенах очень важна частота и вид оперативы, разницу даже видно невооруженным глазом. А у Интела тащит кэш.
Ну это мое мнение.
Ну так то и целероны всякие в бюджетных железках используются.
А каким боком они?
В тесте выше тогда надо было отключить 2-4 ядра и оставить 2. Тогда частота повлияла бы еще сильнее.

Я бы не стал сравнивать i7 с селеронами. Как минимум из-за большего кэша и большего числа ядер.
Да и во многих многоядерных процессорах частота часто в пределах 3.3-3.6.
Ну я к тому что на них еще как бы не на порядок все медленнее бы делалось. Так что я с вами согласен что не только I/O слабое место а процов давно хватает.
По двум точкам трудно судить. Сделайте замеров 20 с шагом 0.1, тогда корреляция будет четко видна. Если, конечно, это не слишком сильно вас затруднит.
нет. Еще раз — проблема не в CPU у 90% приложений. Проблема в работе с памятью.

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

Какой-то совет в стиле «если у вашего клиента бизнес-процессы плохо ложатся на архитектуру приложения, тем хуже для этих процессов».
Что до вопроса с электроном и намеки что приложение на электроне потребляет ресурсов неадекватно больше чем нативное решение — пока это все пустые домыслы

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

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

поможет Java

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


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


QT

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


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

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


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

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

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