Comments 264
Со временем, они поняли, что именно Electron является бутылочным горлышком для достижения желаемой производительности
Пресвятые Керниган и Ричи, неужели ж до кого-то стало наконец доходить!
Ещё бы до остальных дошло...
А кто нибудь может мне объяснить почему у меня VSCode с кучей всяких плагинов (т.е работающий с Typescript как полноценная IDE), использующий электрон, работает быстрее и стабильней чем IDEA (при работе с тем же Typescript) написанная на Java? Или чтобы быстро работало нужно прям на C писать?
Ну может потому что vscode это все таки ближе к паруснику, а idea это больше океанский лайнер?)
Т.е если взять, например, WebStorm, то он будет мощнее как IDE чем VSCode? Или к чему тут ваша аналогия? А по-моему опыту VSCode на больших веб проектах (моно-репо с кучей typescript пакетов) как раз быстрее, мощнее, и глючит меньше, я даже баг репортил по этому поводу, потому что достало.
VSCode — для нескорых языков полноценная IDE, например, для веб разработки ничем не уступает тому же WebStorm.
Уступает. Редактор никогда не будет IDE.
VSCode ужасно тормозит при поиске по исходникам большого проекта.
Очень сильно расстраивают конфликтующие плагины. Когда проект сложный с разнообразными системами развертывания, деплоя, виртуализации и т.д.
VSCode ужасно тормозит при поиске по исходникам большого проекта.
Большой — это сколько в цифрах?
VSCode ужасно тормозит при поиске по исходникам большого проекта.
Слишком сомнительно. Для поиска в VSCode используется ripgrep, быстрее которого ничего нет.
Для поиска в VSCode используется ripgrep, быстрее которого ничего нет.
Для поиска в VSCode используется ripgrep
Мы сейчас обсуждаем только простой полнотекстовый поиск или все таки в том числе всякие другие поисковые возможности, анализирующие содержимое, навроде поиска вызовов функций, использования элементов языка (с учетом разного рода импортов типа *) и т.д.?
vscode делает, например, поиск использования приватного свойства класса (300 строк) настолько долго, что после phpstorm я успеваю нажать еще пару раз, думая, что оно не сработало. шторм открывает юзейджи практически мгновенно
я поставил какой-то топовый по загрузкам экстеншен, без него это совсем не работало.но не надо забывать,что php - это на самом деле тоже расширение для idea, иными словами phpstorm - это преконфигуренная идея
Я упростил, да. Тем не менее это все же расширение, я про это. Сама идея - технически опенсурсная, можно также написать свое расширение под %языкнейм% (как было например с андроид студией, насколько я помню)
https://github.com/JetBrains/intellij-community
Т.е. фактически разница в том, что к одной системе написали годное расширение, а к другой нет, и за годное хотят деняк.
upd. попробовал поставить расширение php Для idea ultimate - работает так же моментально все после индексации. Так что тезис про преконфигуренную идею работает
+100500!
Во-первых, потому что VSCode написан компанией, которая делает лучшие среды разработки на этой планете (это главная причина)
IDEA же изначально была глотком воздуха в мире безумства авторов Java, которые изначально(!) решили что джаве своя IDE не нужна. Но основная проблема Java с жором памяти никуда не делась.
Во-вторых, потому что JavaScript там всё же компилируется, благодаря V8. Без этого Electron был бы не юзабелен.
От себя добавлю, что Visual Studio на винде работает быстрее чем IDEA на MacOS (проверялось на одном интеловском ноуте Apple). А так покупайте Мак - с его железом разница в производительности не ощущается, если памяти 32Гб
Т.е я правильно понял, что в посте где за производительность, ругают электрон (=VSCode) вы предлагаете покупать комп помощнее, чтобы быстрее работала Java(=WebStorm), ведь электрон и так работает быстро?
PS. Я и так сижу на Маке :)
Моя первая и единственная попытка переезда на райдер провалилась после того как я обнаружил что там даже не вся функциональность решарпера есть. Например тогда не было превью начала блока { } при наведении на закрывающую скобку. И это уже была релизная версия райдера, не превью.
Ну и в энтерпрайзе на райдер переехать можно только если вы не зависите от каких-нибудь библиотек, которые в студию плагины ставят.
Я на нем с бетки сижу(на работе - с релиза) и чет особо не страдаю от отсутствия превью блока)
Лично меня достала скорость работы вижлы с решарпером, и поэтому я перешел на иде пошустрее, пусть даже там чего и не было на момент релиза.
Это Visual Studio лучшая среда разработки? Очень голословное утверждение. Про её производительность и про Resharper я вообще скромно умолчу.
Потому что ms переписала критические куски кода на webassembly
А кто нибудь может мне объяснить почему у меня VSCode с кучей всяких плагинов ..., использующий электрон, работает быстрее и стабильней чем IDEA
Потому что ты всегда побеждаешь если волен выбирать удобного соперника. IDEA действительно тормозит, но это не очко в пользу приложений на электроне. Есть замечательный Sublime Text, приложение одного класса с VSCode, который всегда работает быстрее последнего. Есть намного более тяжелая Visual Studio которая тоже работает быстрее чем VSCode.
Собственно, и электрон можно допилить до юзабельного состояния, но какой ценой? VSCode делает огромная команда разработчиков за которыми стоит бюджет MS, Sublime пишется на плюсах командой из одного или двух разработчиков (насколько я знаю).
А IDEA довольно стара и видимо страдает от неудачной архитектуры языкового ядра общего для всех продуктов JetBrains.
Да ещё и батарейку у ноута VSCode расходует намного гуманнее, чем Idea
Хуже всего то, что эти уважаемые "синьоры" только после неудачного опыта поняли, что на JS всё будет тормозить.
Присмотритесь, до них все еще не дошло, они переписывают графический фреймворк.
У меня один вопрос: если все вокруг точно знают как нужно сделать, то почему за прошедшие 9 лет с момента представления Электрона его убийцу так и не написали?
Бизнес ориентируется на скорость выпуска продуктов, а не на качество продукта. Иначе можно проиграть конкуренту, который говнокодит такую же идею быстрее.
Хуже всего то, что эти уважаемые "синьоры" только после неудачного опыта поняли, что на JS всё будет тормозить.
Бизнес ориентируется на скорость выпуска продуктов, а не на качество продукта. Иначе можно проиграть конкуренту, который говнокодит такую же идею быстрее.
Вы будто сами с собой разговариваете.
Но текущая команда Zed — 4 человека.
Если зайти в обсуждение любого софта на электроне, то половина будет ТОЧНО знать какую технологию стоило использовать, вместо электрона, чтобы все работало быстро. Где все эти сотни убийц электрона от тысяч разработчиков по всему миру?
Вы будто сами с собой разговариваете.
Но текущая команда Zed — 4 человека.
Так я не про Zed говорил, а про кучу других продуктов по миру.
Где все эти сотни убийц электрона от тысяч разработчиков по всему миру?
А вот об этом как раз мой предыдущий коммент, на который вы отвечали.
Где все эти сотни убийц электрона от тысяч разработчиков по всему миру?
Да просто разработчиков согнали быдлокодить на Электроне по-быстрому, дабы компании могли увеличить прибыль за счет сокращения затрат на разработку. Если бы силы, вложенные в Электрон, были бы вложены в разработку нормальных альтернатив - вопросов бы не возникало.
Если бы да кабы в саду выросли грибы.
Везде заговор ради того, чтобы сделать ТС мейнстримом.
Какой еще заговор, обычный маркетинг. Жабаскрип был распиарен как "легкий" язык для веба еще в момент создания, далее спрос на веб породил огромное количество специалистов, а дальше уже принцип снежного кома.
Но почему все эти тысячи людей, который точно знают как нужно не собрались и не сделали нормально?
Каждый пишет что "заговор" "распиарен" итд, но в итоге разгадка всегда одна — ничего лучше просто нет. И можно сколько угодно чесать языками и поливать JS, но комментарии не превращаются в код и тем более в продукт.
Еще вчера для быстрых программ ничего кроме С / С++ не было, сегодня есть раст, зиг и на них пишут программы, потому что они объективно лучше.
Просто возьмите и напишите убийцу JS, станьте миллионером, это ведь не сложно, по вам видно что вы ТОЧНО ЗНАЕТЕ ЧТО НУЖНО ДЕЛАТЬ.
ничего лучше просто нетА каков критерий «лучшести»? Electron-приложения, например, на диске занимают не менее 100 МБ только за счёт исполняемого файла, а ведь вместе с ними ещё и пачка DLL/SO идёт в комплекте (зачем мне та же ffmpeg.dll для VS Code?). Да, дисковое пространство не такое уж дорогое, но когда даже Hello World весит по 100+ МБ… тут явно есть какой-то подвох.
Вторая проблема Electron — вся его браузерная половина. Большинство приложений даже близко не используют всю ту бездну
Вы только что и написали критерий "лучшести". Что-то такое, что бы позволяло писать кросс-платформенные графические программы, где hello-world весил бы меньше 100 МБ.
Там, где ненужные фичи можно отпилить и не кидать в бандл.
Да 100мб куда уж там, если что у меня на телефоне 1Тб памяти. Сравнивать hello world очень прикольно, но фишка в том что в 100мб уже содержат все. Да, да как только вы в своё приложение, назовите язык, начнёте добавлять нужные вам библиотеки его размер будет доростать для электрона. Поэтому никто и не парится. Вам не нужен ffmpeg до того момента пока ваш маркетинг отдел не попросит вас засунуть видосик с овервью обновления прямо в приложение. А потом ещё окажется что в ваше приложение все равно нужно вставить веб-вью по какой нибудь причине. И тут все уже переплюнули размер электрона
Electron-приложения, например, на диске занимают не менее 100 МБ
А что они не сделали как с .net и vc_redist? Чтобы Electron тоже устанавливался отдельно.
В некоторых линуксах так и сделали https://repology.org/project/electron/versions. Оказалось, что разработчики не спешат использовать актуальный Electron. В итоге почти каждая версия нужна одному-двум приложениям, что сводит на нет преимущество отдельной установки.
Забавно, что ни Atom, ни VSCode не используют свежий Electron.
В случае с VC redist и .NET Framework таскать библиотеки с приложением запрещено лицензией, поэтому разработчики вынуждены использовать установленные глобально. Те же Java и Python (а теперь и новые .NET) многие приложения таскают с собой несмотря на возможность использования глобально установленных версий. Просто потому, что так надёжнее и не нужно задумываться о совместимости с будущими версиями.
Но почему все эти тысячи людей, который точно знают как нужно не собрались и не сделали нормально?
Причин много. Во-первых, без пиара технология не взлетит вообще, а преодолеть пиар технологий конкурентов в принципе не факт что возможно, учитывая что за ними стоят производители браузеров. Во-вторых, люди в принципе обычно вместе не собираются - нужна компания и нужны деньги, которые никто не даст, потому что см. "во-первых".
ничего лучше просто нет.
Ну это как раз "от создателей" лагающего веба и фреймворков типа электрона. Игры проводят сложнейшие симуляции 60 и больше раз в секунду, HFT-системы работают с наносекундными задержками, но вот для на веба ничего лучше просто нет.
Еще вчера для быстрых программ ничего кроме С / С++ не было, сегодня есть раст, зиг и на них пишут программы, потому что они объективно лучше.
Ага, "объективно". Это вы спроецировали фронтендерское "новый модный фреймворк лучше старого"?
Просто возьмите и напишите убийцу JS
Зачем их писать? Их уже вагон и маленькая тележка. Возьмите любой современный не-эзотерический язык - он будет лучше чем JS. А теперь попробуйте убедить Гугл впилить поддержку этого языка в Chromium наравне с JS. И после этого подождите лет 10, пока он раскрутится.
Я дико извиняюсь, но поддержка WebAssembly впилена в современные браузеры. И даже понадобилось меньше 10 лет.
Справедливости ради - WebAssembly не особо запустишь без JavaScript-обвязки...
Я тоже извинясь, но WebAssembly - это средство выработки выученной беспомощности у веб-программистов. Так извращенно добавить нормальные языки надо постараться, это под силу лишь лучшим из тех, кто заинтересован в сохранении доминации JS.
У Electron есть один "фатальный недостаток". https://lurkmore.to/Фатальный_недостаток
Но если мы ограничиваемся только одной платформой, то проблем нет и убийц Electron хватает. Скажем, под x86+Windows у нас есть .NET Framework, который буквально нокаутирует Electron.
Да нет, достаточно давно все уже есть - Qt на C++ способен в запуск на большинстве популярных платформ. На Mono был Xamarin. С появлением .Net Core - Avalonia, с появлением .Net 5 - MAUI.
Qt на C++ способен в запуск на большинстве популярных платформ
Маленькая загвоздка: Qt на C++ не способен в быструю разработку.
На Mono был Xamarin. С появлением .Net Core - Avalonia, с появлением .Net 5 - MAUI.
За пределами энерпрайза об этом почти никто не знает и не хочет знать.
Кхм кхм...так то еще Delphi умеет в кросплатформу и быстро.
у QT проблема с лицензией, с 5-й версией они решили периеграть лицензию, и выпускать на ней коммерческий продукт стало не выгодно.
почему за прошедшие 9 лет с момента представления Электрона его убийцу так и не написали?
Tauri на расте опять же)
Ну это опять раст, да. Еще пять лет назад про него знало слишком мало человек))
Просто громче всего "закопать электрон и переписать на нативщину" кричат обычно плюсовики, которые не могут в адекватные сроки сделать ни того, ни другого.
Все время забываю, что новый "красивый" редактор комментов хабра съедает хтмл тег </sarcasm>
Плюсовики вообще не кричат особо, опять проецируете на фронтендеров.
Эхх, давно я не ловил старого доброго UB. И что со мной не так...
Хах, это вы ещё раст не коНпеляли))
Долгая компиляция обусловлена необходимостью инстанциировать шаболоны и инлайнить всё, что плохо лежит. Это, безусловно, большой минус для пользователя, но и немалый плюс для получившейся на выходе компилятора программы, так что в итоге баланс соблюдается.
Насколько лично мне известно, std::ranges из C++20, предоставляющие функциональный доступ к контейнерам, чуть ли не только в "плюсах" могут работать так же быстро, как написанные от руки циклы, и именно благодаря этой фиче компилятора.
Полотна ошибок же в шаблонном коде давно стали притчей во языцах, но ситуация начинает улучшаться: концепты позволят проверять соответствие интерфейса при вызове библиотечных функций, а не глубоко внутри них, как это было раньше.
Насколько лично мне известно, std::ranges из C++20, предоставляющие функциональный доступ к контейнерам, чуть ли не только в "плюсах" могут работать так же быстро, как написанные от руки циклы, и именно благодаря этой фиче компилятора.
Это было в расте еще лет 5-7 назад (а может и больше). https://doc.rust-lang.org/std/iter/index.html
Ленивое выполнение std::ranges умеют?
Это было в расте еще лет 5-7 назад
В более-мене современном виде в C++ оно появилось лет 12 назад в Boost (а первые попытки затащить были в в далёком 2003), но до реализации в стандарте ехало долго: библиотеку полировали, и тем временем учили компилятор не выдавать полотна сообщений в ответ на одну ошибку при инстанциировании шаблона.
Ленивое выполнение std::ranges умеют?
Так это ж стандартная фича для таких библиотек.
Конечно не кричат, устали кричать после всех UB.Скорее после настройки окружения и тулчейна в пачке контейнеров, по контейнеру на каждую из целевых платформ. Процесс сборки проекта в C++ абсолютно не кроссплатформенный и по-настоящему мучительный.
Build smaller, faster, and more secure desktop applications with a web frontend
Язык другой — грабли те же.
Не надо его убивать, ему просто не надо жить.
Слепая ненависть к JS detected :)
Все зависит от кривизны рук. У меня есть примеры оверлея для игры (более одного), и все летает без просадки FPS. И тот же клиент для БД (забыл как его, зыбал как его, но кажется что-то для mongodb) который тормозит просто когда по нему мышкой водишь.
Так всё зависит от количества текста. Ваш оверлей видимо три строчки выводит и всё.
Например, в HTML не сделать нормальные списки сообщений, в случае применения для мессенджеров. Всё тормозит.
Например, в HTML не сделать нормальные списки сообщений, в случае применения для мессенджеров. Всё тормозит.
А пацаны-то и не знают, что существует виртуализация.
Которая, кстати, становится нужна только когда ваши "нормальные списки" доходят хотя бы эдак до тысяч элементов, если вы печетесь о юзерах со старыми мобилками. И до десятков тысяч, если нет.
Если у вас "нормальные списки" начинают тормозить раньше — проблема в вас, а не в HTML.
Ну как бы я не настоящий JS'ник, я пишу под Андроид и на Расте. А вижу тормоза именно как пользователь. Везде.
А вижу тормоза именно как пользователь. Везде.
Я тоже. А потом как "настоящий JS'ник" прихожу куда-нибудь работать и вижу там на фронте список на 100 элементов, который тормозит. Не потому, что список, и не потому, что на 100 элементов. А потому, что фронт написан настолько убого, что перерисовывается целиком на любое действие пользователя (а иногда и на бездействие тоже).
А потом прихожу работать в другое место, и вижу там то же самое. И так далее. И потом когда как пользователь хожу по тормозящему вебу — уже не удивляюсь ничему.
Дело не в HTML, и даже не в JS, а в минимизации затрат на разработку. В конце концов, я как "обычный пользователь" с андроидом вам тоже могу предъявить, что в мобилке кругом почему-то безумно тормозные и забагованные приложения. Видать, чё-то не на расте их пишут ^_^
Недаром же каждый фонарик требует 100500 разрешений, включая доступ к отправке SMS. Сразу видно, что разработчики заюзали какие-то готовые компоненты с параметрами по умолчанию, которые запрашивают всего и побольше.
Оверлей поверх всего окна, полупрозрачный и не с самыми дешевыми анимациями, читает положение с логов игры как только туда что-то залетает и "говорит куда лететь". Если есть желание посмотреть кишки - там сылка на гитхаб в описании.
https://www.youtube.com/watch?v=cQ344CdLF6U
Отмечу только что в соседнем треде еще и nodejs процесс который передает в вэб приложение килобайты JSON с логов игры.
> Так всё зависит от количества текста
Все зависит от всего. Не блокируйте event loop и учите CSS, не пишите "квадраты" там где можно отделатся обычным for/loop - и все будет хорошо и не будет ничего тормозить.
Дело не в электроне, а скорее просто в устаревшем вебе, который вероятно отправится на свалку вместе с кастомными костылями вроде реакта, вью и прочих хоть и весьма изящных, но всё же костылей и стероидов.
А вы заметили, как любое описание софта без ссылки на исходники воспринимается как скам?
Электрон это не редактор. Редактор - это atom. Электрон делался для него и изначально назывался atom-shell. Когда поняли что получилось нечто большее, оформили и назвали электрон (атом состоит из электронов).
атом состоит из электронов
Вот с этим то знанием они его и написали, электрон этот Ваш:)
Ну электрон модно хаить, а по факту ?
Те люди которые пишут гавно на электроне, напишут что то стоящее на с++ ? Вы реально в это верите ?
Так это не зависит от инструмента. Дизайнеры делают макет, разработчики просто его исполняют.
Java в тысячу раз лучше этого электронаЗвучит как «электромотор лучше экскаватора».
Ну и да — Qt Jambi (Java байндинги для Qt), на который я ссылку дал — это выдуманный продукт? Или неиспользуемый и заброшенный?
электрона поганого.
То что вы использовали говяные выгрызки не значит что все гавно. Я вот Яву тоже не люблю потому что "тормозит" и выглядит как windows 3.11 ))
атом состоит из электронов
Не то чтобы электронов там не было, но мне кажется, вы что-то упускаете. ;)
Добавил примечание, чтобы убрать двусмысленность.
Да неужели-ж молитвы были услышаны?... Хотя вряд-ли тонны софта будут переписаны под новый фреймворк. :-(
да со временем понапишут новых хипстерных аналогов, некоторые приживутся, но времени понадобится, конечно, много
Тут еще нужно чтобы новый фреймворк оказался столько же удобным для разработки (сам я под электрон не пишу, поэтому продаю за что купил). Один из факторов успеха электрона в том, что там можно писать на JS-е, знатоков которого полно. При этом зная веб-стек в лице HTML, CSS + JS стало возможным получить настольное приложение почти любому желающему (опять же, качество этих приложений оценивать не хочу сейчас).
И вот теперь у нас есть фреймворк на Rust (фреймворк ли? я пока понял, что там редактор). Каким будет порог входа в него для не-растоводов?
Не удержался ...
https://www.youtube.com/watch?v=aOV4b7CVYSU
Средство текстовой коммуникации, встроенное в редактор
Вот что-то уже начинает напрягать. Просто сделайте нормальный не тормозящий редактор. С нормальным фолдингом на основе лексера, а не регулярок (поголовно все редакторы не могут нормально свернуть XML в котором есть куски многострочного текста, так как реализуют фолдинг на основе отступов, а не структуры документа). Встраивать всякие свистелки для полутора человек не надо
В Language Server Protocol есть folding ranges, поэтому почти любая современная ide должна, в теории, это уметь с плагинами. Попробуйте, например, VSCode вместе с https://marketplace.visualstudio.com/items?itemName=redhat.vscode-xml
Зато фолдинг на основе отступов позволяет получить эту функцию из коробки для практически любого блочного языка программирования. И не нужно ставить плагины и lsp (которых у малоизвестных языков может вообще не быть)
Очень полезная и нужная фича.
Какие сейчас варианты? Кидаться исходниками через мессенджеры? Делать коммиты на каждое изменение, если нельзя вставить исходник в мессенджеры?
Шарить экран? А если интернет плохой, надо вдвоем редактировать, а коллега вообще не может голосом разговаривать?
Единственное, чем не отвратительно пользоваться сейчас — это геррит, но это инструмент для ревью.
Как вам Sublime Text?
Да што уж там, Zoom сразу встроить можно. Абсолютно непонятно, зачем это нужно в редакторе. Я был очень удивлен, когда нашел для VSCode дополнение Stories
А я вот не соглашусь.
Нормальных не тормозящих редакторов вагон и тележка. Да тот же neovim вас удовлетворит.
Зато нормальных не тормозящих IDE нету. Потому хороший функционал в ядре программы очень даже нужен.
использующий GPU для рендеринга
Дайте угадаю, если запустить параллельно еще какую-то софтину использующую гпу дико тормозит? Почему-то даже при небольшой загрузке гпу очень хреново справляется с мультизадачностью.
и они считают, что Zed не удалось бы создать с помощью других инструментов
Громкое заявление. Но ничего ж нет. Софта нет, репозитория нет, LSP, не говоря о более навороченных штуках лишь только "будет". Tree-Sitter на треть состоит совсем не из раста.
Как выше отмечали, электрон и не редактор. Atom редактор. VSCode редактор. До последнего, с контейнерами, удалённой работой по SSH, Live Share и прочим вагоном кастомизаций этим прогрессивным штукам догонять и догонять и ещё большой вопрос, какой перфоманс на метр багов будет при сопоставимом функционале.
Новость максимально кликбейтная.
А надо догонять? Я не пользуюсь и половиной из фич vscode, не говоря уже о монстрах типа webstorm. Если они сделают что-то типа атома, но быстрее - отлично, дайте два.
VSCode достаточно быстр даже на ужасающе древних штуках типа Np-nc110p, которые хочется выкинуть в окно ещё до того как оно забутается. Если нужно прям ещё быстрее, есть vim. Который по фичам тоже пока впереди. Ну а так, если вам нужен просто блокнот, то спор ни о чём.
Дело не в быстроте, а в минимализме. Не люблю использовать адовые комбайны когда могу не.
Много лет назад была такая Visual Studio 6, написанная на С/C++ Winapi/MFC. Или ранние версии С++Builder. Прекрасно работали даже на старых машинах (без всяких GPU). А на новых просто летали. Но кому-то понадобилось писать IDE на C#, на Java, на JS... Ну хорошо что одумались и вернулись на язык системного уровня (хотя я все равно не понимаю зачем в этой задаче GPU).
Основная задача IDE - интегрированность, главным образом компилятора и отладчика. Многие "текстовые редакторы для программистов" имеют быстрый интерфейс, но средства разработки к ним прикручены сбоку (или, что еще чаще, их нужно прикручивать вручную). Хуже всего с отладкой - ее как правило нигде в нормальном виде нет.
Прекрасно работали даже на старых машинах (без всяких GPU). А на новых просто летали. Но кому-то понадобилось писать IDE на C#, на Java, на JS...
Повышение уровня абстракции всегда чего-то стоит. Сделав редактор на жс, к примеру, пострадала скорость работы и потребление памяти стало больше, но разработчики смогли реализовать больше фич.
Что я хочу сказать, что не только плохое приходит с использование более ввсокоуровнего языка.
Сделав редактор на жс, к примеру, пострадала скорость работы и потребление памяти стало больше, но разработчики смогли реализовать больше фич.
Я не думаю, что это так. VSCode и Atom, оба хоть сколько-то популярных Electron-редактора, скомпилированы в js скорее потому, что оба выросли из проектов браузерных редакторов/ide, и во многом ими и остаются (GitHub Codespaces это VSCode, к примеру). В браузере выбор языков и технологий намного меньше, по крайней мере, до широкого распространения тулинга и библиотек для wasm.
Они не выросли из браузерных редакторов. Наоборот, до браузера они доросли только спустя несколько лет.
Electron был выбран как единственный инструмент, на котором можно было создать кросс-платформенное графическое приложение в приемлимые для ребят сроки.
Какую альтернативу вы предложили бы им в 2012 году? wxWidgets?
Можно сколько угодно болтать о том, что на библиотеке Х из экосистемы С/С++ можно сделать все то же самое, но "нативно" и используя 10 МБ оперативки, но за десять лет эти разговоры так и никуда не переросли, "убийцы" электрона на с/с++ так и не появилось. Как и не появилось возможности использовать асинхронщину и многопоточность в с/с++, так же удобно, как это происходит в современных языках.
Они не выросли из браузерных редакторов. Наоборот, до браузера они доросли только спустя несколько лет.
Atom начинался с Ace, собранного в standalone-приложение. VSCode начинался с Monaco, который пилили для всяческих нужд Azure. Да и Visual Studio Online был там с самого начала.
Electron был выбран как единственный инструмент, на котором можно было создать кросс-платформенное графическое приложение в приемлимые для ребят сроки.
Ага, особенно учитывая, что для Atom этот Electron еще надо было сначала написать. Да и виджетов в нем никаких нет, ребята свои UI-фреймворки писали, фактически.
Какую альтернативу вы предложили бы им в 2012 году? wxWidgets?
Из того, что знаю, вполне неплохо чувствовали себя IDE на Java.
Из того, что знаю, вполне неплохо чувствовали себя IDE на Java.
Эклипс? Ничего хуже для редактирования текста человечество не придумало. Когда я пробовал ей последний раз пользоваться, она просто валилась от любого взмаха ресницами. Не понимаю, каким чудом мне удалось тогда в этом написать что-то под Android...
Википедия говорит, что IDEA началась еще в 2001 году. Но, опять-таки, я слишком плохо знаю тогдашний мир IDE.
Из того, что знаю, вполне неплохо чувствовали себя IDE на Java.
У меня есть старенький ноутбук, с которого иногда приходилось вносить правки в код. Так вот — на vscode я их вносил за то же самое время, за которое IDEA только запускалась
Давно мучает вопрос, почему каждый второй айтишник правит код со стареньких ноутбуков?Причём не изредка, когда снежный буран в степи застанет, а много и регулярно, так что не лень сборки редакторов с плугинами для этого подерживать.
Какую альтернативу вы предложили бы им в 2012 году? wxWidgets?
Sublime Text появился в 2008, изначально C++ и Python.
В 2008 он был хорош, но потом стал очередным "продвинутым блокнотом" вплоть до 2020.
Sublime Text появился в 2008
Только под Windows.
К тому времени, как они допилили кросс-платформенность, уже появился Atom.
Затем, понадобилось еще 7 лет, чтобы допилить это до функционала вскода образца 2015 года.
В принципе, это все что нужно знать о скорости кросс-платформенной разработки графических приложений на С++.
В итоге мы получаем засахаренный язык, кторый без него уже не используется. Такими темпами, скоро складывать числа в js нужно будет через сахарный метод sum(a, b)
Только вот студия не кросс-платформенная и написана огромной командой, у которой есть ресурсы, чтобы обмазаться санитайзерами, анализаторами и прочим. Но она все равно падает, а интерфейс может замереть при длительной операции из-за того что написать многопоточное приложение на c/c++ все равно невероятно сложно.
Последняя студия без плагинов открывает хеллоу-ворлд на моём 12-ядерном компьютере с 32 ГБ оперативки и nvme около 15 секунд. VSCode делает это за 2-3.
Студия есть под мак, но фронт там переписан с нуля. Версии для линукс нет.
Даже странно слышать такое про студию - мой знакомый майкрософт-бой говорил, что там только пони по радуге бегають да бабочки летают, и ни про что подобное не упоминал))
Даже странно слышать такое про студию
Так потому-что это вранье. Вижуал студия за 15 секунд вполне грузит себе Unreal Engine 4.
А вот зачем врать "КАКОЙ МИКРАСОФТ ПЛОХОЙ" - это я уже не знаю. Может ты знаешь? :)
написана огромной командой, у которой есть ресурсы
Вы прямо досконально знаете, какие у нее ресурсы и какой объем функционала нужно поддерживать, или это диванная аналитика?
Последняя студия без плагинов открывает хеллоу-ворлд
Какую вы считаете последней? У меня аналогичная конфигурация — "голая" VS2022 открывает проект с 20K+ SLOC за 3-5 секунд, заметно быстрее чем 2019. С R# — да, получается ближе к 15 секундам, но лично в моем понимании он того стоит.
Сравнивать с VSCode не совсем корректно, т.к. они в разных весовых категориях — как Paint.NET и Photoshop. К счастью, ими можно пользоваться параллельно, выбирая каждую для подходящих задач.
Сравнивать с VSCode не совсем корректно
Действительно, вскод — кросс-платформенный, а студия — нет.
т.к. они в разных весовых категориях — как Paint.NET и Photoshop
Абсолютно верно. Что студия, что фотошоп — тормозные, падучие и однопоточные монстры. VSCode заменил студию у массового программиста, Affinity Designer заменил фотошоп у массового дизайнера.
Ну вот опять — вы собственный опыт обобщаете на всех.
Кто такой "массовый программист"? Веб-разработчик? Большинство веб-ориентированных языков динамически (или частично) типизированные, поэтому для разработки на них возможностей VSCode действительно хватает.
На противоположном конце спектра находится энтерпрайз — банки, предприятия, биржи и тому подобное. Там тоже приличное количество программистов работает. Вы знаете истории, где "vscode заменил студию" в контексте реально крупного энтерпрайзного проекта на Java, .NET, C++? Я не знаю, но с удовольствием послушаю.
Работаю в крупном российском кровавом энтерпрайзе (не банке и не бирже).
Основной редактор по результатам опроса — VSCode, разработка на С/С++.
Получается, вы собственный опыт обобщаете на всех?
Ну опять — вы опросили ваших непосредственных коллег в одной конкретной компании. Из этой "статистики" никакой вывод сделать нельзя, но было бы интересно почитать статью с опытом и конкретными числами: какой размер проекта, сколько разработчиков, в какой момент и почему перешли и т.д. — иначе это спор о "настоящем шотландце".
Аналогично, только в сравнении с Idea, Android Studio и XCode
при чем тут C++? VS написана на C#.
Изначально на C++, и только начиная с VS 2012 отдельные части (в основном UI) начали переписывать на C#. Лишь к VS 2022 смогли выпустить 64-битную версию, потому что устаревший плюсовый код не позволял сделать это ранее, хотя потребность была уже давно (приходилось выносить куски кода в отдельные процессы, чтобы уложиться в 32-битное адресное пространство).
так сейчас не осталось кода c++?
Остался, как минимум ядро IDE, отладчик и подсистемы для старых типов проектов. Тем не менее, если 10 лет назад написание расширений к IDE представляло из себя пляски вокруг COM, сейчас всё больше подсистем доступно из .NET напрямую, что сильно упрощает разработку. Навскидку, если посмотреть на запущенный процесс IDE, из 1000+ загруженных DLL нативных осталось порядка пары десятков (не считая входящих в состав Windows).
И да, в предыдущем комментарии я немного ошибся, переписывать начали с VS 2010.
Студия есть под мак, но фронт там переписан с нуля.
Строго говоря, студия под мак это вроде бывший Xamarin Studio, который к Visual Studio не имеет отношения.
Последняя студия без плагинов открывает хеллоу-ворлд на моём 12-ядерном компьютере с 32 ГБ оперативки и nvme около 15 секунд. VSCode делает это за 2-3.
Это странно, на гораздо более слабом железе студия без плагинов открывает и индексирует hello world за те же 2-3 секунды. А без индексации (анализа исходников) открывается солюшен любого размера)
Студия есть под мак, но фронт там переписан с нуля
По-моему это Sublime Text, а не Visual Studio.
А я вот помню, что после совершенно тупой студии и всяких билдеров с дельфами появление идеи воспринималось просто как чудо - она хоть про язык что-то понимала, что повышало продуктивность разработки в разы. И было почти плевать на ее скорость.
что-то вы странное помните. В билдере поддержка их диалекта была очень хороша.
Я помню, что когда я ими пользовался, там даже базовых рефакторингов не было. Потом, наверное, появились, но я уже свалил на java и intellij
Это был комментарий, про то, что раньше все прекрасно работало даже на старых машинах. Оно работало быстро не потому, что было написано на таких хороших языках, а потому, что не решало тех задач, которые были нужны разработчикам. Когда стало решать, появились и тормоза.
Про полностью интегрированную среду - если бы все так было хорошо, то какой-нибудь решарпер был бы совершенно не нужен и все бы пользовались чистой студией.
я все равно не понимаю зачем в этой задаче GPUПотому что разрешение экрана 4k. Если напрямую писать во фрейм-буфер, это 1.8ГБ/c (на 60fps)
Это на порядок ниже теоретического максимума CPU memory bandwidth, но легко в это упереться, если не применять хаки по оптимизации передачи данных.
А нужно ещё делать что-то осмысленное, не просто blit, а буковки рисовать шрифтами, стили. Если буковки загрузить в текстуру, а всякие стили/фоны делать шейдерами, явно будет быстрее, т.к. GPU умеет всё это аппаратно.
Да не работали они прекрасно, чего вы придумываете. Синтаксис C++ разбирали с трудом, сложные директивы препроцессора - сразу смерть, используете темплейты - забудьте о нормальном автодополнении. Автоформатирование, рефакторинги? Не, не слышал. Фичи, которые более-менее работали в MSVS6, сейчас есть в каждом первом блокноте. А то, что умеет например, VSCode с плюсовым плагином, да с плагином для системы сборки, да с плагином для системы контроля версий, этого во времена MSVS 6 даже в розовых мечтах разразработчиков не было.
Странно, что ничего не сказано про лицензию будущего проекта.
Пара олдо-высе*ов про говняшность "этого вашего жээса" и про "ваком-си-под-досом-для-всех" и про то как страшно в 2021 целый гигабайт оперативы сожрать.
Инструмент должен делать свое дело! Иайнеры вот не боятся ни оперативу жрать ни ресурсы планеты на свой вакуум переводить.
Геймеров не ломает видюхи покупать по цене автомобиля а бедным нищим кодерам жалко сотку баксов на планку памяти...
Электрон это возможность школьнику, преподавателю, учёному, домохозяйке или музыканту выучить ОДИН язык и написать на нем вообще всё и от мобильника до десктопа и веба а сейчас ещё и iot (espruino).
JS это золотая середина между всяким но-код-ноде scratch и прямым управлением памятью.
Максимально от высоко-абстрактный, без табунов сферических коней паттернов и ООП.
И пока вы сообщите свои носики пузатого бородатого трушного мамкиного кодера, на всех этих "JS - макак" и формошлепов, мой знакомый дворник у себя в подсобке лепит на электроне в локалке своей поликлиники приложение для уборщиц, обнажая беспомощность и ненужность всех этих ваших мега-ВТУЗОВ и прибивая ценник разработки к плинтусу!
Ещё бы вы не пенились своими г*внами )
На счёт раста я не знаю, и мне пофиг, но непонятно почему rust-убийца node - deno, не умеет жить на arm вообще и 32 бит в частности?
Если этот "убийца" электрона тоже зазвездится своей трушностью и "скорострельностью" но забудет про дворников в поликлиниках, то пойдёт он туда же куда все эти си-билдеры со студиями.
Ну и для тех кто до сих пор никак не поймет "зачем весь этот веб-зоопаок" :
Найдите хоть что-то , хоть одну вменяемую альтернативу вебу в GUI , которая бы не выглядела как гавно мамонта и не требовала бы десятка джунов в подсобниках, респонзивилась от мобильника до десктопа и делала бы это и на макоси и на линуксах?
Так вроде никто и не спорит с тем, что в некоторых случаях (как, например, в приведенных Вами) это может быть хорошо для кодеров. Речь за user experience.
Весь софт - нет. Однако вот есть такой пример: Obsidian. Это приложение не идеально, но оно реализует очень интересные идеи, и при этом реализует (а) в браузере, (б) в кроссплатформенном десктопном приложении, (в) в мобильном приложении под Андроид и айОС. Насколько я знаю, разработкой занимаются два (2) человека, инструменты - TypeScript/React/Electron. Скачайте, покрутите функционал, и ответьте на такой вопрос: смогут ли два человека в разумные сроки реализовать что-то подобное с помощью других инструментов? C++/Qt, C#/WPF, что там ещё из живого GUI-шного осталось, вот это всё.
Это я к тому, что JS - безусловно компромисс, но это очень удачный и эффективный компромисс.
Так вы сами же и сказали - возможность сравнительно легко делать плагины, для начала. "Просто" взять браузер и "просто" завернуть туда редактор маркдауна с возможностью расширять внешний вид и функционал плагинами, прикиньте хотя бы примерно, сколько на это усилий потребуется на любой другой платформе для GUI. Насколько я с этим делом знаком (кроме Flutter, не трогал его) - два человека в разумные сроки такое не осилят и близко. Большая команда осилит, да кто только кто денег на неё даст. Путь от идеи до MVP и далее до первых релизов в JS-экосистеме в разы, если не на порядки, короче альтернатив.
Вы упорно утверждаете, что запилить заметочник с браузером - что-то простое. Это не так. До Обсидиана было множество попыток реализовать методику Zettelkasten, ни одна из них не взлетела настолько хорошо, насколько мне известно. Да и если оставить Zettelkasten в покое и забыть про кроссплатформенность и плагины, оставить просто иерархический заметочник - работает оно ровнее и быстрее альтернатив, написанных такими же одиночками на Swing/WinForms/MFC/whatever.
С другой стороны, есть, например, Telegram, у которого вполне нативные клиенты для разных платформ, включая веб.
P.S. сам пользуюсь Obsidian, VS Code, Discord, но на этом список хороших (на мой взгляд) Electron-приложений и заканчивается.
С Телеграмом сравнение некорректно, у него помимо нативных клиентов есть бэкер-миллиардер, может позволить себе.
Пример Обсидиана показывает, что эта экосистема даёт возможность быстой разработки достаточно продвинутых в GUI-плане приложений очень малыми усилиями, воплощая в жизнь какие-то интересные идеи, которые в ином случае остались бы либо долгостроем, либо нереализованными вовсе. (Я имею ввиду не Electron конкретно, а скорее всю JS-экосистему, т.к. Electron по большому счёту лишь ещё один рантайм для неё.)
Именно поэтому Гугл, Инста и т.д. в самом начале строчили на Пайтоне.
После некоторые стали придумывать свой язык, другие - модифицировать существующий под свои нужды (FB).
Однако вот есть такой пример: Obsidian. Это приложение не идеально, но оно реализует очень интересные идеи
Кроме "модного" интерфейса в нем ничего интересного нету, а по возможностям оно и 10% не дотягивает до Емаксовского org/org-roam mode
Геймеров не ломает видюхи покупать по цене автомобиля а бедным нищим кодерам жалко сотку баксов на планку памяти...
Ну раз вы богатый и вам не жалко — зашлите эту сотку баксов мне, буду благодарен.
Найдите хоть что-то , хоть одну вменяемую альтернативу вебу в GUI , которая бы не выглядела как гавно мамонта и не требовала бы десятка джунов в подсобниках, респонзивилась от мобильника до десктопа и делала бы это и на макоси и на линуксах?
можно подумать, у веба здесь всё прекрасно...
Типичный формошлёп.
Этим, в принципе, все сказано.
Странно, мне казалось, что между си и nocode не только js, но и множество других языков, популярных и нет, разной степени абстрактности: C#, Java, Kotlin, Go, Rust, D, Dart, Lua... Не JS единым. Тот же C#/Kotlin не сказать бы, что как-то сильно сложнее JS.
Найдите хоть что-то , хоть одну вменяемую альтернативу вебу в GUI , которая бы не выглядела как гавно мамонта и не требовала бы десятка джунов в подсобниках, респонзивилась от мобильника до десктопа и делала бы это и на макоси и на линуксах?
Посмотри что такое FireMonkey (FMX). Работает на всех платформах. Винда, линукс, макось, иос, андроид и даже распбери. Работает и на арм и на новой M1. Работает с GPU отрисовкой (DirectX или OpenGL, зависит от платформы). Позволяет использовать шейдеры хоть для чего и позволяет пометстить любой контрол в любой контрол (как любит это хтмл).
При этом имеет дизайнер дизайна. Т.е. дизайнить шаблоны для дизайна визуально. В добавок позволяет переключить контрол в нативную отрисовку. Т.е. поле ввода будет полем ввода из платформы и т.д. Добавим к этому визуальную настройку анимации и трансфрмации. И это мы даже не приступали к коду, который позволяет ещё кучу всего настроить для дизайна. Можем так же размещать 3D объекты и, можем убрать фон окна для отрисовки всего этого на рабочем столе с альфаканалом (примеры:
https://youtu.be/U802Uik8IzM,
https://youtu.be/GspC-fhOZLY,
https://youtu.be/umgA8fjy4pI,
https://youtu.be/Y_WHERlyahg,
https://youtu.be/r10Zf8jYpP0,
https://youtu.be/hcACtvOO-Ec).
Ну и красивости. Я выполнял любые макеты в фигме от дизайнеров в этом фреймворке, как бы они не извращались. Думаю в примерах это будет видно.
Всё это я к тому, что веб и css в частности далеко не уникальное явление в дизайне. Сейчас очень много GUI фреймворков, позволяющих делать красивый интерфейс.
Например? Я, к сожалению, не сталкивался с такими требованиями.
Screen Reader-ы для слепых, я думаю.
А они есть, причем всегда. :) И веб, как по мне, наиболее стандартизован и предсказуем в этом плане. Для того, чтобы веб приложение сделать неюзабельным для скринридеров, нужно приложить немалые усилия. И то останется шанс хоть как-то это обойти. А нативные платформы могут просто не иметь должную поддержку accessibility. Ведь обычно "в требованиях это явно не прописано".
Как правило, вне веба это зависит от платформы. Тот же андроид именно для этого отдельный фреймворк. Через fmx его можно использовать без проблем. Можно импортировать классы java напрямую. Так же и в винде. Доступ к данным окна можно обеспечить без проблем. Например, дня озвучки текста.
Так же и в винде. Доступ к данным окна можно обеспечить без проблем.
Со стороны разработчика?
К сожалению, это не мешает многие годы официальным клиентам viber и telegram быть полностью недоступными на винде. Да и по smartgit я писал разработчикам по этому поводу. Они причем даже пытались что-то сделать, но решения так и не нашли. На андроиде тоже подобных примеров достаточно. Но там скорее халатность вроде неподписанных кнопок и недоступных элементов управления.
Не знаю как по поводу крупного шрифта, но озвучку всех элементов сделать не трудно. Например, можно обратить внимание на хинты. И при генерации вызывать нативного озвутчика. Событие имеется. А хинты вообще всегда рекомендуются. Так что проблем с этим не вижу.
Ну а в вебе придётся каждый раз что-то особенное использовать.
при генерации вызывать нативного озвутчика.
Вообще озвучиванием элементов занимается скринридер. Задача программы — обеспечить навигацию с помощью клавиатуры и дать информацию для скринридера об элементах интерфейса. В вебе с этим все очень неплохо. Т.к. платформа давняя и устоявшаяся, и производители браузеров провели много работы над доступностью. А вот остальные платформы, по моим ощущениям, каждый раз должны обеспечивать свою доступность с нуля. Пусть и с использованием средств ос. Поэтому она и варьируется от полного нуля до вполне приличной. Но так как эти вопросы у компаний стоят не на первом месте, отношение у меня к ним подозрительное.
Еще из последнего перевод JetBrains toolbox с web view на собственный Compose Multiplatform. Ребята хвастаются уменьшением размера приложения, увеличением отзывчивости, но accessibility пропало совсем. Обещают в перспективе поправить, но когда конкретно — неизвестно. Но им хотя бы верить можно, ведь их IDE по результатам сознательно проведенной работы вполне доступны. А пока можно сидеть на старой неэффективной версии.
Причем, что симптоматично, Compose Multiplatform недавно перешел в production ready 1.0 версию. Но accessibility там все еще нет.
эммм. этот zed какое-то унылое говно, походу. ничего толком нету, из того, чем я бы пользовался. пока останусь на vi/vim как вездеходе, и spacemacs для локального редактирования. ничего лучше пока не видел.
Специально создали коллизию имен с zed из zsh (встроенный редактор zsh)?
Пока выглядит как ненужно. Похоже что закрытый код, попытка сделать комбайн, NIH во все поля, и непонимание, что помимо проблемы скорости рендера основной проблемой у них является догнать по фичам хоть кого-то из лидеров (редакторов или IDE, смотря с кем они собрались соревноваться).
Видимо вдохновлялись трупом xi-editor xi-editor, лучше бы коммитили в него.
С их сайта:
The key insight was that modern graphics hardware can render complex 3D graphics at high frame rates, so why not use it to render relatively simple 2D user interfaces with an immediate mode architecture?
Immediate mode это способ отрисовки GUI, при котором при любом изменении пересоздаётся целиком вся иерархия компонентов. При работе с большим количеством кода, при большом количестве элементов на экране, это всё будет тормозить. Можно расходиться, товарищи.
Проблема не с самой отрисовкой, а с компоновкой и перекомпоновкой когда что-то удаляется из DOM, или что-то вставляется.
- современные видеокарты архитектурно заточены под рендеринг миллионов треугольников;
- растеризация векторного текста, а в особенности юникода — вещь далеко не самая тривиальная и быстрая (емодзи, лигатуры и прочая порнография, без которой в 2022 выпускать редактор текста как-то моветон).
В совокупности это обозначает, что львиную долю работы — растеризацию глифов и построение layout'а текста выполняет исключительно CPU, на GPU тут разве что финальный рендеринг получится отгрузить, и это отработает быстро, да.
Text Rendering Hates You
Кто мешает все буквы нужного размера шрифта заранее нарисовать в текстуру, а дальше только ренедерить куски текстуры в нужные места? Или даже не буквы, а глифы со всеми возможными наклонами и деформациями, которые могут встретится в шрифте. Опять же, антиальясинг, отмеченный в вашей статье, тут из коробки.
Построение layout-а копейки, просто из-за объёмов данных. Тут надо 40-60 КБ прошерстить, это в кеш CPU влезет, это не десятки мегабайт графики.
Не просто треугольников, а затекстуренных и с прозрачностью. Прямоугольник под букву можно сложить из двух треугольников.
Буква — это не прямоугольник. В этом и суть, что GPU очень хорошо умеет делать вещи, под которые он заточен, например, под вывод треугольников. Рендеринг шрифтов к таким вещам не относится (хотя у Mali вроде есть набор OpenGL-расширений для текста, так что там, возможно, ситуация получше).
Кто мешает все буквы нужного размера шрифта заранее нарисовать в текстуру, а дальше только ренедерить куски текстуры в нужные места?
Никто, так и поступают. Но если вы прочитаете соответствующий раздел в статье, то узнаете, что это не универсальное решение, и у него есть свои проблемы.
Или даже не буквы, а глифы со всеми возможными наклонами и деформациями, которые могут встретится в шрифте.
Если приложение будет кешировать абсолютно все глифы во всех возможных размерах и начертаниях — оно память будет жрать половниками, особенно на ретине. Про это тоже в статье есть: если дать пользователю использовать очень большие шрифты, то память кончится.
Построение layout-а копейки, просто из-за объёмов данных. Тут надо 40-60 КБ прошерстить, это в кеш CPU влезет, это не десятки мегабайт графики.
Во-первых, откуда такая оценка? Во-вторых, вы же понимаете, что сложная логика даже на 40-60Кб может занять непристойно много времени? А у вас нет много времени, вам нужно все UI-операции уложить в 16мс.
Я конечно не исключаю, что вы правы. Но, с одной стороны, есть ваши слова о том, как все просто, с другой — есть объективная реальность, в которой куча разработчиков тратят кучу времени на движки рендеринга текста, с третьей — пользователи на том же хабре, которые регулярно жалуются, что шрифты мыльные. И это в целом намекает, что проблема несколько глубже, чем просто свалить в GPU текст и сказать «рендери!»
Прямоугольник под букву можно сложить из двух треугольников.
Можно и одним обойтись.
Atom не умеет писать файлы атомарно, возможна потеря данных.
https://github.com/atom/atom/issues/11406
Судя по исходникам VSCode у него должна быть такая же проблема, но на последний жалются меньше.
Разработка на С / C++ заняла бы слишком много времени и скорее всего закончилась бы неудачей проекта
Ага, а на Rust она типа уже закончилась, и удачно. Да и вообще, с чего они взяли что на Rust что-то напишется быстрее? Rust безопаснее плюсов, это да. Но не проще, и писать на нём не быстрее.
Rust безопаснее плюсов - а значит меньше времени уйдет на отладку. Поэтому и быстрее будет.
Да не только по этому.
Потому что у раста есть взрослая экосистема, а у плюсов нет ничего.
Если цель — быстро написать условную Windows 98, то есть что-то падучее, неподдерживаемое уже через несколько лет, с неверной внутренней архитектурой и слабой поддержкой многопоточности/асинхронности, под одну платформу и без внешних библиотек, но работающее реально быстро, то скорость разработки на плюсах и расте будет сравнима.
Стоит убрать из этого условия хоть что-нибудь, и внезапно оказывается, что приходится обмазываться санитайзерами, анализаторами, valgrind, делать отдельные сборки со всем этим включенным, писать тесты для абсолютно всех сценариев, обязательно прогонять фаззинг, делать отдельные релизные сборки, где все это выключено, делать джобы, которые проверяют что нужные флаги сборки РЕАЛЬНО прокидываются (ведь мы не доверяем никаким инструментам на С++), делать тесты, которые бы сравнивали поведение обеих сборок. Если что-то надо собирать под несколько платформ, то писать мозговыносящие скрипты для симейка, а потом — и вовсе надстройку над симейком. Где-то в перерыве тратить недели на поиск подходящей библиотеки, которая бы делала то что нам нужно нормально (потому что их ровно десять, но понять какая из них стоящая невозможно, пока лично не потестируешь). Ой, мы хотим стороннюю библиотеку... но она собирается тулой XYZ, которая у нас не работает. Придется выбрать другую, которая симейком собирается.
И это мы еще не дошли до самого написания самой программы!
И с чего же они взяли что на Rust что-то напишется быстрее?! Удивительно конечно, ведь все так просто, нужно просто приложить старый советский...
Обожемой, у раста нет ничего из вышеописанного просто потому, что у раста пока ещё вообще нет ничего, кроме больших перспектив. Как только на нём начнут реально писать, вот прям в продакшене, вот прям живые люди - внезапно понадобится вот это всё, поскольку языковые преимущества закроют 1% потребностей, а всё остальное как было нужно, так и будет дальше.
На Rust прям реально пишут прям живые люди в CloudFlare, Amazon, Dropbox и ещё куче других компаний. Отзывы в основном положительные.
А мужики-то и не знают https://stratis-storage.github.io/
На хабре в последнее время стало модно прям демонизировать C++. Почитаешь, так складывается ощущение, что любой хеллоу ворлд содержит сотни UB, которые компилятор трактует самым ужасным способом.
Да, C++ сложен, но чаще всего не настолько, как описывают.
Потому что у раста есть взрослая экосистема, а у плюсов нет ничего.
По ощущениям наоборот. Для плюсов можно найти почти что угодно, а вот для раста нужного часто нет, а то что есть по ощущениям сделано на половину.
Например: для линала в плюсах я использую Eigen причем с кастомным BLAS-бекендом (на маках это Accelerate, если что) и ничего подобного для раста я не нашел. Есть nalgebra, но нельзя сторонний бекенд подключить, только их самостийная реализация. Есть rust-blas, который есть обертка над произвольным BLAS-ом, но это именно обертка -- надо самому настраивать данные и дергать низкоуровневые функции.
Особенно на отладку логики.
Меньше времени уйдет - не значит, что отлаживать совсем не придется.
И одно дело отлаживать логику, имеющую детерминированный характер, а другое - утечки памяти, выходы за границы массива и те же гонки (при чтении/записи из разных потоков), которые имеют плавающий характер. И Rust как раз эти плавающие проблемы старается закрыть своей моделью памяти.
Так что - да, на Rust быстрее будет разработка. А главное - надежнее.
Речь шла об Atom:
Our first attempt was Atom, which we loved like a child but which ultimately fell short of our original vision. When we created Electron in 2012 to serve as Atom's runtime, there weren't a lot of great options for building cross-platform desktop apps.
Had we tried to write Atom in C or C++, it never would have shipped, and we loved the idea of developers extending their editor with the familiar tools of JavaScript, HTML, and CSS.
Но не проще, и писать на нём не быстрее.
И проще, и быстрее. Хотя бы потому что выучить Rust реально, а выучить C++ — нет.
Кликбейтненый заголовок.
Вообще в такой статье хотелось бы как раз видеть ссылки на мнения разработчиков.
Но в сути, сидели 4 разработчика, писали новый редактор типа Атома и решили, что веб, как рендер движок не заходит им, почему бы и нет, веб не для всего подходит. И действительно может быть бутылочным горлышком, особенно, если View очень сильно отличается по целям от браузерного.
we decided to take full control and simply build a GPU-powered UI framework
Решили не городить огородов и просто сделать для себя GPU фреймворк.
Причем тут Electron? Во всяком случае, в глобальном смысле?
Могли сделать хоть на Unreal Engine, с встроенным индикатором здоровья разработчика.
Ни для кого не новость, что Electron не подходит под все задачи, и что JS однопоточен
что-то мне кажется, что боязнь работы с С\С++ немного связана с незнанием новых стандартов и все-таки недостачной квалификацией, для очередного убийцы С++ у него (Rust) немного медленный рост реальных проектов
Borrow checker - это не только про управление памятью, но и про потокобезопасность.
https://habr.com/ru/company/otus/blog/578138/
На safe Rust нельзя вызвать гонку. Вроде как.
Если же есть возможность поднять GC, то вместо возни с borrow checker программисты предпочитают юзать Go
И затем все равно переписывают на раст, когда нужна производительность:
Отсюда можно перейти на страницы с такими историями https://serokell.io/blog/rust-companies
то вместо возни с borrow checker
Если програмист относится к borrow checker как к чему-то с чем нуждно возится, то у него просто низкий уровень. Borrow checker не мешает, а помогает. Rust не приносит ничего нового в правила написания корректных программ, он просто делает их строгими.
Проблема не в том, что borrow checker мешает, проблема в том что слишком долго нормой были языки, которые позволяют написать и скомпилировать очевидно некорректный код.
Авторы Electron признали его неудачным, написали новый фреймворк на Rust и представили новый редактор Zed