Comments 461
Многие восхищаются Electron, но не думаю о цене, которую приходиться платить пользователям за удобство разработчиков.
И хотел бы добавить про Оперативку, многие говорят, что типа JS — Браузер сам мусор убирает, потому память и растет, ну он очистит ее, но разработчики на самом деле могут предопределить количество нужной памяти, создав массив, в который бы сохраняли что хотели, а потом сами бы очищали. Грубо говоря, если вы хотите экономить оперативку и чаще ререндерить, то вы можете завести массив, к примеру из 20 ячеек и постоянно их переписывать актуальными данными для рендеринга, тогда сохраните оперативку, но нужно ли это )
Я так делал, когда для 4 айпада писал на JS интерактивную книгу на 100+ страниц (PDF трансформировался в PNG и накладывались звуковые и анимационные эффекты), так как на Айпаде было мало оперативки, а JS и Webview прожорливые — можете представить, но я справился. Считаю Электрон — удачная платформа, а Slack — не самый качественный софт. В тоже время мне не нравится React (субьективно), предпочитал EmberJS, сейчас на свежем Angular.
Пожалейте своих пользователей, не пишите приложения на JS под мобильные устройства. Это тормозит, выглядит, как сайт в браузере и занимает неприлично много памяти. Это я вам как пользователь таких приложений говорю. Пользуюсь, потому что по работе надо.
А то, что покдачивается весь Электрон, ну с другой стороны и всякие NET Framework-и тоже подкачиваются.
- Необязательно. .Net Framework предустанавливается в ОС начиная с WindowsXP SP1. Если, например, в минимальных требованиях Windows 7, можно использовать .NET Framework 3.5.1. Приложения получаются очень компактные (например, окно с надписью Hello world на WPF — 4 кб)
- Все приложения .net разделяют общий фреймворк, а каждое Electron приложение включает в себя свой собственный инстанс хромиума. Отсюда разный размер и потребление памяти.
- Вообще сравнивать эти 2 платформы нечестно, т.к. .net framework работает только под windows (а .net core не имеет UI библиотек в составе). Кросплатформенный фреймворк всегда тяжелее нативного
Переделанный на nwjs вариант запускается везде, начиная от XP, кончая OS X. Ах, да, еще и на сайте работает на той же кодовой базе. Хотя там ее собственно 50 строк
Ну и какие выводы я должен сделать из этой истории?
А я нигде не писал что .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 можно написать гигантский кусок говна.
какой-то .net на полтора гига
.Net 4.7.2 весит 80 Мб. Причем это самый новый из всех .Net'ов.
А можете дать ссылку на тот .Net в 1.5 Гб?
Вот кстати Volkov Commander занимал 64кб, а сколько будет весить его аналог на Electron или на .NET?
Это очень субьективно, если сравнивать vscode и какой-нибудь neovim + tmux то в целом я может быть и согласился бы что различия несуществественны, но вот слэк с стерминалом сравнивать…
По сути, вы либо слэком не пользуетесь (к слову, пользуетесь ли?) либо у вас очень интересные вкусы. Нет, если вы представите концепт того как слэк в терминале сделать — мне будет любопытно (даже очень). Повторюсь — слэк это не только чатики.
Слаком { \ˈslak \ } увы пользуюсь — корпоративный стандарт. А вы пользовались centericq?
Повторюсь — слэк это не только чатики.
Да ради бога. В придачу поиск и медиаконент. Посмотрите на Far с conemu. Вы все еще считаете что гигабайт оперативки не перебор, даже с учетом всех ваших киллер-фич?
нет.
запустить под облочкой winpty-agent.exe и cmd.exe — это не терминал. При том, что сожрала эта поделка 50 мб поверх 0,8 того, что спрятала под себя…
А еще при запуске стандратного виндового ssh до сервера не смогла нормально при изменении окна отрисовать запущенный mс.
Сравните это с ConEmu, что ли....
Ставилось на чистую Win 7 Pro SP1
А причем тут .Net тогда? Для UI-only приложений достаточно .Net. Просто этому продукту требуется серьезная база данных (SQLite недостаточно).
Повторюсь — сейчас это так же «на коленке» для теста собрано мной на nwjs (тот же Electron, вид сбоку). Данные вообще в json в файлике лежат. И 50 строк универсального кода, работающего как под node, так и в чистом браузере с web-сервера. И при этом сборка под XP/Win7+/OS X вообще без проблем
Этому приложению не требовалась никакая серьезная база, да и вообще база.
Левое приложение, которому не требуется база, устанавливает SQL Server Express, который не имеет никакого отношения к дотнету, но во всем у вас дотнет виноват. Почему именно он, а не ящирики с планеты Нибиру?
Этому приложению не требовалась никакая серьезная база, да и вообще база.
А что это за приложение такое, приведите ссылку, пожалуйста? Я не спорю, что иногда разработчики тянут ненужное, но чтобы устанавливать базу и не использовать — это что-то новое.
И непонятно, что вы отстаиваете? .Net весит немного, тут мы согласились. Если есть какая-то задача решается в 50 строчек на JS и требует аж целой базы на .Net — я с радостью бы посмотрел на неё, так как попахивает вымыслом.
Если же вы хотите сказать, что некоторые разработчики устанавливают много всего на комп — ну так Politura объяснил выше как минимум одну причину. Так Google Chrome изначально распространялся, т.е. Adobe Flash устанавливал этот самый хром, если не убрать галку.
Мой быстрый прототип на 50 строчек js кода + html конечно никакую базу не использовал. Тупо грузится json и этого достаточно. Суть показать список слов-терминов и показать видео для каждого.
С большой долей вероятности то, что вы сделали на электроне в 50 строчек js кода можно сделать под дотнет со сравнимым количеством строчек кода и получить приложение, которое будет занимать десятки килобайт и работать на всех Windows начиная с XP с третьим сервис паком и заканчивая самой последней 10-кой без каких либо доустанавливаний чего-нибудь еще. Просто запускаете экзешник в десятки килобайт и он работает. Ну да, будет стандартный windows-интерфейс, если нужны будут украшательства, за счет картинок и прочего размер наверняка вырастет, но врядли будет больше сотен килобайт.
Это же выбор между скорость и стоимостью разработки и количеством сжираемых ресурсов железа пользователя. Кто-то готов потратиться и пожалеть юзера, кто-то не готов. Особенно это становится актуально, во времена, когда «Мы носим суперкомпьютеры в наших карманах.» Почему бы не использовать бесплатно эти суперкомпьютеры и платить за разработку только одной программы, а не пяти?
И уж тем более глупо советовать «подите выучите С или Rust, вы, веб-разработчики». Не думаю, что Slack пишут макаки, выбор писать на веб-стеке — это осознанный выбор, а не от того, что «ничего другого не умеем».
Разработчики написали одну веб-версию, и вместо того что бы написать нормальный десктопный клиент, обернули вебверсию электроном, Готово.
Для стартапа это нормально, но Slack Technologies уже зрелая компания с огромной базой корпоративных клиентов, пора и о них подумать.
Даже не вижу смысла качать их клиент, просто держу открытую вкладку Slack в браузере.
Да, это экономия в ущерб конечным пользователям. Я это и сказал. Глупо ожидать от бизнеса, что он не будет снижать затраты, когда он может их снижать. Бизнес — не альтруизм.
я бы не сказал что в ущерб
чтобы написать быструю прогу, нужны ресурсы, хорошие ресурсы и время
это намного большие деньги, чем на js
и если например чтобы пользоваться этой прогой вам нужно заплатить 100 баксов в месяц вместо например 10, вы заплатите?
Ну или пользователь будет вынужден заплатить 100 баксов, чтобы купить дополнительную память\процессор\итд.
а в 2000 году (18 лет назад) pentium с непомню-уже-сколько памяти (наверное 256 Мб), и windows 98 работала на этом компе, хотя и со скрипом.
а сейчас компы такой же мощности, если не выше, умещаются в задний карман джинсов и можно в браузере запустить виртуальную windows 98 и в автобусе ехать и работать по несколько часов =)
Веб версия же всe умеет (кроме шаринга десктопа нa видеозвонках)
PWA нас всех спасет.
В Firefox есть профили, можно параллельно запускать несколько независимых инстансов с разными профилями. Например запуская:
firefox --new-instance -P fooГде foo — произвольное имя профиля (если такого профиля ещё нет, откроется окно с управлением профилями).
Каждый профиль имеет свой набор расширений и настроек браузера.
все же удобнее когда есть разные приложения на панели задач, чем куча вкладок в браузере.
Мне наоборот нравится поменьше открытых программ :)
А вкладки вроде слака/почты и т.п. я обычно делаю «Pin Tab» тогда они занимают меньше горизонтального места и их труднее нечаянно закрыть.
Веб версия же всe умеет (кроме шаринга десктопа нa видеозвонках)
вроде и это реализуется через расширение устанавливаемое в браузер.
Это просто экономия, в ущерб конечным пользователям.
на минуточку, Slack это коммерческое приложение. Пользование им стоит денег. Вы готовы платить в 5 раз больше, чтобы получить быстрые и качественные нативные приложения под 5 платформ? Даже сейчас у слака не самая приятная ценовая политика, а за 5х никто им не будет пользоваться вообще
Каким раком дискорд попал в крутые приложения?
Есть Slack, а есть к примеру Discord, оба на электроне, но просто сравните скорость их работы и отзывчивость интерфейса.
Я пока видел только vs code из таких приложений которым хоть как то пользоваться можно.
Несколько плагинов в него влепи и посмотри на результат.
Ну, судя по всему, под линукс нормальная 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 ничего из коробки вроде нет.
В корне проекта нужно создать файлы <имя_проекта>.files и <имя_проекта>.includes в кторых поместить просто список всех файлов исходников и список всех инклюд-директорий, соответственно. Я их создавал с помощью чего-то вроде find -name *.C > myproject.files.
Upd: проект нужно создавать с помощью File -> New File or Project -> Import Project -> Import existing project
Самое неприятное, что все эти приложения на электроне из всех сил пытаются выглядеть как будто они легковесные, а по факту — очень тяжелые решения. Ну это как если взять Ford Granada Station Vagon 1982, прикрутить спойлер, покрасить красным тормозные колодки, раскрасить кузов яркими красками и налепить стикеры а-ля ралли. Нелепо.
Люди начинают забывать, как должно работать приложение. Посмотрите на тот же телеграм, просто сравните время запуска, время синхронизации, потребляемую память… Но нет, зато мы во время длиннющей загрузки занимающей чуть ли не десяток секунд мы показываем смешные фразочки. Дешевый способ купить внимание пользователя, пока вся эта машинерия разворачивается.
Да телеграм напомнил мне о старых временах, когда всё работало быстро, как в старом скайпе.
FONTCONFIG_FILE=/etc/fonts/ telegram
Discord от релиза к релизу иногда течет просто ужасно:
Очевидно же, там анимированные аватарки и магазин с играми.
Например, сканирует список процессов, чтобы показывать в статусе, в какую игру играет пользователь, рисовать оверлей. Плюс собирает некоторую телеметрию
Если открыть чаты и покликать по разным каналам то поднимается и держится в пределах 130-140 МБ (зависит от количества GIF). После закрытия окна через 5 секунд потребление 94-95 под вантузом. Всего скорее сабж на скриншоте выше под macOS течет по памяти сильно. Ну оно и очевидно это же JS/Electron.
А LibreOffice не на джаве написан? Он такой тормозной в сравнении с MS Office, что я на джаву грешил.
1. В OpenOffice.org Sun долго пытался напихать кучу Java в разнае места.
2. После того, как LibreOffice отпочковался — они её выкорчевали и интерфейс стал быстрее.
3. Главное: с тех пор вышло много новых версий MS Office — и они стали сильно тормознее.
Так что про стереотип «тормозной LibreOffice» стоит забыть: он и в самый момент появления (то есть отпочковывания от OpenOffice.org) не был особо тормозным, а сейчас — так и вообще «летает». В основном за счёт пункта номер 3, правда…
MS Office не заметил тормознутости
То, что вы «не видите» тормозов не обозначает, что их нет, увы. Проихводители софта за последний лет 20 приучили большинство пользователей к тому, что весь софт работает катастрофически медленно.
Даже исключений (типа того же Хрома) хватает ненадолго: да, 10 лет назад, когда Хром только появился — он был реально быстрым и маленьким. Но к современному монстру слова «быстрый» и «маленький» неприменимы от слова «совсем».
WinAPI — через wine
XLib — в принципе есть на многих платформах нативно.
Но и то и другое опять же именно плюсов не требует. Обычный C, можно даже pascal
Касательно XLib, где-то когда-то слышал про реализацию XLib для Windows, но сам не наталкивался.
>Но и то и другое опять же именно плюсов не требует
А кто и где говорил, что обязательно требует?
Я не собираюсь. Нужды такой не было. Я пользовался тем, что другие делали, если интересно как — вот нашел вам пару ссылок.
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++.
Но по факту — это уже дополнительные библиотеки. В этом случае обычно проще уже взять что-то более подходящее. Тот же Qt.
Под «Чистый C++» я понимаю C++ с STL и какой-нибудь C библиотекой. Т.е. без использования дополнительных зависимостей, в т.ч. и сборочных.
C++ — это нынче всё же не расширение C, а вполне независимый язык с частичной поддержкой C.
К чистому C++ в рамках конкретно взятой платформы логично добавляется какой-нибудь её интерфейс (без этого уж точно далеко не уедешь, т.к. UI в языки редко тащится). На Windows — это WinAPI, в котором есть UI. На Linux — боль. Если совсем честно, то только голый шлюз. Если чуть менее честно, то glibc, который тоже далёк от UI. Таким образом, честно в Linux с UI не выйдет. Поэтому опять же сделал допущение в виде X-ов (плохо знаком с wayland, поэтому тут не смотрю на него), т.к. более низкоуровневого UI в Linux не припоминаю (хот.
В рамках таких рассуждений я и пришёл к двум интерфейсам: xlib и WinAPI, притягивание за уши которых к чему-то общему то ещё занятие. В данном случае реальнее и выгоднее взять что-то более абстрактное.
На мой взгляд для такого — wsl или docker. Конечно это доп. зависимость в OS.
> В этом случае обычно проще уже взять что-то более подходящее. Тот
> же Qt.
Я вообще после появления QT воспринимаю его как часть языка. Очень уж хорошие у них интерфейсы классов, документация и даже инструментарий. Если доведется что-то писать на C++ нынче, то у меня даже мысли нет делать это на STL или на чем-то другом. Контейнеры, многопоточность, сериализация, UI, регулярные выражения, скрипты, даже html/css — все в одной упаковке и все унифицировано. Бери и делай. Даже если платформа одна.
Дело было на работе. Там админских прав нет. Мне когда-то для чего-то (уже не помню) поставили 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-разработке, которые именно про нативные приложения, и которые начинают с азов. Не посоветуете ли чего толкового?
местами вполне удобные
.net core sdk
для любителей собрать самостоятельно
К сожалению программистов такая вещь как 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), а не проблемы отрасли, парадигмы программирования или вселенской справедливости.
Причем под количеством и качеством я понимал термины из философии (Диалектика Гегеля / Диалектический Материализм), а не количество как число (уж тем более число разработчиков) и качество как качество ПО.
Сам пример перехода я подрузамевал так:
- Появляется проблема написания сетевых сервисов и приложений;
- Появляются разрозненные решения: зачастую библиотеки/фреймворки к существующим языкам для работы над проблемой;
- Возрастает сложность проблемы, возрастает нагрузка на приложения;
- Постепенно продолжают происходить количественные изменения: предлагаются новые варианты решения — multi-threading (Java, Apache HTTP server, etc.), fork (CGI, FastCGI, *CGI), async concurrency (libevent, libev, libuv, etc. и основанные на них решения — NGINX, NodeJS и т.д.)
- Происходит качественный скачок — появление и позиционирование языка Go для решения этих проблем. Язык заточен исключительно под предметную область: объединяет модель multi-threading и async concurrency — программа запускается в несколько потоков, которые в свою очередь обрабатывают очередь задач (goroutines), позволяя еще более эффективно использовать процессорные ядра.
Стандартная библиотека позволяет написать мощный и быстрый HTTP сервер в пару строк кода за несколько десятков минут. На решение подобной задачи с точно такой же эффективностью в других языках уйдет просто уйма времени (особенно в C++).
Если Вы не согласны с такой интерпретацией, то подробнее о примерах действия закона можете прочитать в вики.
За сим позвольте откланяться. Считаю данную дискуссию исчерпанной и вышедшей за рамки данной статьи.
Смешались в кучу кони, люди.
Происходит качественный скачок — появление и позиционирование языка 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 появился, сначала его позиционировали как конкурента и замену языку C, но не найдя на этом поприще признания, его просто специализировали под написание сетевых приложений. И в этом ключе он уже обрел популярность.
Создается впечатление что Вы упорно не хотите видеть какую проблему он решает и уводите все в плоскость сравнения языков по их возможностям.
Можете объяснить зачем среднестатистическому HTTP серверу (к примеру) аппликативные функторы, монады и монадные трансформеры (в общем их виде)?
Вот перепишем Nginx на Haskell, вот тогда уж точно заживем!
А Вам бы с таким аватаром только в дискуссиях про ЯП участвовать =)
Еще и гадать по аватарке будете, неплохо )
Создается впечатление что Вы упорно не хотите видеть какую проблему он решает и уводите все в плоскость сравнения языков по их возможностям.
Можете объяснить зачем среднестатистическому HTTP серверу (к примеру) аппликативные функторы, монады и монадные трансформеры (в общем их виде)?
Затем же, зачем и в любой другой программе — чтобы описать пайплайн обработки запроса в удобном виде. А может и не нужны, это ведь просто инструмент. Во-первых есть много промежуточных сценариев, а во-вторых вопрос аналогичен "зачем среднестатистическому HTTP серверу нужны continue и break".
Зачем среднестатистическому HTTP серверу нужны continue и break
Ну, наверное затем, чтобы, как минимум, можно было более удобно построить конечный автомат для парсинга HTTP запроса, нет?
Хотя да, что уж там, с монадами-то процесс парсинга значительно ускорится и потребит меньше памяти! Это ж как можно будет распараллелить процесс, если парсить заголовки и тело запроса отдельными pure функциями, завернутыми в монаду. Ого-го!
Не понимаю ваших ужимок
Давайте я Вам объясню:
Я не пишу на Go. Для моих задач он не имеет достаточной выразительности и удобства. Я упомянул Go в качестве ответа на вопрос Fesor.
Посыл мой заключался в том, что сегодня все пишут GUI на Electron, а завтра есть вероятность появления какой-либо более оптимизированной по памяти и скорости технологии, согласно закону перехода количественного в качественное.
Я упомянул Go специально, т.к. это всем понятный пример, который на слуху у большинства, в отличие от более маргинальных здесь приведенных языков (F#, Racket, CML и т.д.), и упомянул его в совершенно конкретном контексте — сетевых приложений.
Вместо того чтобы прочитать мои сообщения внимательно, люди, заметив упоминание Go, решили наброситься на меня и начать выяснять чем Go лучше или хуже других технологий (еще и попутно выставляя меня фанатиком Go).
Скажите, Вы тоже не видите изначального посыла моих комментариев?
Ну, это к вашему вопросу о том, зачем знать разницу между монадой и аппликативным функтором.
Вы видимо тоже не хотите читать мои комментарии. Скажите, где именно я задавал вопрос о том "зачем знать разницу между монадой и аппликативным функтором"?
Думаю это вопрос не ко мне. Лучше об этом спросить у Ozon: https://vc.ru/ozon/45542-go или у Zalando, или у остальных пользователей.
В основном они применяют Go для инфраструктурных моментов (насколько мне известно).
Также есть всякие рекламные биржи и т.д.
На тестовых серверах всё ОК, а вот реальные нагрузки мгновенно кладут систему на обе лопатки, причём даже добавление серверных мощностей не позволяет справиться с проблемой.
Всё упало 26 сентября, прошёл уже почти месяц, всё это время программисты пафосно превозмогают проблему, но безуспешно. Завязанные на них интернет-магазины терпят убытки, франчайзи разоряются, техподдержка убита напрочь наплывом разгневанных пользователей.
А система лежит. И если продолжит лежать ещё недельки три, то есть неплохой шанс увидеть банкротство крупной курьерской компании исключительно по вине IT.
Думаю что ответ на Ваш комментарий был связан с вопросом: "А зачем для магазинов всякая хардкорная конкурентность и всё такое?".
Про Go упоминаний не было. Но Вы опять про Go и про студентов, хотя я, например, использовал сочетание "вчерашних студентов", что подразумевает то что человек все-таки закончил обучение в ВУЗе.
И такое происходит на протяжении всей ветки со всеми комментаторами.
"Чукча не читатель, чукча писатель!" ©
Очень жаль что русскоязычное комьюнити сильно уступает в адекватности цивилизованным странам.
Очень жаль что русскоязычное комьюнити сильно уступает в адекватности цивилизованным странам.
Очень здорово что вы всё русскоязычное комьюнити назвали нецивилизованным на основании одного спора в интернете.
здорово что вы всё русскоязычное комьюнити назвали нецивилизованным
Ну вот видите как оно получается. Я же написал что русскоязычное комьюнити уступает в адекватности, а не то что оно нецивилизованно.
Говорю же, "Чукча не читатель, чукча писатель".
И уж точно не Вам на это мое высказывание обижаться, тем более что Вы тут совсем недавно пытались выставить меня фанатиком Go, говоря что "гоферам застилает глаза божественность Пайка, но неплохо бы ознакомиться с теорией." и позволяя себе прочие фривольности (при весьма забавном обстоятельстве, что я на Go НЕ пишу).
Так что давайте закроем тему. Здесь больше нечего обсуждать.
Сегодня для этого берут Go.
Разве что смузи стартапы. Ему еще версий 5 развиваться до момента, когда им можно будет безболезненно пользоваться.
Такая же или чуть-чуть получше чем в 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?
В джаве есть дженерики
ну дженерики и метапрограммирование на темплейтах это все же разные немного вещи.
arxiv.org/abs/1605.05274v2
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 языка.
Для любой пары языков можно найти даже больше похожих вещей, чем ваш перечень.
- в js тоже есть var, как и в куче других языков. Ладно, предположим вы имели ввиду только вывод типов, но он есть в куче других языков. Стал ли C# похож на Haskell?
- В питоне тоже есть лямбды, питон похож на C#/C++/Java?
- В хачкеле есть генерики, в расте есть генерики, даже в го теперь есть генерики. Похож ли C#/Typescript на Go?
- Эксепшны есть в повершелле. Стала ли Java похожа на Powershell?..
Теперь давайте про ченджлоги. Посмотрим что у C# 8.X:
- Not null reference types
- Records
- HKT
- Type classes
- Defalt interface methods
- Code generation extension
- Method contracts
...
Приведите ченджлог другого языка, который похож на данный.
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
Ну там в плюсы контракты запилить пытаются, например.
Это слабо подходит под определение «дежавю» :)
в Go, например нет while
Нет отдельного кейворда, да, просто потому что for уже это покрывает.
А так же в C++ долгое время не было foreach
а еще C++ довольно долгое время крайне медленно развивался. Ну и добавление for_each лишь пример миграции фич из разных языков.
SQL:2003 тоже нет FOR и WHILE.
Насколько я помню, стандарт SQL он как бы только про декларативные штуки, а императивщина это про SQL/PSM который вроде как расширение спецификации. Но я не разбирался.
Такая же или чуть-чуть получше чем в 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, то без умного чувака рядом человек скорее всего будет гнать мусор тоннами.
> выбиваться будет. Что в принципе даже неплохо, наверно.
Даже представить не могу как бы это выглядело. Можете попробовать на псевдокоде примерчик написать?
> Язык без шаблонов обрекает себя на очень узкую область применения.
> Исключением могут быть разве что языки старше меня, но тут дело в
> специфике.
Так ведь это и хорошо, разве нет? Узкоспециализированый язык, заточеный под эту специальную задачу позволит решать эту задачу более эфективно. А очередной монстр никаких преимуществ перед другими такими же языками широкого профиля иметь не будет. А недостатки — будет, в виде меньшей библиотеки инструментов, меньшего коммьюнити итд
> И поэтому пока нет никакого смысла менять C++ на Go.
И я о том же. Не надо C++ менять на Go. Кесарю кесарево.
> Нужен разный зоопарк версий под разных заказчиков и возиться со всем этим в
> одном воркспейсе не самая тривиальная задача.
Ну на это жаловаться во времена докера — как-то странно.
> И в итоге не понятно, во-первых, а какие интерфейсы мы вообще реализуем, а,
> во-вторых, нет ну вообще никаких гарантий, что мы его реализовали.
Вот с первым согласен. И считаю, что это прекрасно. А второе — действительно проблема, но ведь это и не важно. Если код потребителя изменился так, что ему перестал подходить уже реализованый интерфейс — то и проблему можно решать там, где ее проще всего решить — в коде клиента.
> Ну, на мой вкус, не самый плохой вариант развития событий.
А зачем, если уже есть rust?
> Изучение того же C++ на достаточном уровне либо отобьет у вас желание
> программировать, либо научит нормально распоряжаться ресурсами. Если
> начинать с Go, то без умного чувака рядом человек скорее всего будет гнать
> мусор тоннами.
В очередной раз вспоминаю лекцию Uncle Bob-а. Каждые 5 лет количество разработчиков удваивается. Не потому, что они на свет выползают, а потому что есть спрос. Если вы хотите ограничить этот приток, то даже успеха вам желать будет странным. Это как пытаться зонтиком заткнуть дыру в плотине.
В очередной раз вспоминаю лекцию Uncle Bob-а. Каждые 5 лет количество разработчиков удваивается. Не потому, что они на свет выползают, а потому что есть спрос. Если вы хотите ограничить этот приток, то даже успеха вам желать будет странным. Это как пытаться зонтиком заткнуть дыру в плотине.
Так пусть вкатываются, кто ж им мешает. Вот только вкатываться в IT они должны через боль и страдания, а то потом у нас Gmail лагает и на Хабре страница с 2к комментов минуту грузится. Таких вот тут не надо.
Electron действительно сжирает всю память и процессорное время.
Не путайте слаковский клиент и электрон. Сам электрон ничего нe «сжирает».
Недавно писал нa нем тулзу для трея — занимает 25МБ, процессор вообще не трогает фактически. Скажете 25МБ для мелкой трейной проги — это много? Я скажу что она работает на всех популярных операционках и написана нa языке без прямого управления памятью.
Как человек писавший утилиту для трея в xp и убунте 6.04 — да, 25 метров это дичь для мелкой трейной проги. После всяких борландовских с++ старых, где можно было влезть в мегабайт (прога смотрящая смб шары в локалке) — электрон это жир жирный.
К примеру клиент Telegram потребляет 47МБ.
Без информации о функционале сложно согласится с тем что всего-то 25Мб. Что ваша программа делает?
Ничего почти не делает, показывает иконку + статистику кое-какую.
25МБ весит просто обертка.
Я понимаю что в отрыве от контекста — 25МБ — это много.
Но надо учитывать, во-первых, что это всего 0.15% от современных средних 16ГБ.
А во-вторых, что за ~50 строк кода и 25МБ памяти мы получаем программу, которая работает везде без плясок с бубном.
И 25МБ не будут просто так расти в геометрической прогрессии с ростом функционала, все зависит от прямоты рук разработчиков.
Не стоит брать слак в пример, он просто коряво сделан. Я ужe вышe писал что сам юзаю веб версию вместо клиента.
современных средних 16ГБ
Вы забыли уточнить: средние 16 гигов на машине программиста. Потому что в реальности 16 гигов это ни разу не среднее значение. Обычно сейчас 4 и 8 встречаются. На совсем дешевом железе 2-3. На совсем-совсем дешевом и того меньше.
На совсем дешевом железе 2-3. На совсем-совсем дешевом и того меньше.
Это что ж за дешевое железо-то такое? В том же ДНСе компов меньше, чем с 4 гигами нету в продаже. Я бы сказал, средние машины сейчас как раз 8, реже — 16.
Притом я еще видел варианты с 2 и 1 гигом (да и сейчас есть в том же днс двухгиговые варианты за 10к примерно). И не надо забывать что есть еще и БУ железо которое покупают люди с невысоким достатком.
И не надо забывать что есть еще и БУ железо которое покупают люди с невысоким достатком.
4 гб модуль DDR4 новый по ценам ДНСа — в районе 2500 р, на авито бэушные они по 2000 у барыг, стало быть у частников можно купить по 1600-1700 где-то.
Осталось уточнить, в какое место БУ железа можно засунуть DDR4. («Более старая» память дороже.)И не надо забывать что есть еще и БУ железо которое покупают люди с невысоким достатком.4 гб модуль DDR4 новый по ценам ДНСа — в районе 2500 р, на авито бэушные они по 2000 у барыг, стало быть у частников можно купить по 1600-1700 где-то.
(Для «носить с собой в автобусе» у меня нетбук, в который больше 2ГБ просто «по инструкции» не ставится (да, говорят, в некоторые можно ставить больше, чем положено, и оно даже работает).)
Осталось уточнить, в какое место БУ железа можно засунуть DDR4
В такое БУ, которое не старше 4-х лет, DDR4 была представлена в 2014м.
«Более старая» память дороже.
ДНС, новый модуль G.Skill 4GB DDR3 = 2 тыщи рублей, Patriot 2100 р. Есть даже дешевле.
Авито первые попавшиеся предложения: Ddr3 4gb Hynix 2Rx8 PC3-10600 1250 рублей, 4гб ddr3 рс-12800/10600 — 1700 рублей.
25Mb?!?!
Прям сейчас на .net запустил форму с треем: бинарник — 42кб и в памяти 3,5 мб. И да, вот оно процессор не трогает.
Upd.: забыл добавить, что 35 кб из них — иконка трея
По памяти 3.5мб для иконки в трее тоже звучит жирновато, вам не кажется?
К примеру зачем вам 1МиБ памяти для стека основного потока?
ну все же, .net это еще и рантайм, и спорить с нативным кодом, содержащим только winapi я не буду. по поводу 1мб на поток — это не к нам, это более древний вопрос. Каюсь в неопытности, я не знаю как указать рантайму есть меньше по дефолту, но вроде бы iis ест в 4 раза меньше.ну и этот 1м — не реально съеденный, а всего лишь обозначенный в виртуальной памяти.
Во-вторых то, что у вас сишный рантайм встроен в большинство ОС никого не расстраивает. C++ redistrutable на гигабайты люди охотно ставят, а вот 50мб фреймворка это чересчур. Как-то не очень честно.
Отвечая товарищу zeronice, IIS тоже кроме как в легаси проектах не используется, kestrel + nginx наше все.
Сможет ли утилита при том же умении отжирать памяти намного меньше?
Скажете 25МБ для мелкой трейной проги — это много?
Это серверная убунта.
Сегодня количество веб разработчиков в разы превышает количество других прикладных программистов. Писать софт на 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, и то и то — электрон, вот только в том как это все работает какая-то разница все же есть.
Рано или поздно придется отложить костыли и взяться за решение этой проблемы.
Но процессоры подходят к финалу эволюции
во первых не к финалу эволюции а к ограничениям элементной базы. А во вторых — причем тут процессоры?
Если что — основная проблема на сегодняшний день не процессоры, а скорость доступа к памяти и 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 то все равно не будет нужной скорости.
Рзработчики игр, например, все больше уходят в многопоточность
Ну вы сравнили, объемы вычислений игрушки какой и объем вычислений требуемый тому же шторму.
Шторм упирается в I/O. Да, есть нюансы, типа специализированный софт для симуляций, визуализации и т.д. который можно развивать только за счет параллелизма вычислений, но это опять же маленький процент прикладного софта.
Вот reindex проекта, использование диска было по-минимуму.
Качество не получилось, прошу прощения :)
Все программы бы работали сильно быстрее если сделать у 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 тоже в равной степени медленное. И скорость действительно сильно зависит от оптимизации кода.
На тех же Райзенах очень важна частота и вид оперативы, разницу даже видно невооруженным глазом. А у Интела тащит кэш.
Ну это мое мнение.
нет. Еще раз — проблема не в 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 все основано на открытом стандарте.
ну если мне память не изменяет, они просто все контролы на opengl запилили. Почти как это делают браузеры со своим html+css. Ну или вы можете сделать на webgl ;)
Подождите, я правильно понял, что они берут браузер, который написан умными людьми на C++/Rust и который с помощью OpenGL хардверно ускоренно рисует всякий HTML-GUI, и затем из всего HTML-GUI используют canvas, в котором с помощью OpenGL на JS рисуют свои кнопочки?
электрон выыигрывает тут так как в отличии от ораклавской graalvm все основано на открытом стандарте.
Ну стандарта может и нет, но код то у GraalVM открытый
Отличный пример, кстати. Слак, у создателей которого сейчас деньги не кончаются, а они жмотятся на портирование в нативный код. И телеграм, который с первой версии с намного меньшими ресурсами делался как надо (правда Дуров начинал с реально сильной командой олимпиадников, а не энтерпрайз макак). Но, к сожалению, инвесторы активно раздувают капитализацию слака, тем самым говоря, "красавчики, продолжайте в том же духе".
У меня 23.5 GiB ОЗУ. Увеличивал с 16, ибо стало не хватать. Ииии. Всё равно не хватает. Всё течёт. Уже выработался рефлекс. Вижу 90+% потребление ОЗУ? Ок, перезапускаю skype и виджет потребления озу на mate-panel показывает ступеньку вниз (падает 5-8% потребления). Перезапускаю Vivaldi — ещё 20%. Перезапускаю Chrome — ещё 20%. Оба браузера восстанавливают все открытые вкладки. Но память к прежнему уровню сразу не восстанавливается. Перезапускаю shutter, slack, tint2 — ещё по 10%. Т.е. просто перезапустив окружение я возвращаю себе 10+ GiB ОЗУ. День-другой и снова приходится повторять расстрелы.
Не могу понять, это нынче так софт пишут, если у меня что-то с системой не то? Раньше (пару лет назад) при 16 GiB ОЗУ я редко превышал 10 GiB отметку. Скажем когда запускал сразу 2 virtual box VM.
Думаю у каждого текущего приложения может быть своя проблема. Скажем какие там у tint2 (написан на C) могут быть кеши? А разпирает его порой больше 2 GiB. Shutter (python) растёт как на дрожжах с каждым новым скриншотом. Явно течёт память. Браузеры, те и правда могут что-то жесточайше кешировать. Потом текут отдельно взятые табы в них. Вот у меня открыт inoReader в Vivaldi. Кушает он сейчас немного не мало — 1400 MiB. Доходило и до 3+ GiB. В нём реклама течёт. Автор об этой проблеме знает — говорит покупайте премиум, там без рекламы. Skype и Slack текут потому что электронруки кривые, видимо, у авторов. Кто знает. Тут надо детективную история по каждому случаю проводить.
Он написан на плюсах и свифте, работает фантастически быстро. Но с памятью не всё гладко.
Вот сейчас я на них смотрю — слак — 500мб и 4 канала +8 чатов, телеграм 32мб 20 каналов и 30+ чатов.
При умножении на 6 — вы тоже ошибаетесь — непосредственно написание кода — это не 100% разработки. Спецификации, дизайн и аналитика едят гораздо больше, при этом шарятся между платформами процентов на 90.
вот у меня пред глазами 2 приложения. Телеграм и слэк. Обе отжираютт 600 метров памятиTelegram 600 метров — жесть, что вы с ним делаете если не секрет?
У меня 50-70 метров максимум:
был запущен 12 дней. После перезапуска сходу сьел 190 метров.
надо б обновить его уже конечно, но справедливости ради он так весь год себя ведёт, максимум за год было 760 МБ.
Для сравнения, вкладка гмейла ест как раз те 600мб.
На macOS меньше 300 со старта у меня не получается — snag.gy/nlQiEX.jpg
Они там свои тарифы просто так нарисовали?
Маленький инсайд, — зачастую ответ на этот вопрос — да (без шуток).
Что касается C#, это хороший язык (типизируемый, компилируемый, со сборкой мусора и с ООП), но не знаю, насколько легко на нем писать не привязанные к винде приложения. Вы пишете, WPF, но это будет работать только под виндой.
Что касается дельфи… он как бы немного устаревший.
Но это же не проблема. Telegram Desktop имеет вполне обычный «web desktop app» вид. Но к ресурсам не сильно требователен, отзывчивость GUI тоже адекватная. На Qt написан.
HTTP API, вебсокеты — все это в Qt есть. Для этого не обязателен браузер)
Например AvaloniaILSpy, дизассемблер .NET.
Невидимая рука рынка так решила, что месенджеры отжирающие по 300 метров памяти нужны, значит они нужны. Иначе спроса бы небыло.
Другой вопрос что возможно рынок так решил потому что качественно лучше ничего нет. Может быть вам стоит сделать свой продукт качественно лучше чем все что есть на рынке, и возможно на ваш продукт будет высокий спрос.
Нет конечно, и повторюсь — я за если кто-то возьмет и сделает достойный продукт. Реалии рынка в целом такие, что никто особо не парится. И да, не раз бывало когда на рынок выходит продукт, который чуть-чуть поднимает планку качества и только после этого остальные начинают что-то делать.
Я потому и говорю о невидимой руке рынка и все такое. Есть предложение и есть спрос. Спрос на более качественные продукты есть, но за неимением предложения в целом все мирятся с тем что есть. Это приводит к спросу на телефоны с 6-ю гигами оперативки, что уже не особо удивляет.
> И почему именно webrtc?
Ну webrtc это довольно удобный (относительно) стандарт. Во всяком случае альтернатив не особо много да и по распространенности и наличию готовых решений конкурентов у него на данный момент нет.
Поставьте себя на место даже не владельцев бизнеса, а менеджера разработки, перед которым стоит выбор: логистический и управленческий ад синхронизации пяти разных codebases и содержание команды в (как минимум) пять человек на мартышкин труд писать одно и то же на разных языках. Либо взять проверенный и работающий для 99% Electron и бурно развивающийся и богатый возможностями JS+React+HTML5+CSS, в которых JSON можно загрузить одной строчкой, а анимацию сделать двумя.
Electron — это, возможно, крайность, но тот же React Native — это вполне себе способ кросс-платформенной разработки, если есть задача сделать продукт, который можно развивать и поддерживать.
Переписывал тут старое одно своё приложение года 2 назад с win7+mysql на centos + mariadb. Всё, что мне пришлось поправить, это работу с сокетами и БД — по странице кода на каждый. Различия в ОС, да. Но вот в остальной части ничего не трогал — стандарты c++ не от ОС же зависят.
Но у меня нет графики. Даже если графика задействована, то она, по-прежнему, обёртка над логикой, прослойка между пользователем и логикой. Если же логика привязана к специфическим для ОС элементам управления, то я глубоко задумался бы.
p.s. за последние 3 года пользовался скайпом исключительно через web.
Несколько раз пробовал пользоваться звонками slack-а. Не смогли. То не заводится, то не слышно, то приложение уходит в какой-то вечный цикл, то ещё какая-то чертовщина. Так ни разу не удалось нормально воспользоваться им. А desktop-версия под linux у меня даже "взять трубку" ни разу не смогла (в отличии от браузерной).
Ну десктопное приложение на JS можно было писать под Windows со времён IE 5. Но единственное которым я пользовался это был интерфейс для ffmpeg или подобного конвертера видео.
Интересно в современой винде работают hta или нет?
Мое личное мнение, что Slack тормозит, потому что именно его код написан плохо, а не потому что он на Electron. Так как я часто пишу разный высоконагруженный код в браузер, собственно я пишу разный софт, который работает из под браузера и с большими данными и с разными анимациями, то я вас уверяю, что да, запуская софт при помощи Электрон — вы подтягиваете много в оперативку, но не он прямо ответственен за баги, а именно реализация.
Я искренне, вообще не понимаю, как разработчики уровня Slack позволяют такие тормоза, ведь это всего-лишь управление текстовыми данными и так как js позволяет все делать асинхронно, то нагрузку можно прекрасно балансировать.
Может меня заминусуют, но я люблю писать JS софт, это невероятно просто, но я знаю как писать его так, чтобы он работал быстро и даже парюсь, чтобы он не мучал батарейку, но мне не нравится, когда просто плохой софт выдают за проблему платформы.
Тот же Atom, давным давно был достаточно быстрым, но сегодня — он на столько тормознутый, что им невозможно пользоваться, но пробелма там же не с Electron, а именно с реализацией подсветки синтаксиса. На сколько я помню, все Webview редакторы используют одну и ту же библиотеку подсветки, что и приводит к абсолютно одинаковым тормозам, что Atom, что Adobe. Отсюда у меня простейший вопрос, кто те разработчики, которые это планировали и решили, что и такие редакторы стоит выводить в продакшн да еще и не фиксить столько лет? Но многие люди всеравно опользуются, не смотря на то, что редактировать уже даже стандартный файл не является возможным.
Я посмотрел свой диспетчер задач, никакой безумной активности в простое (именно активности) я не заметил, но из Electron софта у меня только Slack. Но знаете, что больше всего сжирает ресурсов в Скайпе? (Сейчас найти не могу, но раньше так было) — рекламный Баннер ), приходилось раньше открывать другой окно Скайпа, чтобы баннер ушел и нагрузка на CPU ушла.
Может меня заминусуют, но я люблю писать JS софт, это невероятно просто, но я знаю как писать его так, чтобы он работал быстро и даже парюсь, чтобы он не мучал батарейку, но мне не нравится, когда просто плохой софт выдают за проблему платформы.
…
На сколько я помню, все Webview редакторы используют одну и ту же библиотеку подсветки, что и приводит к абсолютно одинаковым тормозам, что Atom, что Adobe. Отсюда у меня простейший вопрос, кто те разработчики, которые это планировали и решили, что и такие редакторы стоит выводить в продакшн да еще и не фиксить столько лет?
Есть подозрение, что если никто не смог написать библиотеку лучше Webview, то может это проблема платформы и написать такую производительную библиотеку невозможно? По чисто объективным причинам, примерно тем же, почему хорошо структурированное нормализованное апи сталкивается с проблемой N+1.
Не поймите не верно- я сам android-разраб и пишу исключительно натив, и у меня JS-приложения тоже вызывают негодование.
Но IT правит бизнес. И только бизнес. И он двигает индустрию, разработчики к этому не причастны.
И вот когда начинаешь считать деньги- выясняется, что JS-приложения очень дешево обходятся. В том числе и с косяками. А еще выясняется, что время разработчика стоит дороже вычислительных ресурсов пользователя. Точнее эти ресурсы для бизнеса бесплатны почти совсем. И этими ресурсами бизнес расплачивается за скорость и дешевизну JS-фреймворков.
И тут два выхода:
1. Заставить бизнес платить за ресурсы пользователя. Не знаю чем и как, но это бы сделало фактор реально важным. Минус- много игроков уйдут с рынка
2. Стандартизировать API или вообще заставить всех поддерживать JS. Но тут минусов еще больше:
Все перейдут на что-то типа Chrome OS и конкурировать останется мало чем.
Внезапно выяснится, что подход с реализацией интерпретируемого языка с нестрогой типизацией сам по себе затратен. Ведь для системы уже нет разницы между Boolean и String. Экономить просто не на чем. Плюс в JS придется вводить много жизненного цикла сущностей, к чему он просто не готов. На выходе получаем неповоротливую тупую монстро-ось, но зато да- в JS локально можно будет из коробки, да. И бизнесу обойдется в копейки.
Вывод прост- в мире пишется много хороших, быстрых и экономных софтин. Но если общество привыкло есть
Вот интересно, когда JS, NodeJS и С работют вместе передавая все координаты с тачскрина телефона на Windows и управляют курсором, управлением текста и тд, то разве этого может быть мало для написания чатика? Slack тормозит, потому что сделан плохо, а не потому что Electron
И я написал это потому, что дожился до написания собственных интерпретаторов и виртуальных машин (не для JS. проприетарщина). И примерно с этого момента начинаешь понимать, что реализации слабой типизации без ЖЦ, или, например stateless- они все имеют ряд именно концептуальных проблем.
Да, разные реализации софта на JS будут показывать разную производительность. И на машине с i5 и выше, Вы, скорее всего, не заметите разницы в работе одной и той же простой логики на JS и Java и нативе. Но, чем логика жирнее, и чем машина слабее- тем больше будет проявляться разница.
Факт в том, что так или иначе- чтобы JS вращался нужно больше ресурсов. Ведь JS-примитив содержит больше информации, чем, например, C-примитив. Плюс нужно больше компонент, чтобы этот примитив обслуживать, адресовать. И это всё добро, призванное облегчить жизнь разрабу, надо где-то хранить. Конечно же, в оперативе пользователя.
Так что нет- одна и та же логика не может работать одинаково быстро на JS\Java\C чисто математически.
Со Slack другая проблема- ни Electron ни JS сам по себе не могут корректно работать с ЖЦ Win\Mac\etc… И не смогут- JS разработан дня веба, для него предназначен, и в нем должен оставаться. Попытки запихнуть JS в приложение- это как ехать на санках по асфальту летом- это реально, но не эффективно. Но дешево, если под рукой только санки. Так что, люди в Slack не криворукие, просто (слишком) экономные
Дождемся нативной поддержки JS и все )
А если вам совсем поплакать хочется за "прогресс человечества" — The Mother of All Demos, presented by Douglas Engelbart (1968)
Дождемся нативной поддержки JS и все )
Вот это и будет черным днем календаря, когда тысячи электрон-макак хлынут в десктоп. Проблемы — они всегда в кадрах, и если дать возможность плохим кадрам писать некачественный код — они ей непременно воспользуются.
Можно было писать без него, на чистом WinAPI, или с использованием сторонних фреймворков, тогда размер файла был от 12 КБ, насколько помню.
Современный Delphi очень продвинут, на нем можно графические программы под почти все ОС писать, а с помощью сторонней реализации Object Pascal — еще и под WebAssembly.
Меня заголовок статьи выморозил в обратную сторону — как будто они заявили, что электрон имеет все преимущества flash — компактность исполняемого файла, обратную совместимость, эффективность, малое потребление памяти...
Flash не просто так был стандартом для анимации и сложных веб приложений.
если нe учитывать «компактность» самого плеера
> обратную совместимость
AS2->AS3 разве были обратно совместимыми?
> эффективность
как это определяется?
> малое потребление памяти…
и немалое потреблениe процессора
Это я не к тому что флэш «плохой», но своих проблем у него хватало.
1) Можно использовать подход Xamarin`а: пишем общую логику на Rust, а GUI реализуем нативно.
2) Если нам не нужно поддерживать старые платформы, то можно использовать гибридный подход: использовать для отрисовки стандартную для платформы WebView, а код отрисовки и логику напишем на Rust.
3) А что собственно не так с Qt, на мой взгляд этот тот самый «нормальный кроссплатформенный GUI фреймворк»
Slack не пользуюсь, часто запущен Whatsapp десктоп, диспетчер задач постоянно на втором мониторе, потребления ресурсов Whatsapp не замечал, 300мб памяти занимает, соглашусь не мало. Также есть свое приложение на electron, нагрузки на процессор в свернутом режиме в фоне, тоже не замечал, памяти всего 111мб.
Также пользуюсь VS code, там порой видна в фоне какая то нагрузка, периодически бывает до 10%, но это совсем другое приложение.
Flash для десктопа был уже 10 лет назад и есть до сих пор, называется Adobe Air. Причем писать можно было и на js, точно так же как на электроне сейчас.
Интересно посмотреть на независимые результаты замеров после этих изменений.
Мне менять ноут или слак? Даже не знаю… на ноуте я еще и поиграть могу, и поработать — visual studio и та себя отзывчивее ведет.
- Оф. поддержки реакт-нэйтив для чего-либо кроме мобильных ОС нет
- VSCode написан на электроне и каких-либо проблем с его производительностью (в том числе на маке) я не вижу
- Можно призывать жаловаться и отказываться от технологии, а можно её совершенствовать
Прошло 15 лет, и вот результат.
Банально: то, что Slack висит в виде десктоп-клиента на каждой машине команды разработчиков, и жрет как не в себя — команду Slack не волнует?
Другое дело что разработчики слаки, вероятно, в слаке же и сидят. Получается, «плачут, колются, но продолжают
Ну и проблем у разработчиков, я уверен, нет. Как те посты одного из разработчиков (или просто хорошего тестера) Chromium — habr.com/post/420579 habr.com/post/421153
Пока оптимизация стоит дороже плашки памяти — картина меняться не будет. Только голосование ногами, только хардкор. Скайп до сих пор остается корпоративным решением, потому что он у всех есть, а не потому что он хороший. Аналогичное зависание может постичь и слак, поэтому все спокойны.
Ни в коем случае не оправдываю прожорливость слака, но вот что меня удивляет — стремление инсталлировать себе в систему всякую ерунду. Что там такого есть в чатиках, какая такая функциональность, что надо ставить приложение? Что такого умеет десктопный электрон, чего нету в веб-версиях? Нотификации блимкают, гифки в #offtop крутятся, мессаги отправляются. Давайте еще джиру в webview завернем, а чо.
А совсем по теме, ИМХО: разделяйте: JS, W3C APIs, browser's VM. Здесь ругают только последнее, вроде. Хотя и первые двое не идеальны, но все же — разделяйте!
Мне тоже не нравится электрон, и, иногда смотря на современные тенденции, мне хочется горько произнести "что же с нами стало?". котэ
Но вот какие есть кроссплатформенные UI, пусть для windows/linux/mac (мобилки в расчет не берем, это целый отдельный мир)? Qt (есть биндинги к другим языкам, например pyqt), GTK (тоже есть биндинги, например GTK#), JavaFX, Swing, Mono WinForms, Avalonia (хоть и сырая). Тысячи их.
Главное преимущество JS в том, что в нынешних реалиях, браузер (а следовательно и JS) есть практически на любой платформе
Поэтому, как только найдут решение как запускать JS приложение отдельным клиентом без дополнительной нагрузки в виде целого браузера
Но ведь вы только что назвали (и верно) такое важное преимущество JS, как то, что браузер уже скорее всего установлен. Так зачем изобретать костыльный велосипед для запуска JS без браузера, когда есть браузер? Просто запускайте приложение в браузере, не скачивая и не запуская отдельный инстанс.
А высокое потребление именно из-за инстанса браузера, HTML и встроенных технологий. С потребление процессора — скорее всего, разработчики программы что-то сделали не так. Если у нас нет задач, мы просто по идее должны спать до прерывания/окончания sleep.
Для сравнения, я пишу страничку (понимать как очень сложное веб-приложение), в которой js ест несколько мегабайт. Но в итоге при реальном открытии браузер может требовать и несколько сот мегабайт. Сделать что-то с этим нереально — твой код ест всего лишь несколько мегабайт. Дело не в js.
А высокое потребление именно из-за инстанса браузера, HTML (DOM, рендеринга и пр.) и встроенных технологий. С потребление процессора — скорее всего, разработчики программы что-то сделали не так. Если у нас нет задач, мы просто по идее должны спать до прерывания/окончания sleep.
Для сравнения, я пишу страничку (понимать как очень сложное веб-приложение), в которой js ест несколько мегабайт. Но в итоге при реальном открытии браузер может требовать и несколько сот мегабайт. Сделать что-то с этим нереально — твой код ест всего лишь несколько мегабайт. Дело не в js.
И да, кто считает, что дело в анимациях — нет, не в них. Они как раз работают быстро, т. к. ускоряются видеокартой.
давайте уж сразу вернемся к ассемблеру!
ну я начинал с асма, да.
страдал по поводу скорости и размеру, писал микропрограммы.
а толк?
все равно пришло время js и быстрой разработки
мне кажется, проблема в коде и разработчике, а не в технологии
если кодер не умеет оптимизировать, ему ничто не поможет
вы наверное живете в каменном веке
свой ноут я купил в 2011, тогда купил и поставил 16 гигов памяти, недорого это стоило
ноут летает, памяти дохрена
сейчас, 7 лет спустя, не знаю что там на рынке ноутов, не слежу, ибо не нужно, ноут прекрасно работает, но догадываюсь, что наверняка уже по 32 или 64 гигов у всех
32 гига это ужас сколько памяти и стоит наверное копейки и если на ней запускать волковкоммандер в 64 кб, то наверное да, лишняя…
но на дворе вроде 2018 и отчего бы эту память не загрузить то?
Это не смешно, что установленные герои меча и магии со всей музыкой и ресурсами весит 700 мегабайт, столько же, сколько весит один только гмейл, и это в несколько раз меньше, чем слаки всякие… Неужели эта игра настолько проще, чем показать переписку с датами и рюшечками?
но догадываюсь, что наверняка уже по 32 или 64 гигов у всех
Более 4 гигов редко встречаются у обычных людей. Кроме того еще 2 в ходу. Надеюсь вы не разработчик сайтов или SPA? Ну или хотя-б тестите свои работы на планшетах с 2 гигами оперативки и атомом?
32 гига это ужас сколько памяти и стоит наверное копейки
Ну если для вас это копейки… прикупите мне пару планок кингстона на 16? для меня 32 гига DDR3 прикупить сложно финансово даже за пару месяцев.
Нужна нормальная кросс-платформенная GUI-библиотека в стиле Delphi VCL, только под все платформы. Именно библиотека, из которой линкер сможет извлечь в бинарник только реально исполняемый код, а не убогий фреймворк, где в бинарник улетит всё вплоть до драйвера XBox и реально исполняемого кода будет хорошо если 1%.
Да что GUI, даже вменяемой кросс-платформенной TUI-библиотеки всемирный программерский гений так и не родил. Как-то вдруг выяснилось, что мол «консоль винды не умеет в цвет и всё сложно», в Linux «проблемы с зависимостями и всё сложно», а под Android просто «всё сложно».
И именно в этом заключается один из основных факторов популярности Electron. Потому что это единственное GUI, которое просто, блин, работает на всех платформах. Которое реально кроссплатформенное. Для которого по щелчку пальцев через npm подтягивается что угодно, а не как во всяких C++, где работа с зависимостями как бы не напряжнее собственно программирования.
А теперь ваш коллега тоже хочет поработать над проектом, и клонит его с Github'а. Но вот незадача — он сидит под виндою и тоже хочет, чтоб из-под винды собирались бинарники под всё сразу…
И вот тут-то сразу начинаешь мечтать если не об Electron'е, то о чём угодно, лишь бы это был не C++ с его охрененно «удобными» кросс-компиляцией, системой сборки и менеджментом зависимостей. Сразу возникают ассоциации с древним авто, где вы больше времени проводите под машиной, чем в машине.
Это просто плата за производительность и нативность.
Она совершенно необязательна. Например в Rust и (насколько я вижу) в вашем любимом хаскеле есть единый менеджер пакетов, сводящий добавление зависимости к одной команде.
Что, простите?
Вы об этом?
The easiest way to acquire the build tools is by installing Microsoft Visual C++ Build Tools 2017 which provides just the Visual C++ build tools.
Так это что бы быстро и просто получить весь тулинг, который необходимен вам для сборки приложения на rust под винду. За размеры винить надо не раст а мелкософт тогда уж. Ну и с C++ будет та же история в целом. И думаю не только с ним.
Добавлю что вся Visual Studio вам не нужна. С ней у вас может и получится 4-5 гигов, а вот сколько весит только билд тулз — проверьте сами.
Ну и опять же — это зависимости исключительно для сборки (сборка, линковка и прочие прелести).
Ну да. Конечно, можно винить MS, но ведь выбор этого тулчейна был по воле разработчиков Rust, их не не заставляли его выбирать.Они выбрали стандартный toolchain для платформы. На MacOS они используют Clang, в Linux — gcc.
А уж как и почему данный toolchain стал «стандартом де-факто» — точно не разработчиков rust'а нужно спрашивать…
Поставьте mingw и собирайте под него, в чем проблемы-то?
Я PHPшник, решил попробовать себя в компилируемом языке со строгой типизацией, чисто по фану
Изучай Haskell во имя добра! (С)
При этом эти же люди спокойно ставят 60-гиговые думы и не думают :)
Не вижу совершенно никаких проблем поставить даже 15гб обвязки, не говоря уж про 500мб.
С опасением качаю инсталятор (что за идиотская мода на программы для скачивания установщиков программ), и с грустью обнаруживаю, что тут качать-неперекачать.
Потому что в винде нет моды на однострочные установщики, как например для убунты:
curl https://sh.rustup.rs -sSf | shИнтерпретатор PHP весит в архиве 24 МБ, в распакованном виде раза в 2 больше, зависит только от Visual C++ Redistributable, который весит несколько мегабайт и уже давно у всех установлен. Конечно не очень правильно сравнивать компилируемые и интерпретируемые языки, но всё же.
Абсолютно не правильно. Не говоря уже про то, что сам компилятор может весить и не очень много, но стандартная библиотека включает в себя тысячи классов и десятки тысяч API. Например, в том же mingw 13 тысяч одних только бинарных файлов
Никто вроде не заставлял разработчиков Rust следовать этой моде. Могли бы взять тулчейн попроще и воткнуть его инсталятор к себе, чтобы ставилось одним кликом.
Дело не в этом. Виндузятники привыкли к установщикам — держите. Линуксоиды к скриптам — держите.
Смысл установщика в том, что он правильно определяет параметры машины. Какой процессор установлен, какая битность ОС и т.п. И в зависимости от этого ставит конкретный дистрибутив.
При этом эти же люди спокойно ставят 60-гиговые думы и не думают :)
Думы уже середнячки. 95-гиговый Red Dead Redemption 2 подвезли, вот чего бойся-то.
4 гига для тулинга для сборки — это норма. Да, вам скорее всего нужно из этого только 10%, проблема в том что предсказать какая часть понадобится разработчику сложно, а заставлять его как-то по хитрому конфигурить все это добро — как-то глупо.
Как бывший разработчик игрушек на флэш я очень скорблю по временам, когда была простая крутая платформа Fash/Flex с богатейшими возможностями и кучей средств разработки для инди-разработчиков на рынке
Многие годы назад я чисто из интереса покуривал эту тему — FGL, вот это все. Ребята, писавшие на флэше, нормально так денег рубили, были оригиналы, получавшие, бывало и 10К баксов за одну игру. Ну это если верить прохладным историям из сети :)
Slack — дерьмо для лохов, Electron не нужен.Смысл не потерялся.
И все вы, веб-разработчики: Выучите С или Rust или что-то в этом духе.
До C веб-разработчиков допускать не стоит в своей массе, а до Rust они и сами не дойдут (в своей массе).
Честно пытался сделать веб-приложение на Си, точнее, на C++. Не хотел, чтоб у меня программа тормозила как чёрт знает что на ровном месте и сосала батарею нетбука как вампир. Нашёл, на чём это возможно сделать: imGUI + SDL2. Какое-то время перестрадал в попытках это запустить, но-таки запустил. И вот, что обнаружил: в EmScripten, поскольку управление нужно возвращать постоянно в самый низ (ну это я и так знаю), в SDL2 под EmScripten не работает SDL_WaitEvent. Вместо этого есть только SDL_PollEvent, которую нужно дёргать из процедуры, которую настраивает emscripten_set_main_loop. И это единственный способ, я пытался найти EmScripten-специфичные альтернативы, чтоб подписаться на события и пробуждаться только когда события есть. Нету!
И вот, что получается. Если подписаться по умолчанию, то всё время вообще, когда CPU свободен, он рендерит кадр. Работает отзывчиво, да. Под 60fps. Но у CPU жрёт всё ядро при том, что необходимости в этом никакой нет, пока ничего не происходит. Хочется взять фомку и объяснить кое-кому разницу между 0% CPU и 100% CPU, и пояснить насчёт людей, которые выбрали C под Web, какую сторону в этом континууме они бы ожидали получить. Но ничего я не возьму. Всё бесплатно же. Или в интересах бизнеса. Нет такого государства, которое бы вкладывалось в программирование в интересах народа.
Где-то глубоко в кишках там настраивается куча обработчиков мыши, клавиатуры и прочего, и они тихонько подкладывают события в очередь SDL2 и больше никак об этом не докладывают. Не подкопаться. А поставишь пробуждения раз в секунду — жор CPU уменьшится, но будет слайдшоу по кадру в секунду. Впрочем, если 60 таких посекундных вкладок открыть — это будет то же, что одна, жрущая весь CPU. Angular, конечно, жрёт CPU как не в себя, но всё же не настолько плох, чтоб перестать справляться с 60 просто открытыми вкладками.
Можно попробовать всё же подкопаться и подписаться на те же самые события, но тогда нет гарантий, в каком порядке будут вызываться события. Может, сначала подкопанный обработчик вызовется, поглядит на пустую очередь событий SDL2 и успокоится. Там всё настолько сломано, что это просто невыносимо.
А поставишь пробуждения раз в секунду — жор CPU уменьшится, но будет слайдшоу по кадру в секунду.
А если поставить пробуждения раз в 30 милисекунд?
Electron это Flash для десктопа