Три бывших разработчика (Nathan Sobo, Antonio Scandurra и Max Brunsfeld) редактора Atom и Nate Butler из Facebook вчера представили свой новый редактор Zed над которым они работали последние несколько лет.
Основными идеями для редактора нового поколения они считают:
- Максимально возможная скорость работы
- Совместная работа в реальном времени
- Средство текстовой коммуникации, встроенное в редактор
- Эффективность разработчика за счет максимально полезного UI
Изначально разработчики попробовали написать ядро редактора на Rust и оставить Electron в качестве фронтенда. Этот проект назывался Xray, но GitHub отказались продолжать развитие проекта. Со временем, они поняли, что именно Electron является узким местом для достижения желаемой производительности и решили написать свой графический фреймворк, использующий GPU для рендеринга.
Он называется GPUI и, по словам авторов, вдохновлен проектом Mozilla Webrender.
Electron был создан в 2012 во время написания Atom и, для того времени, авторы считают это правильным выбором, так как их целью было создать кросс-платформенный редактор. К сожалению, ничего более подходящего, чем веб-технологии тогда не было. Разработка на С / C++ заняла бы слишком много времени и скорее всего закончилась бы неудачей проекта, к тому же, хотелось, что бы сторонние разработчики могли расширять редактор с помощью знакомых для многих JavaScript, HTML, и CSS.
Использование Rust позволило небольшой команде разработать продукт в срок, и они считают, что Zed не удалось бы создать с помощью других инструментов.
Редактор будет поддерживать Language Server Protocol, но также иметь мощную встроенную поддержку более 50 языков на основе Tree-Sitter (используется GitHub).
Проект находится в стадии бета-тестирования, записаться можно по ссылке.
Примечание:
Авторы считают именно Electron (а не Atom) неудачной технологией, причем именно в данный момент времени. В ретроспективе наоборот — именно благодаря ему им удалось создать Atom и достичь успеха.
In the end, however, we reached the conclusion that the editor we wanted to use couldn't be built in a single-threaded scripting language. It was time to start over. Now we're back from the wilderness, this time with the knowledge and tools we need to execute without compromise.
Atom — бесплатный текстовый редактор для Linux, macOS, Windows с поддержкой плагинов, написанных на JavaScript, и встраиваемых под управлением Git. Atom основан на Electron.
Electron (ранее известен как atom shell) — фреймворк, разработанный GitHub. Позволяет разрабатывать нативные графические приложения для операционных систем с помощью веб-технологий, комбинируя возможности Node.js для работы с back-end и библиотеки веб-рендеринга Chromium. Был разработан в 2012 для создания редактора Atom.
Rust — мультипарадигмальный компилируемый язык программирования общего назначения. Ключевые приоритеты языка: безопасность, скорость и параллелизм.
Комментарии (245)
Tanner
16.12.2021 03:45+30А вы заметили, как любое описание софта без ссылки на исходники воспринимается как скам?
zorn-v
16.12.2021 04:42+35Электрон это не редактор. Редактор - это atom. Электрон делался для него и изначально назывался atom-shell. Когда поняли что получилось нечто большее, оформили и назвали электрон (атом состоит из электронов).
shnegs
16.12.2021 09:00+39атом состоит из электронов
Вот с этим то знанием они его и написали, электрон этот Ваш:)
zorn-v
18.12.2021 12:26Ну электрон модно хаить, а по факту ?
Те люди которые пишут гавно на электроне, напишут что то стоящее на с++ ? Вы реально в это верите ?
quwy
18.12.2021 15:45-1Те люди которые пишут гавно на электроне, напишут что то стоящее на с++ ?
Те люди, которые пишут говно на электроне, на c++ вообще ничего не напишут, и пойдут заниматься чисткой сараев, прямым своим делом.
qw1
18.12.2021 19:17А приложения кто писать будет? Плюсовиков на все поделия не хватит, да и не интересно им такое, рисовать рюшечки и выравнивать по пикселям, чтобы стильно смотрелось.
HemulGM
18.12.2021 20:27+1Так это не зависит от инструмента. Дизайнеры делают макет, разработчики просто его исполняют.
quwy
19.12.2021 02:34А других нормальных инструментов кроме плюсов нет?
Даже многими порицаемая на десктопе Java в тысячу раз лучше этого электрона поганого.
trokhymchuk
16.12.2021 09:07+13атом состоит из электронов
Не то чтобы электронов там не было, но мне кажется, вы что-то упускаете. ;)
ksbes
16.12.2021 10:20+14atom shell (атомная оболочка) состоит из электронов - так что всё правильно.
Oxyd
16.12.2021 05:10+6Да неужели-ж молитвы были услышаны?... Хотя вряд-ли тонны софта будут переписаны под новый фреймворк. :-(
GeneAYak
16.12.2021 11:10+2да со временем понапишут новых хипстерных аналогов, некоторые приживутся, но времени понадобится, конечно, много
IvaYan
16.12.2021 14:13Тут еще нужно чтобы новый фреймворк оказался столько же удобным для разработки (сам я под электрон не пишу, поэтому продаю за что купил). Один из факторов успеха электрона в том, что там можно писать на JS-е, знатоков которого полно. При этом зная веб-стек в лице HTML, CSS + JS стало возможным получить настольное приложение почти любому желающему (опять же, качество этих приложений оценивать не хочу сейчас).
И вот теперь у нас есть фреймворк на Rust (фреймворк ли? я пока понял, что там редактор). Каким будет порог входа в него для не-растоводов?
alexeishch
16.12.2021 14:53+1>можно писать на JS-е, знатоков которого полно
Вот тут я прям в голос засмеялся
kira-dev
16.12.2021 21:44Я не переживу еще один электрон-комбайн в довесок к пятаку электрон-прилаг на своем ноуте
Mingun
16.12.2021 07:31+20Средство текстовой коммуникации, встроенное в редактор
Вот что-то уже начинает напрягать. Просто сделайте нормальный не тормозящий редактор. С нормальным фолдингом на основе лексера, а не регулярок (поголовно все редакторы не могут нормально свернуть XML в котором есть куски многострочного текста, так как реализуют фолдинг на основе отступов, а не структуры документа). Встраивать всякие свистелки для полутора человек не надо
iliazeus
16.12.2021 09:13+4В Language Server Protocol есть folding ranges, поэтому почти любая современная ide должна, в теории, это уметь с плагинами. Попробуйте, например, VSCode вместе с https://marketplace.visualstudio.com/items?itemName=redhat.vscode-xml
shoco
16.12.2021 10:32+2Зато фолдинг на основе отступов позволяет получить эту функцию из коробки для практически любого блочного языка программирования. И не нужно ставить плагины и lsp (которых у малоизвестных языков может вообще не быть)
Mingun
16.12.2021 11:47+1Проблема в том, что раскраска тоже требует лексера и она-то работает правильно!
Gordon01 Автор
16.12.2021 10:47-2Очень полезная и нужная фича.
Какие сейчас варианты? Кидаться исходниками через мессенджеры? Делать коммиты на каждое изменение, если нельзя вставить исходник в мессенджеры?
Шарить экран? А если интернет плохой, надо вдвоем редактировать, а коллега вообще не может голосом разговаривать?
Единственное, чем не отвратительно пользоваться сейчас — это геррит, но это инструмент для ревью.
Mingun
16.12.2021 11:51+5Вариант — сделать это плагином, а не встраивать. Потому что встроенное все равно будет хуже, чем специализированное решение и поддерживаться через пень-колоду. От быстрого текстового редактора все же ожидаешь в первую очередь редактирование текста, а не чат
AlexSelivanoff
17.12.2021 07:09+1Да што уж там, Zoom сразу встроить можно. Абсолютно непонятно, зачем это нужно в редакторе. Я был очень удивлен, когда нашел для VSCode дополнение Stories
goldrobot
17.12.2021 16:19А я вот не соглашусь.
Нормальных не тормозящих редакторов вагон и тележка. Да тот же neovim вас удовлетворит.
Зато нормальных не тормозящих IDE нету. Потому хороший функционал в ядре программы очень даже нужен.
Oblitus
16.12.2021 08:06использующий GPU для рендеринга
Дайте угадаю, если запустить параллельно еще какую-то софтину использующую гпу дико тормозит? Почему-то даже при небольшой загрузке гпу очень хреново справляется с мультизадачностью.
GamePad64
16.12.2021 13:13+2Так сейчас даже композитинг выполняется с участием GPU. Получается, любое приложение, запущенное не на весь экран, должно тормозить.
QuAzI
16.12.2021 08:34+19и они считают, что Zed не удалось бы создать с помощью других инструментов
Громкое заявление. Но ничего ж нет. Софта нет, репозитория нет, LSP, не говоря о более навороченных штуках лишь только "будет". Tree-Sitter на треть состоит совсем не из раста.
Как выше отмечали, электрон и не редактор. Atom редактор. VSCode редактор. До последнего, с контейнерами, удалённой работой по SSH, Live Share и прочим вагоном кастомизаций этим прогрессивным штукам догонять и догонять и ещё большой вопрос, какой перфоманс на метр багов будет при сопоставимом функционале.
Новость максимально кликбейтная.
k102
16.12.2021 10:56А надо догонять? Я не пользуюсь и половиной из фич vscode, не говоря уже о монстрах типа webstorm. Если они сделают что-то типа атома, но быстрее - отлично, дайте два.
QuAzI
16.12.2021 11:57+3VSCode достаточно быстр даже на ужасающе древних штуках типа Np-nc110p, которые хочется выкинуть в окно ещё до того как оно забутается. Если нужно прям ещё быстрее, есть vim. Который по фичам тоже пока впереди. Ну а так, если вам нужен просто блокнот, то спор ни о чём.
k102
16.12.2021 14:20-2Дело не в быстроте, а в минимализме. Не люблю использовать адовые комбайны когда могу не.
QuAzI
16.12.2021 15:43+2Не используйте. Достаточно просто не ставить дополнения. Ну и Zen mode + Vim-like navigation в помощь. Более лаконичных адекватных именно IDE не заточенных под "подрыгать только вот этой лампочкой" вам не найти. Но можно лепить монстров из sublime/npp и пытаться выдать тёплое за мягкое
NeoCode
16.12.2021 08:47+21Много лет назад была такая Visual Studio 6, написанная на С/C++ Winapi/MFC. Или ранние версии С++Builder. Прекрасно работали даже на старых машинах (без всяких GPU). А на новых просто летали. Но кому-то понадобилось писать IDE на C#, на Java, на JS... Ну хорошо что одумались и вернулись на язык системного уровня (хотя я все равно не понимаю зачем в этой задаче GPU).
Основная задача IDE - интегрированность, главным образом компилятора и отладчика. Многие "текстовые редакторы для программистов" имеют быстрый интерфейс, но средства разработки к ним прикручены сбоку (или, что еще чаще, их нужно прикручивать вручную). Хуже всего с отладкой - ее как правило нигде в нормальном виде нет.
trokhymchuk
16.12.2021 09:12+6Прекрасно работали даже на старых машинах (без всяких GPU). А на новых просто летали. Но кому-то понадобилось писать IDE на C#, на Java, на JS...
Повышение уровня абстракции всегда чего-то стоит. Сделав редактор на жс, к примеру, пострадала скорость работы и потребление памяти стало больше, но разработчики смогли реализовать больше фич.
Что я хочу сказать, что не только плохое приходит с использование более ввсокоуровнего языка.
iliazeus
16.12.2021 09:22+4Сделав редактор на жс, к примеру, пострадала скорость работы и потребление памяти стало больше, но разработчики смогли реализовать больше фич.
Я не думаю, что это так. VSCode и Atom, оба хоть сколько-то популярных Electron-редактора, скомпилированы в js скорее потому, что оба выросли из проектов браузерных редакторов/ide, и во многом ими и остаются (GitHub Codespaces это VSCode, к примеру). В браузере выбор языков и технологий намного меньше, по крайней мере, до широкого распространения тулинга и библиотек для wasm.
Gordon01 Автор
16.12.2021 13:13+3Они не выросли из браузерных редакторов. Наоборот, до браузера они доросли только спустя несколько лет.
Electron был выбран как единственный инструмент, на котором можно было создать кросс-платформенное графическое приложение в приемлимые для ребят сроки.
Какую альтернативу вы предложили бы им в 2012 году? wxWidgets?
Можно сколько угодно болтать о том, что на библиотеке Х из экосистемы С/С++ можно сделать все то же самое, но "нативно" и используя 10 МБ оперативки, но за десять лет эти разговоры так и никуда не переросли, "убийцы" электрона на с/с++ так и не появилось. Как и не появилось возможности использовать асинхронщину и многопоточность в с/с++, так же удобно, как это происходит в современных языках.
iliazeus
16.12.2021 13:35+6Они не выросли из браузерных редакторов. Наоборот, до браузера они доросли только спустя несколько лет.
Atom начинался с Ace, собранного в standalone-приложение. VSCode начинался с Monaco, который пилили для всяческих нужд Azure. Да и Visual Studio Online был там с самого начала.
Electron был выбран как единственный инструмент, на котором можно было создать кросс-платформенное графическое приложение в приемлимые для ребят сроки.
Ага, особенно учитывая, что для Atom этот Electron еще надо было сначала написать. Да и виджетов в нем никаких нет, ребята свои UI-фреймворки писали, фактически.
Какую альтернативу вы предложили бы им в 2012 году? wxWidgets?
Из того, что знаю, вполне неплохо чувствовали себя IDE на Java.
Gordon01 Автор
16.12.2021 14:00+4Из того, что знаю, вполне неплохо чувствовали себя IDE на Java.
Эклипс? Ничего хуже для редактирования текста человечество не придумало. Когда я пробовал ей последний раз пользоваться, она просто валилась от любого взмаха ресницами. Не понимаю, каким чудом мне удалось тогда в этом написать что-то под Android...
iliazeus
16.12.2021 14:02Википедия говорит, что IDEA началась еще в 2001 году. Но, опять-таки, я слишком плохо знаю тогдашний мир IDE.
BioHazzardt
16.12.2021 16:53Из того, что знаю, вполне неплохо чувствовали себя IDE на Java.
У меня есть старенький ноутбук, с которого иногда приходилось вносить правки в код. Так вот — на vscode я их вносил за то же самое время, за которое IDEA только запускалась
zaiats_2k
16.12.2021 18:47-2Давно мучает вопрос, почему каждый второй айтишник правит код со стареньких ноутбуков?Причём не изредка, когда снежный буран в степи застанет, а много и регулярно, так что не лень сборки редакторов с плугинами для этого подерживать.
BioHazzardt
16.12.2021 18:53ну у меня основная рабочая машина — это стационарная пекарня, а ее с собой не потаскаешь, еще есть старенький мак и тот самый ноут (новый не покупаю, т.к. пользуюсь даст бог если раз в полгода). Так уж получилось, что мака под рукой не было. Кстати если говорить про IDE на жабе, идея вполне себе хорошая штука, на какой-нибудь eclipse или netbeans вообще без слез не взглянешь
ALiEN175
17.12.2021 01:11+3Это хорошая практика. Прежде чем кидать код в продакшен, возьми и запусти сначала на два ядра/два гига (хотя бы). Может тогда поменьше было бы монструозных поделий программ и веб-страниц, сразу отжирающих половину ресурсов 4-х ядерной машины с 8 гб памяти. Про занимаемое на диске место скромно промолчу, там вообще ад какой-то творится.
IvaYan
16.12.2021 14:17+2Какую альтернативу вы предложили бы им в 2012 году? wxWidgets?
Sublime Text появился в 2008, изначально C++ и Python.
Gordon01 Автор
16.12.2021 14:28+5В 2008 он был хорош, но потом стал очередным "продвинутым блокнотом" вплоть до 2020.
Sublime Text появился в 2008
Только под Windows.
К тому времени, как они допилили кросс-платформенность, уже появился Atom.
Затем, понадобилось еще 7 лет, чтобы допилить это до функционала вскода образца 2015 года.
В принципе, это все что нужно знать о скорости кросс-платформенной разработки графических приложений на С++.
HemulGM
18.12.2021 15:24В итоге мы получаем засахаренный язык, кторый без него уже не используется. Такими темпами, скоро складывать числа в js нужно будет через сахарный метод sum(a, b)
Gordon01 Автор
16.12.2021 09:42+9Только вот студия не кросс-платформенная и написана огромной командой, у которой есть ресурсы, чтобы обмазаться санитайзерами, анализаторами и прочим. Но она все равно падает, а интерфейс может замереть при длительной операции из-за того что написать многопоточное приложение на c/c++ все равно невероятно сложно.
Последняя студия без плагинов открывает хеллоу-ворлд на моём 12-ядерном компьютере с 32 ГБ оперативки и nvme около 15 секунд. VSCode делает это за 2-3.
Студия есть под мак, но фронт там переписан с нуля. Версии для линукс нет.
vdudouyt
16.12.2021 10:27-6Даже странно слышать такое про студию - мой знакомый майкрософт-бой говорил, что там только пони по радуге бегають да бабочки летают, и ни про что подобное не упоминал))
Starl1ght
16.12.2021 22:50+2Даже странно слышать такое про студию
Так потому-что это вранье. Вижуал студия за 15 секунд вполне грузит себе Unreal Engine 4.
А вот зачем врать "КАКОЙ МИКРАСОФТ ПЛОХОЙ" - это я уже не знаю. Может ты знаешь? :)
impwx
16.12.2021 11:02+9написана огромной командой, у которой есть ресурсы
Вы прямо досконально знаете, какие у нее ресурсы и какой объем функционала нужно поддерживать, или это диванная аналитика?
Последняя студия без плагинов открывает хеллоу-ворлд
Какую вы считаете последней? У меня аналогичная конфигурация — "голая" VS2022 открывает проект с 20K+ SLOC за 3-5 секунд, заметно быстрее чем 2019. С R# — да, получается ближе к 15 секундам, но лично в моем понимании он того стоит.
Сравнивать с VSCode не совсем корректно, т.к. они в разных весовых категориях — как Paint.NET и Photoshop. К счастью, ими можно пользоваться параллельно, выбирая каждую для подходящих задач.
Gordon01 Автор
16.12.2021 11:53-7Сравнивать с VSCode не совсем корректно
Действительно, вскод — кросс-платформенный, а студия — нет.
т.к. они в разных весовых категориях — как Paint.NET и Photoshop
Абсолютно верно. Что студия, что фотошоп — тормозные, падучие и однопоточные монстры. VSCode заменил студию у массового программиста, Affinity Designer заменил фотошоп у массового дизайнера.
impwx
16.12.2021 12:21+13Ну вот опять — вы собственный опыт обобщаете на всех.
Кто такой "массовый программист"? Веб-разработчик? Большинство веб-ориентированных языков динамически (или частично) типизированные, поэтому для разработки на них возможностей VSCode действительно хватает.
На противоположном конце спектра находится энтерпрайз — банки, предприятия, биржи и тому подобное. Там тоже приличное количество программистов работает. Вы знаете истории, где "vscode заменил студию" в контексте реально крупного энтерпрайзного проекта на Java, .NET, C++? Я не знаю, но с удовольствием послушаю.
Gordon01 Автор
16.12.2021 14:31Работаю в крупном российском кровавом энтерпрайзе (не банке и не бирже).
Основной редактор по результатам опроса — VSCode, разработка на С/С++.
Получается, вы собственный опыт обобщаете на всех?
impwx
16.12.2021 14:39+1Ну опять — вы опросили ваших непосредственных коллег в одной конкретной компании. Из этой "статистики" никакой вывод сделать нельзя, но было бы интересно почитать статью с опытом и конкретными числами: какой размер проекта, сколько разработчиков, в какой момент и почему перешли и т.д. — иначе это спор о "настоящем шотландце".
Carburn
16.12.2021 13:53при чем тут C++? VS написана на C#.
darkdaskin
16.12.2021 16:51+1Изначально на C++, и только начиная с VS 2012 отдельные части (в основном UI) начали переписывать на C#. Лишь к VS 2022 смогли выпустить 64-битную версию, потому что устаревший плюсовый код не позволял сделать это ранее, хотя потребность была уже давно (приходилось выносить куски кода в отдельные процессы, чтобы уложиться в 32-битное адресное пространство).
Carburn
16.12.2021 19:17-1так сейчас не осталось кода c++?
darkdaskin
18.12.2021 04:07Остался, как минимум ядро IDE, отладчик и подсистемы для старых типов проектов. Тем не менее, если 10 лет назад написание расширений к IDE представляло из себя пляски вокруг COM, сейчас всё больше подсистем доступно из .NET напрямую, что сильно упрощает разработку. Навскидку, если посмотреть на запущенный процесс IDE, из 1000+ загруженных DLL нативных осталось порядка пары десятков (не считая входящих в состав Windows).
И да, в предыдущем комментарии я немного ошибся, переписывать начали с VS 2010.
IvaYan
16.12.2021 14:20+1Студия есть под мак, но фронт там переписан с нуля.
Строго говоря, студия под мак это вроде бывший Xamarin Studio, который к Visual Studio не имеет отношения.
slonopotamus
17.12.2021 00:05бывший Xamarin Studio
Который в свою очередь является бывшим MonoDevelop.
KReal
16.12.2021 17:06Последняя студия без плагинов открывает хеллоу-ворлд на моём 12-ядерном компьютере с 32 ГБ оперативки и nvme около 15 секунд. VSCode делает это за 2-3.
Это странно, на гораздо более слабом железе студия без плагинов открывает и индексирует hello world за те же 2-3 секунды. А без индексации (анализа исходников) открывается солюшен любого размера)
Carburn
18.12.2021 13:09Студия есть под мак, но фронт там переписан с нуля
По-моему это Sublime Text, а не Visual Studio.
joyfolk
16.12.2021 11:00+6А я вот помню, что после совершенно тупой студии и всяких билдеров с дельфами появление идеи воспринималось просто как чудо - она хоть про язык что-то понимала, что повышало продуктивность разработки в разы. И было почти плевать на ее скорость.
Static_electro
16.12.2021 12:45+2что-то вы странное помните. В билдере поддержка их диалекта была очень хороша.
joyfolk
16.12.2021 12:56+1Я помню, что когда я ими пользовался, там даже базовых рефакторингов не было. Потом, наверное, появились, но я уже свалил на java и intellij
speakingfish
17.12.2021 11:19Watcom Optima ещё была — с похожим редактором форм как C++Builder, но с большим числом компонент, фич, гораздо шустрее и компактней и конечно на базе нормального, в отличие от Borland, компилятора C++. Но не выдержала конкуренции с C++Builder.
qw1
16.12.2021 13:16+5я все равно не понимаю зачем в этой задаче GPU
Потому что разрешение экрана 4k. Если напрямую писать во фрейм-буфер, это 1.8ГБ/c (на 60fps)
Это на порядок ниже теоретического максимума CPU memory bandwidth, но легко в это упереться, если не применять хаки по оптимизации передачи данных.
А нужно ещё делать что-то осмысленное, не просто blit, а буковки рисовать шрифтами, стили. Если буковки загрузить в текстуру, а всякие стили/фоны делать шейдерами, явно будет быстрее, т.к. GPU умеет всё это аппаратно.
bzq
16.12.2021 17:57+2Это проблемы не среды разработки, а GUI. И они данным давно так или иначе решены во всех современных ОС с графическим интерфейсом. Так что я в недоумении, зачем среде разработки нужен GPU, если конечно не считать в фоне крипту.
cepera_ang
16.12.2021 17:59+4А как они решены "во всех современных ОС"? Уж не предоставлением API к видеокарте ли? :)
qw1
16.12.2021 18:12А через какое API рисовать, чтобы было переносимым и быстрым? OpenGL неплохо подходит.
avkudrin
16.12.2021 19:05+4Да не работали они прекрасно, чего вы придумываете. Синтаксис C++ разбирали с трудом, сложные директивы препроцессора - сразу смерть, используете темплейты - забудьте о нормальном автодополнении. Автоформатирование, рефакторинги? Не, не слышал. Фичи, которые более-менее работали в MSVS6, сейчас есть в каждом первом блокноте. А то, что умеет например, VSCode с плюсовым плагином, да с плагином для системы сборки, да с плагином для системы контроля версий, этого во времена MSVS 6 даже в розовых мечтах разразработчиков не было.
RiverFlow
16.12.2021 10:56-24Пара олдо-высе*ов про говняшность "этого вашего жээса" и про "ваком-си-под-досом-для-всех" и про то как страшно в 2021 целый гигабайт оперативы сожрать.
Инструмент должен делать свое дело! Иайнеры вот не боятся ни оперативу жрать ни ресурсы планеты на свой вакуум переводить.
Геймеров не ломает видюхи покупать по цене автомобиля а бедным нищим кодерам жалко сотку баксов на планку памяти...
Электрон это возможность школьнику, преподавателю, учёному, домохозяйке или музыканту выучить ОДИН язык и написать на нем вообще всё и от мобильника до десктопа и веба а сейчас ещё и iot (espruino).
JS это золотая середина между всяким но-код-ноде scratch и прямым управлением памятью.
Максимально от высоко-абстрактный, без табунов сферических коней паттернов и ООП.
И пока вы сообщите свои носики пузатого бородатого трушного мамкиного кодера, на всех этих "JS - макак" и формошлепов, мой знакомый дворник у себя в подсобке лепит на электроне в локалке своей поликлиники приложение для уборщиц, обнажая беспомощность и ненужность всех этих ваших мега-ВТУЗОВ и прибивая ценник разработки к плинтусу!
Ещё бы вы не пенились своими г*внами )
На счёт раста я не знаю, и мне пофиг, но непонятно почему rust-убийца node - deno, не умеет жить на arm вообще и 32 бит в частности?
Если этот "убийца" электрона тоже зазвездится своей трушностью и "скорострельностью" но забудет про дворников в поликлиниках, то пойдёт он туда же куда все эти си-билдеры со студиями.
Ну и для тех кто до сих пор никак не поймет "зачем весь этот веб-зоопаок" :
Найдите хоть что-то , хоть одну вменяемую альтернативу вебу в GUI , которая бы не выглядела как гавно мамонта и не требовала бы десятка джунов в подсобниках, респонзивилась от мобильника до десктопа и делала бы это и на макоси и на линуксах?
cepera_ang
16.12.2021 12:29+25Электрон это возможность школьнику, преподавателю, учёному, домохозяйке или музыканту выучить ОДИН язык и написать на нем вообще всё и от мобильника до десктопа и веба а сейчас ещё и iot (espruino).
Но нужно ли нам, чтобы весь софт был написан как будто бы школьниками, учеными и домохозяйками (одновременно)? Причём сразу под ардуино, веб и десктоп в одном пакете ))
alexdesyatnik
16.12.2021 20:08+1Весь софт - нет. Однако вот есть такой пример: Obsidian. Это приложение не идеально, но оно реализует очень интересные идеи, и при этом реализует (а) в браузере, (б) в кроссплатформенном десктопном приложении, (в) в мобильном приложении под Андроид и айОС. Насколько я знаю, разработкой занимаются два (2) человека, инструменты - TypeScript/React/Electron. Скачайте, покрутите функционал, и ответьте на такой вопрос: смогут ли два человека в разумные сроки реализовать что-то подобное с помощью других инструментов? C++/Qt, C#/WPF, что там ещё из живого GUI-шного осталось, вот это всё.
Это я к тому, что JS - безусловно компромисс, но это очень удачный и эффективный компромисс.
cepera_ang
16.12.2021 20:46Не хочется говорить ничего плохого про Обсидиан, но насчёт двух разработчиков — это очень натянуто, без пачки расширений в нём ничего интересного нет и с трудом можно найти отличия от ведения заметок в vscode. Ну то есть это круто, что можно взять браузер с завернутым туда редактором маркдауна и в две каски сделать очередной заметочник, но это всё ещё просто офлайновый браузер, который позволяет редактировать текстовые файлы.
Или может я пропустил какую-то особенную функциональность обсидиана? Что там такого уникального и сложного?
alexdesyatnik
16.12.2021 21:07+1Так вы сами же и сказали - возможность сравнительно легко делать плагины, для начала. "Просто" взять браузер и "просто" завернуть туда редактор маркдауна с возможностью расширять внешний вид и функционал плагинами, прикиньте хотя бы примерно, сколько на это усилий потребуется на любой другой платформе для GUI. Насколько я с этим делом знаком (кроме Flutter, не трогал его) - два человека в разумные сроки такое не осилят и близко. Большая команда осилит, да кто только кто денег на неё даст. Путь от идеи до MVP и далее до первых релизов в JS-экосистеме в разы, если не на порядки, короче альтернатив.
cepera_ang
16.12.2021 21:22Путь от идеи до MVP и далее до первых релизов в JS-экосистеме в разы, если не на порядки, короче альтернатив.
Я вижу проблему лишь в том, что короткий путь от нуля до MVP формирует культуру неспособную пройти длинный путь, когда это неожиданно оказывается необходимо и приложения так и остаются где-то на уровне MVP, потому что никто не думал, что запилить что-то большее, чем заметочник с браузером будет сильно сложнее и дороже, а пользователи уже привыкли, что всё бесплатно и что всё работает криво и медленно, поэтому ничего дорогого им не нужно, а без денег путь от MVP далеко не идёт.
alexdesyatnik
16.12.2021 21:51Вы упорно утверждаете, что запилить заметочник с браузером - что-то простое. Это не так. До Обсидиана было множество попыток реализовать методику Zettelkasten, ни одна из них не взлетела настолько хорошо, насколько мне известно. Да и если оставить Zettelkasten в покое и забыть про кроссплатформенность и плагины, оставить просто иерархический заметочник - работает оно ровнее и быстрее альтернатив, написанных такими же одиночками на Swing/WinForms/MFC/whatever.
DirectoriX
16.12.2021 20:51Если ваша цель делать и сайт, и приложение, которые полностью (как Discord) или частично (как Obsidian, я не припомню, чтоб там был веб-редактор, видел только возможность опубликовать хранилище на их сервере как сайт) дублируют возможности друг друга — да, в Electron есть смысл. Но как часто вам это действительно нужно?
С другой стороны, есть, например, Telegram, у которого вполне нативные клиенты для разных платформ, включая веб.
P.S. сам пользуюсь Obsidian, VS Code, Discord, но на этом список хороших (на мой взгляд) Electron-приложений и заканчивается.alexdesyatnik
16.12.2021 21:14С Телеграмом сравнение некорректно, у него помимо нативных клиентов есть бэкер-миллиардер, может позволить себе.
Пример Обсидиана показывает, что эта экосистема даёт возможность быстой разработки достаточно продвинутых в GUI-плане приложений очень малыми усилиями, воплощая в жизнь какие-то интересные идеи, которые в ином случае остались бы либо долгостроем, либо нереализованными вовсе. (Я имею ввиду не Electron конкретно, а скорее всю JS-экосистему, т.к. Electron по большому счёту лишь ещё один рантайм для неё.)
mr_bag
16.12.2021 21:02Именно поэтому Гугл, Инста и т.д. в самом начале строчили на Пайтоне.
После некоторые стали придумывать свой язык, другие - модифицировать существующий под свои нужды (FB).
vtb_k
17.12.2021 00:28Однако вот есть такой пример: Obsidian. Это приложение не идеально, но оно реализует очень интересные идеи
Кроме "модного" интерфейса в нем ничего интересного нету, а по возможностям оно и 10% не дотягивает до Емаксовского
org/org-roam mode
WraithOW
16.12.2021 12:40+8Геймеров не ломает видюхи покупать по цене автомобиля а бедным нищим кодерам жалко сотку баксов на планку памяти...
Ну раз вы богатый и вам не жалко — зашлите эту сотку баксов мне, буду благодарен.
Static_electro
16.12.2021 12:48+3Найдите хоть что-то , хоть одну вменяемую альтернативу вебу в GUI , которая бы не выглядела как гавно мамонта и не требовала бы десятка джунов в подсобниках, респонзивилась от мобильника до десктопа и делала бы это и на макоси и на линуксах?
можно подумать, у веба здесь всё прекрасно...
Alex_ME
16.12.2021 21:25+2Странно, мне казалось, что между си и nocode не только js, но и множество других языков, популярных и нет, разной степени абстрактности: C#, Java, Kotlin, Go, Rust, D, Dart, Lua... Не JS единым. Тот же C#/Kotlin не сказать бы, что как-то сильно сложнее JS.
HemulGM
18.12.2021 00:36Найдите хоть что-то , хоть одну вменяемую альтернативу вебу в 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 фреймворков, позволяющих делать красивый интерфейс.
Chamie
18.12.2021 02:07А как там с accesibility и прочей доступностью для людей с особыми потребностями?
HemulGM
18.12.2021 12:37Например? Я, к сожалению, не сталкивался с такими требованиями.
vsh797
18.12.2021 16:00А они есть, причем всегда. :) И веб, как по мне, наиболее стандартизован и предсказуем в этом плане. Для того, чтобы веб приложение сделать неюзабельным для скринридеров, нужно приложить немалые усилия. И то останется шанс хоть как-то это обойти. А нативные платформы могут просто не иметь должную поддержку accessibility. Ведь обычно "в требованиях это явно не прописано".
HemulGM
18.12.2021 16:04Как правило, вне веба это зависит от платформы. Тот же андроид именно для этого отдельный фреймворк. Через fmx его можно использовать без проблем. Можно импортировать классы java напрямую. Так же и в винде. Доступ к данным окна можно обеспечить без проблем. Например, дня озвучки текста.
vsh797
18.12.2021 16:18Так же и в винде. Доступ к данным окна можно обеспечить без проблем.
Со стороны разработчика?
К сожалению, это не мешает многие годы официальным клиентам viber и telegram быть полностью недоступными на винде. Да и по smartgit я писал разработчикам по этому поводу. Они причем даже пытались что-то сделать, но решения так и не нашли. На андроиде тоже подобных примеров достаточно. Но там скорее халатность вроде неподписанных кнопок и недоступных элементов управления.
HemulGM
18.12.2021 18:19Не знаю как по поводу крупного шрифта, но озвучку всех элементов сделать не трудно. Например, можно обратить внимание на хинты. И при генерации вызывать нативного озвутчика. Событие имеется. А хинты вообще всегда рекомендуются. Так что проблем с этим не вижу.
Ну а в вебе придётся каждый раз что-то особенное использовать.
vsh797
18.12.2021 18:47при генерации вызывать нативного озвутчика.
Вообще озвучиванием элементов занимается скринридер. Задача программы — обеспечить навигацию с помощью клавиатуры и дать информацию для скринридера об элементах интерфейса. В вебе с этим все очень неплохо. Т.к. платформа давняя и устоявшаяся, и производители браузеров провели много работы над доступностью. А вот остальные платформы, по моим ощущениям, каждый раз должны обеспечивать свою доступность с нуля. Пусть и с использованием средств ос. Поэтому она и варьируется от полного нуля до вполне приличной. Но так как эти вопросы у компаний стоят не на первом месте, отношение у меня к ним подозрительное.
vsh797
18.12.2021 16:27Еще из последнего перевод JetBrains toolbox с web view на собственный Compose Multiplatform. Ребята хвастаются уменьшением размера приложения, увеличением отзывчивости, но accessibility пропало совсем. Обещают в перспективе поправить, но когда конкретно — неизвестно. Но им хотя бы верить можно, ведь их IDE по результатам сознательно проведенной работы вполне доступны. А пока можно сидеть на старой неэффективной версии.
Причем, что симптоматично, Compose Multiplatform недавно перешел в production ready 1.0 версию. Но accessibility там все еще нет.
gred
16.12.2021 11:48эммм. этот zed какое-то унылое говно, походу. ничего толком нету, из того, чем я бы пользовался. пока останусь на vi/vim как вездеходе, и spacemacs для локального редактирования. ничего лучше пока не видел.
Cheater
16.12.2021 13:32-2Специально создали коллизию имен с zed из zsh (встроенный редактор zsh)?
Пока выглядит как ненужно. Похоже что закрытый код, попытка сделать комбайн, NIH во все поля, и непонимание, что помимо проблемы скорости рендера основной проблемой у них является догнать по фичам хоть кого-то из лидеров (редакторов или IDE, смотря с кем они собрались соревноваться).
Видимо вдохновлялись
трупом xi-editorxi-editor, лучше бы коммитили в него.
Revertis
16.12.2021 14:06С их сайта:
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, при котором при любом изменении пересоздаётся целиком вся иерархия компонентов. При работе с большим количеством кода, при большом количестве элементов на экране, это всё будет тормозить. Можно расходиться, товарищи.
cepera_ang
16.12.2021 15:54+3Объясните, почему современные игрушки рендерят сотни кадров в секунду с миллионами треугольников, а отобразить две сотни кнопочек и страничку текста обязательно должно будет тормозить?
Gordon01 Автор
16.12.2021 16:10-2cepera_ang
16.12.2021 16:37+2Что должна обозначать эта ссылка? "Посмотрите, рендерить кнопочки и текст можно без тормозов, тут описано как" или "Посмотрите, какая это сложная задача, рендерить миллиард вещей, поддерживаемых современным браузером" (но тогда причём тут редактор кода, он что обязательно должен поддерживать весь груз веба ради отображения этой сотни квадратных панелек и странички текста?)
Revertis
16.12.2021 16:13Проблема не с самой отрисовкой, а с компоновкой и перекомпоновкой когда что-то удаляется из DOM, или что-то вставляется.
cepera_ang
16.12.2021 16:22Например внезапные зигзаообразные картинки с тенью, красиво обтекаемые программным кодом? Или что там такого нужно внезапно перекомпоновывать в редакторе кода при работе? Открыв случайный проект в VSCode, не вижу ничего кроме прямоугольных кнопок и моноширинного (!) кода на экране.
Revertis
16.12.2021 16:31+1Например, любые списки. Кстати, сколько
<span>'ов у вас на одной странице кода?
WraithOW
16.12.2021 19:39Я сварщик не настоящий, но замечу, что:
- современные видеокарты архитектурно заточены под рендеринг миллионов треугольников;
- растеризация векторного текста, а в особенности юникода — вещь далеко не самая тривиальная и быстрая (емодзи, лигатуры и прочая порнография, без которой в 2022 выпускать редактор текста как-то моветон).
В совокупности это обозначает, что львиную долю работы — растеризацию глифов и построение layout'а текста выполняет исключительно CPU, на GPU тут разве что финальный рендеринг получится отгрузить, и это отработает быстро, да.
Text Rendering Hates Youqw1
16.12.2021 19:58Не просто треугольников, а затекстуренных и с прозрачностью. Прямоугольник под букву можно сложить из двух треугольников.
Кто мешает все буквы нужного размера шрифта заранее нарисовать в текстуру, а дальше только ренедерить куски текстуры в нужные места? Или даже не буквы, а глифы со всеми возможными наклонами и деформациями, которые могут встретится в шрифте. Опять же, антиальясинг, отмеченный в вашей статье, тут из коробки.
Построение layout-а копейки, просто из-за объёмов данных. Тут надо 40-60 КБ прошерстить, это в кеш CPU влезет, это не десятки мегабайт графики.WraithOW
16.12.2021 21:02Не просто треугольников, а затекстуренных и с прозрачностью. Прямоугольник под букву можно сложить из двух треугольников.
Буква — это не прямоугольник. В этом и суть, что GPU очень хорошо умеет делать вещи, под которые он заточен, например, под вывод треугольников. Рендеринг шрифтов к таким вещам не относится (хотя у Mali вроде есть набор OpenGL-расширений для текста, так что там, возможно, ситуация получше).Кто мешает все буквы нужного размера шрифта заранее нарисовать в текстуру, а дальше только ренедерить куски текстуры в нужные места?
Никто, так и поступают. Но если вы прочитаете соответствующий раздел в статье, то узнаете, что это не универсальное решение, и у него есть свои проблемы.Или даже не буквы, а глифы со всеми возможными наклонами и деформациями, которые могут встретится в шрифте.
Если приложение будет кешировать абсолютно все глифы во всех возможных размерах и начертаниях — оно память будет жрать половниками, особенно на ретине. Про это тоже в статье есть: если дать пользователю использовать очень большие шрифты, то память кончится.Построение layout-а копейки, просто из-за объёмов данных. Тут надо 40-60 КБ прошерстить, это в кеш CPU влезет, это не десятки мегабайт графики.
Во-первых, откуда такая оценка? Во-вторых, вы же понимаете, что сложная логика даже на 40-60Кб может занять непристойно много времени? А у вас нет много времени, вам нужно все UI-операции уложить в 16мс.
Я конечно не исключаю, что вы правы. Но, с одной стороны, есть ваши слова о том, как все просто, с другой — есть объективная реальность, в которой куча разработчиков тратят кучу времени на движки рендеринга текста, с третьей — пользователи на том же хабре, которые регулярно жалуются, что шрифты мыльные. И это в целом намекает, что проблема несколько глубже, чем просто свалить в GPU текст и сказать «рендери!»qw1
16.12.2021 21:06Я не говорю, что просто. Я пытаюсь опровергнуть утверждение, что GPU в этой задаче делать нечего.
EvilFox
17.12.2021 00:27Прямоугольник под букву можно сложить из двух треугольников.
Можно и одним обойтись.
windymindy
16.12.2021 14:07Atom не умеет писать файлы атомарно, возможна потеря данных.
https://github.com/atom/atom/issues/11406
Судя по исходникам VSCode у него должна быть такая же проблема, но на последний жалются меньше.
JustDont
16.12.2021 14:37+1В VSCode сталкивался только с тем, что в некоторых ситуациях он захватывал файлы проекта и не давал их удалять другим процессам. А потом и это починили.
tangro
16.12.2021 15:35+2Разработка на С / C++ заняла бы слишком много времени и скорее всего закончилась бы неудачей проекта
Ага, а на Rust она типа уже закончилась, и удачно. Да и вообще, с чего они взяли что на Rust что-то напишется быстрее? Rust безопаснее плюсов, это да. Но не проще, и писать на нём не быстрее.
SabMakc
16.12.2021 15:42+8Rust безопаснее плюсов - а значит меньше времени уйдет на отладку. Поэтому и быстрее будет.
Gordon01 Автор
16.12.2021 16:08+8Да не только по этому.
Потому что у раста есть взрослая экосистема, а у плюсов нет ничего.
Если цель — быстро написать условную Windows 98, то есть что-то падучее, неподдерживаемое уже через несколько лет, с неверной внутренней архитектурой и слабой поддержкой многопоточности/асинхронности, под одну платформу и без внешних библиотек, но работающее реально быстро, то скорость разработки на плюсах и расте будет сравнима.
Стоит убрать из этого условия хоть что-нибудь, и внезапно оказывается, что приходится обмазываться санитайзерами, анализаторами, valgrind, делать отдельные сборки со всем этим включенным, писать тесты для абсолютно всех сценариев, обязательно прогонять фаззинг, делать отдельные релизные сборки, где все это выключено, делать джобы, которые проверяют что нужные флаги сборки РЕАЛЬНО прокидываются (ведь мы не доверяем никаким инструментам на С++), делать тесты, которые бы сравнивали поведение обеих сборок. Если что-то надо собирать под несколько платформ, то писать мозговыносящие скрипты для симейка, а потом — и вовсе надстройку над симейком. Где-то в перерыве тратить недели на поиск подходящей библиотеки, которая бы делала то что нам нужно нормально (потому что их ровно десять, но понять какая из них стоящая невозможно, пока лично не потестируешь). Ой, мы хотим стороннюю библиотеку... но она собирается тулой XYZ, которая у нас не работает. Придется выбрать другую, которая симейком собирается.
И это мы еще не дошли до самого написания самой программы!
И с чего же они взяли что на Rust что-то напишется быстрее?! Удивительно конечно, ведь все так просто, нужно просто приложить старый советский...
tangro
16.12.2021 19:47+2Обожемой, у раста нет ничего из вышеописанного просто потому, что у раста пока ещё вообще нет ничего, кроме больших перспектив. Как только на нём начнут реально писать, вот прям в продакшене, вот прям живые люди - внезапно понадобится вот это всё, поскольку языковые преимущества закроют 1% потребностей, а всё остальное как было нужно, так и будет дальше.
AnthonyMikh
17.12.2021 22:46-1На Rust прям реально пишут прям живые люди в CloudFlare, Amazon, Dropbox и ещё куче других компаний. Отзывы в основном положительные.
Alex_ME
16.12.2021 21:46+5На хабре в последнее время стало модно прям демонизировать C++. Почитаешь, так складывается ощущение, что любой хеллоу ворлд содержит сотни UB, которые компилятор трактует самым ужасным способом.
Да, C++ сложен, но чаще всего не настолько, как описывают.
IvaYan
18.12.2021 12:18Потому что у раста есть взрослая экосистема, а у плюсов нет ничего.
По ощущениям наоборот. Для плюсов можно найти почти что угодно, а вот для раста нужного часто нет, а то что есть по ощущениям сделано на половину.
Например: для линала в плюсах я использую Eigen причем с кастомным BLAS-бекендом (на маках это Accelerate, если что) и ничего подобного для раста я не нашел. Есть nalgebra, но нельзя сторонний бекенд подключить, только их самостийная реализация. Есть rust-blas, который есть обертка над произвольным BLAS-ом, но это именно обертка -- надо самому настраивать данные и дергать низкоуровневые функции.
IvaYan
16.12.2021 16:22Особенно на отладку логики.
SabMakc
16.12.2021 17:05+5Меньше времени уйдет - не значит, что отлаживать совсем не придется.
И одно дело отлаживать логику, имеющую детерминированный характер, а другое - утечки памяти, выходы за границы массива и те же гонки (при чтении/записи из разных потоков), которые имеют плавающий характер. И Rust как раз эти плавающие проблемы старается закрыть своей моделью памяти.
Так что - да, на Rust быстрее будет разработка. А главное - надежнее.
Gordon01 Автор
16.12.2021 15:44Речь шла об 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.
AnthonyMikh
16.12.2021 18:03+2Но не проще, и писать на нём не быстрее.
И проще, и быстрее. Хотя бы потому что выучить Rust реально, а выучить C++ — нет.
tangro
16.12.2021 19:50Угу, именно поэтому в мире миллион программистов на С/С++ и считанные единицы вакансий по всему миру на расте.
Lexicon
16.12.2021 15:57+3Кликбейтненый заголовок.
Вообще в такой статье хотелось бы как раз видеть ссылки на мнения разработчиков.Но в сути, сидели 4 разработчика, писали новый редактор типа Атома и решили, что веб, как рендер движок не заходит им, почему бы и нет, веб не для всего подходит. И действительно может быть бутылочным горлышком, особенно, если View очень сильно отличается по целям от браузерного.
we decided to take full control and simply build a GPU-powered UI framework
Решили не городить огородов и просто сделать для себя GPU фреймворк.
Причем тут Electron? Во всяком случае, в глобальном смысле?
Могли сделать хоть на Unreal Engine, с встроенным индикатором здоровья разработчика.
Ни для кого не новость, что Electron не подходит под все задачи, и что JS однопоточен
Ingulf
17.12.2021 08:33+2что-то мне кажется, что боязнь работы с С\С++ немного связана с незнанием новых стандартов и все-таки недостачной квалификацией, для очередного убийцы С++ у него (Rust) немного медленный рост реальных проектов
Alexey2005
17.12.2021 12:48Потому что Rust используется в качестве замены C++ только там, где по какой-то причине нельзя использовать сборку мусора. Если же есть возможность поднять GC, то вместо возни с borrow checker программисты предпочитают юзать Go. И собственно именно Go отжирает основную часть аудитории у C++, и там рост проектов очень даже заметный. А Rust'у достаются крохи вроде написания модулей для ядра Linux.
Alex_ME
17.12.2021 14:02Borrow checker - это не только про управление памятью, но и про потокобезопасность.
https://habr.com/ru/company/otus/blog/578138/
На safe Rust нельзя вызвать гонку. Вроде как.
picul
18.12.2021 04:07Нельзя вызвать data race (если использовать safe Rust). Race condition/deadlock полностью поддерживаются.
Gordon01 Автор
17.12.2021 16:00+4Если же есть возможность поднять GC, то вместо возни с borrow checker программисты предпочитают юзать Go
И затем все равно переписывают на раст, когда нужна производительность:
Отсюда можно перейти на страницы с такими историями https://serokell.io/blog/rust-companies
то вместо возни с borrow checker
Если програмист относится к borrow checker как к чему-то с чем нуждно возится, то у него просто низкий уровень. Borrow checker не мешает, а помогает. Rust не приносит ничего нового в правила написания корректных программ, он просто делает их строгими.
Проблема не в том, что borrow checker мешает, проблема в том что слишком долго нормой были языки, которые позволяют написать и скомпилировать очевидно некорректный код.
FreakII
Пресвятые Керниган и Ричи, неужели ж до кого-то стало наконец доходить!
QeqReh
Ещё бы до остальных дошло...
alexshelkov
А кто нибудь может мне объяснить почему у меня VSCode с кучей всяких плагинов (т.е работающий с Typescript как полноценная IDE), использующий электрон, работает быстрее и стабильней чем IDEA (при работе с тем же Typescript) написанная на Java? Или чтобы быстро работало нужно прям на C писать?
MyraJKee
Ну может потому что vscode это все таки ближе к паруснику, а idea это больше океанский лайнер?)
Barabas79
Угу, один такой тоже почти лайнер застрял недавно )
alexshelkov
Т.е если взять, например, WebStorm, то он будет мощнее как IDE чем VSCode? Или к чему тут ваша аналогия? А по-моему опыту VSCode на больших веб проектах (моно-репо с кучей typescript пакетов) как раз быстрее, мощнее, и глючит меньше, я даже баг репортил по этому поводу, потому что достало.
VSCode — для нескорых языков полноценная IDE, например, для веб разработки ничем не уступает тому же WebStorm.
Atton
Уступает. Редактор никогда не будет IDE.
VSCode ужасно тормозит при поиске по исходникам большого проекта.
Очень сильно расстраивают конфликтующие плагины. Когда проект сложный с разнообразными системами развертывания, деплоя, виртуализации и т.д.
JustDont
Большой — это сколько в цифрах?
Gordon01 Автор
Слишком сомнительно. Для поиска в VSCode используется ripgrep, быстрее которого ничего нет.
jtraub
https://github.com/Genivia/ugrep#performance-results
Gordon01 Автор
У разработчиков ripgrep другие данные. Почему?
rjhdby
Потому, что они разработчики ripgrep? Собственно то-же самое можно сказать и о бенчмарке выше.
cepera_ang
Быстрее которого в сплошном поиске ничего нет, но можно же индексировать файлы, тем более что код меняется со скоростью несколько килобайт в день в худшем случае.
pbatanov
Мы сейчас обсуждаем только простой полнотекстовый поиск или все таки в том числе всякие другие поисковые возможности, анализирующие содержимое, навроде поиска вызовов функций, использования элементов языка (с учетом разного рода импортов типа *) и т.д.?
vscode делает, например, поиск использования приватного свойства класса (300 строк) настолько долго, что после phpstorm я успеваю нажать еще пару раз, думая, что оно не сработало. шторм открывает юзейджи практически мгновенно
cepera_ang
vscode или то, что он использует под капотом для вашего конкретного языка? (это не умаляёт того, что комплекс vscode + расширения для языка как единый продукт могут быть тормозными)
pbatanov
я поставил какой-то топовый по загрузкам экстеншен, без него это совсем не работало.но не надо забывать,что php - это на самом деле тоже расширение для idea, иными словами phpstorm - это преконфигуренная идея
cepera_ang
Проприетарное расширение от авторов самого софта — это не просто "преконфигуренная идея" :)
pbatanov
Я упростил, да. Тем не менее это все же расширение, я про это. Сама идея - технически опенсурсная, можно также написать свое расширение под %языкнейм% (как было например с андроид студией, насколько я помню)
https://github.com/JetBrains/intellij-community
Т.е. фактически разница в том, что к одной системе написали годное расширение, а к другой нет, и за годное хотят деняк.
upd. попробовал поставить расширение php Для idea ultimate - работает так же моментально все после индексации. Так что тезис про преконфигуренную идею работает
gev
+100500!
alexeishch
Во-первых, потому что VSCode написан компанией, которая делает лучшие среды разработки на этой планете (это главная причина)
IDEA же изначально была глотком воздуха в мире безумства авторов Java, которые изначально(!) решили что джаве своя IDE не нужна. Но основная проблема Java с жором памяти никуда не делась.
Во-вторых, потому что JavaScript там всё же компилируется, благодаря V8. Без этого Electron был бы не юзабелен.
От себя добавлю, что Visual Studio на винде работает быстрее чем IDEA на MacOS (проверялось на одном интеловском ноуте Apple). А так покупайте Мак - с его железом разница в производительности не ощущается, если памяти 32Гб
alexshelkov
Т.е я правильно понял, что в посте где за производительность, ругают электрон (=VSCode) вы предлагаете покупать комп помощнее, чтобы быстрее работала Java(=WebStorm), ведь электрон и так работает быстро?
PS. Я и так сижу на Маке :)
KReal
Долгое время считал так же (Visual Studio rulezz), но в итоге с удовольствием перешёл на Rider (c# / .net core). Однако для фронта использую VS Code)
Alexsey
Моя первая и единственная попытка переезда на райдер провалилась после того как я обнаружил что там даже не вся функциональность решарпера есть. Например тогда не было превью начала блока { } при наведении на закрывающую скобку. И это уже была релизная версия райдера, не превью.
Ну и в энтерпрайзе на райдер переехать можно только если вы не зависите от каких-нибудь библиотек, которые в студию плагины ставят.
KReal
Я не использовал решарпер на всю катушку, так что мне этой боли не понять) И да, с библиотеками и плагинами проблем тоже не было.
kira-dev
Я на нем с бетки сижу(на работе - с релиза) и чет особо не страдаю от отсутствия превью блока)
Лично меня достала скорость работы вижлы с решарпером, и поэтому я перешел на иде пошустрее, пусть даже там чего и не было на момент релиза.
yroman
Это Visual Studio лучшая среда разработки? Очень голословное утверждение. Про её производительность и про Resharper я вообще скромно умолчу.
telpos
Потому что ms переписала критические куски кода на webassembly
Flux
Потому что ты всегда побеждаешь если волен выбирать удобного соперника. IDEA действительно тормозит, но это не очко в пользу приложений на электроне. Есть замечательный Sublime Text, приложение одного класса с VSCode, который всегда работает быстрее последнего. Есть намного более тяжелая Visual Studio которая тоже работает быстрее чем VSCode.
Собственно, и электрон можно допилить до юзабельного состояния, но какой ценой? VSCode делает огромная команда разработчиков за которыми стоит бюджет MS, Sublime пишется на плюсах командой из одного или двух разработчиков (насколько я знаю).
А IDEA довольно стара и видимо страдает от неудачной архитектуры языкового ядра общего для всех продуктов JetBrains.
AlexSelivanoff
Да ещё и батарейку у ноута VSCode расходует намного гуманнее, чем Idea
Revertis
Хуже всего то, что эти уважаемые "синьоры" только после неудачного опыта поняли, что на JS всё будет тормозить.
picul
Присмотритесь, до них все еще не дошло, они переписывают графический фреймворк.
Revertis
Не, ну они же заявили, что таки поняли, что именно HTML/CSS/JS всё тормозили.
picul
Ага, увидел цитату в конце. Ну, не прошло и десяти лет. А нет, прошло...
Gordon01 Автор
У меня один вопрос: если все вокруг точно знают как нужно сделать, то почему за прошедшие 9 лет с момента представления Электрона его убийцу так и не написали?
Revertis
Бизнес ориентируется на скорость выпуска продуктов, а не на качество продукта. Иначе можно проиграть конкуренту, который говнокодит такую же идею быстрее.
Gordon01 Автор
Вы будто сами с собой разговариваете.
Но текущая команда Zed — 4 человека.
Если зайти в обсуждение любого софта на электроне, то половина будет ТОЧНО знать какую технологию стоило использовать, вместо электрона, чтобы все работало быстро. Где все эти сотни убийц электрона от тысяч разработчиков по всему миру?
Revertis
Так я не про Zed говорил, а про кучу других продуктов по миру.
А вот об этом как раз мой предыдущий коммент, на который вы отвечали.
picul
Да просто разработчиков согнали быдлокодить на Электроне по-быстрому, дабы компании могли увеличить прибыль за счет сокращения затрат на разработку. Если бы силы, вложенные в Электрон, были бы вложены в разработку нормальных альтернатив - вопросов бы не возникало.
Gordon01 Автор
Если бы да кабы в саду выросли грибы.
Везде заговор ради того, чтобы сделать ТС мейнстримом.
picul
Какой еще заговор, обычный маркетинг. Жабаскрип был распиарен как "легкий" язык для веба еще в момент создания, далее спрос на веб породил огромное количество специалистов, а дальше уже принцип снежного кома.
Gordon01 Автор
Но почему все эти тысячи людей, который точно знают как нужно не собрались и не сделали нормально?
Каждый пишет что "заговор" "распиарен" итд, но в итоге разгадка всегда одна — ничего лучше просто нет. И можно сколько угодно чесать языками и поливать JS, но комментарии не превращаются в код и тем более в продукт.
Еще вчера для быстрых программ ничего кроме С / С++ не было, сегодня есть раст, зиг и на них пишут программы, потому что они объективно лучше.
Просто возьмите и напишите убийцу JS, станьте миллионером, это ведь не сложно, по вам видно что вы ТОЧНО ЗНАЕТЕ ЧТО НУЖНО ДЕЛАТЬ.
DirectoriX
Вторая проблема Electron — вся его браузерная половина. Большинство приложений даже близко не используют всю ту бездну
говнокодавозможностей, которые заложены в Chromium. Когда вы в последний раз пользовались Slack-приложением с помощью геймпада? Это почти как зайти в магазин бытовой техники и купить по 1 товару из каждой категории, на всякий случай. Ну и пусть потом вафельница пылится на газонокосилке, нужный нам утюг-то купили!Gordon01 Автор
Вы только что и написали критерий "лучшести". Что-то такое, что бы позволяло писать кросс-платформенные графические программы, где hello-world весил бы меньше 100 МБ.
Там, где ненужные фичи можно отпилить и не кидать в бандл.
avengerweb
Да 100мб куда уж там, если что у меня на телефоне 1Тб памяти. Сравнивать hello world очень прикольно, но фишка в том что в 100мб уже содержат все. Да, да как только вы в своё приложение, назовите язык, начнёте добавлять нужные вам библиотеки его размер будет доростать для электрона. Поэтому никто и не парится. Вам не нужен ffmpeg до того момента пока ваш маркетинг отдел не попросит вас засунуть видосик с овервью обновления прямо в приложение. А потом ещё окажется что в ваше приложение все равно нужно вставить веб-вью по какой нибудь причине. И тут все уже переплюнули размер электрона
Gordon01 Автор
Ещё очень интересно спросить у этих специалистов по всему какой-нибудь легковесный аналог ffmpeg, чтобы воспроизвести нормально сжатое видео в своей программе, вот смеху то будет)
picul
Смеху будет, когда до Вас дойдет, что никаких альтернатив не требуется - нужно статически вкомпилировать ffmpeg в приложение, и компилятор сам выкинет абсолютно все лишнее. Правда Вам как "специалисту не по всему" видимо придется для начала объяснить что такое компиляция.
mafia8
А что они не сделали как с .net и vc_redist? Чтобы Electron тоже устанавливался отдельно.
qark
В некоторых линуксах так и сделали https://repology.org/project/electron/versions. Оказалось, что разработчики не спешат использовать актуальный Electron. В итоге почти каждая версия нужна одному-двум приложениям, что сводит на нет преимущество отдельной установки.
Забавно, что ни Atom, ни VSCode не используют свежий Electron.
picul
Причин много. Во-первых, без пиара технология не взлетит вообще, а преодолеть пиар технологий конкурентов в принципе не факт что возможно, учитывая что за ними стоят производители браузеров. Во-вторых, люди в принципе обычно вместе не собираются - нужна компания и нужны деньги, которые никто не даст, потому что см. "во-первых".
Ну это как раз "от создателей" лагающего веба и фреймворков типа электрона. Игры проводят сложнейшие симуляции 60 и больше раз в секунду, HFT-системы работают с наносекундными задержками, но вот для на веба ничего лучше просто нет.
Ага, "объективно". Это вы спроецировали фронтендерское "новый модный фреймворк лучше старого"?
Зачем их писать? Их уже вагон и маленькая тележка. Возьмите любой современный не-эзотерический язык - он будет лучше чем JS. А теперь попробуйте убедить Гугл впилить поддержку этого языка в Chromium наравне с JS. И после этого подождите лет 10, пока он раскрутится.
Gordon01 Автор
Я дико извиняюсь, но поддержка WebAssembly впилена в современные браузеры. И даже понадобилось меньше 10 лет.
SabMakc
Справедливости ради - WebAssembly не особо запустишь без JavaScript-обвязки...
lam0x86
Это переходный период. Когда из WebAssembly можно будет делать всё то же, что и из JS, то импорты типа `<script src="myassembly.wasm"></script>` (ну или более элегантный подход) появятся очень быстро.
picul
Я тоже извинясь, но WebAssembly - это средство выработки выученной беспомощности у веб-программистов. Так извращенно добавить нормальные языки надо постараться, это под силу лишь лучшим из тех, кто заинтересован в сохранении доминации JS.
freecoder_xx
Это смотря на каком языке вы будете программировать. Я использую Rust и он хорошо подходит для использования с WebAssembly.
thesun2003
У Electron есть один "фатальный недостаток". https://lurkmore.to/Фатальный_недостаток
Alexey2005
Кроссплатформенность. Именно в ней весь затык. В современном мире обеспечить кроссплатформенную работу не просто сложно, а чрезвычайно сложно.
Но если мы ограничиваемся только одной платформой, то проблем нет и убийц Electron хватает. Скажем, под x86+Windows у нас есть .NET Framework, который буквально нокаутирует Electron.
SKProCH
Да нет, достаточно давно все уже есть - Qt на C++ способен в запуск на большинстве популярных платформ. На Mono был Xamarin. С появлением .Net Core - Avalonia, с появлением .Net 5 - MAUI.
Gordon01 Автор
Маленькая загвоздка: Qt на C++ не способен в быструю разработку.
За пределами энерпрайза об этом почти никто не знает и не хочет знать.
TiGR
Есть же QtQuick
harios
Кхм кхм...так то еще Delphi умеет в кросплатформу и быстро.
AlexSelivanoff
И судя по рассылке в моей почте, он ещё и вполне себе жив
harios
А чо ему быть мертвым, я уже пощупал 11 версию и она очень даже ничего.
AlexSelivanoff
Да я просто с версии с 7й ничего на нем не писал больше хеллоуворлда и как-то вокруг пишущих на дельфи не видать, поэтому каждый раз радуюсь, что он жив ещё
beezy92
у QT проблема с лицензией, с 5-й версией они решили периеграть лицензию, и выпускать на ней коммерческий продукт стало не выгодно.
apro
Как все основные части были под lgpl 4 версии, так в 5 и остались. Что поменялось?
vtb_k
Tauri на расте опять же)
Gordon01 Автор
Ну это опять раст, да. Еще пять лет назад про него знало слишком мало человек))
Просто громче всего "закопать электрон и переписать на нативщину" кричат обычно плюсовики, которые не могут в адекватные сроки сделать ни того, ни другого.
vtb_k
Все время забываю, что новый "красивый" редактор комментов хабра съедает хтмл тег
</sarcasm>picul
Плюсовики вообще не кричат особо, опять проецируете на фронтендеров.
0xd34df00d
Конечно не кричат, устали кричать после всех UB.
picul
Эхх, давно я не ловил старого доброго UB. И что со мной не так...
0xd34df00d
Я тоже давно не ловил — просто уже почти два года не пишу на плюсах.
BioHazzardt
я не плюсовик, но свои три копейки вставлю — главная проблема плюсов даже не неопределенное поведение, зная архитектуру и внутреннее устройство языка избежать этого можно (если, конечно, задача плюс-минус типовая), а проблема в долгой компиляции. Очень бесит, когда получасовая компиляция бросает тебе некислый трейс, когда ты просто точку с запятой поставить забываешь)
Gordon01 Автор
Хах, это вы ещё раст не коНпеляли))
BioHazzardt
раст трогал ради интереса, там все норм. Просто плюсы я не в IDEшках делаю, а в Kate, там кроме подсветки синтаксиса нихрена особо и нету. Если подскажете хорошую IDE под плюсы на линуксах буду благодарен
0xd34df00d
Раньше kdevelop норм было, теперь стало валиться на больших проектах с кучей хардкорных темплейтов (но для мелочёвки норм).
CLion, в принципе, относительно сойдёт. Ему бы отзывчивость уровня kdevelop — и будет шикарно.
QtCreator ещё народ хвалит, но я не осилил, их работа с многотаргетными проектами меня просто убивает, придумать хуже было невозможно.
BioHazzardt
спасибо) но QtCreator именно для QT хорошо работает, и при разработке на Qt я его в основном и использую, kdevelop ну так себе, вылетает часто, Clion не использовал, попробую
allcreater
Долгая компиляция обусловлена необходимостью инстанциировать шаболоны и инлайнить всё, что плохо лежит. Это, безусловно, большой минус для пользователя, но и немалый плюс для получившейся на выходе компилятора программы, так что в итоге баланс соблюдается.
Насколько лично мне известно, std::ranges из C++20, предоставляющие функциональный доступ к контейнерам, чуть ли не только в "плюсах" могут работать так же быстро, как написанные от руки циклы, и именно благодаря этой фиче компилятора.
Полотна ошибок же в шаблонном коде давно стали притчей во языцах, но ситуация начинает улучшаться: концепты позволят проверять соответствие интерфейса при вызове библиотечных функций, а не глубоко внутри них, как это было раньше.
Gordon01 Автор
Это было в расте еще лет 5-7 назад (а может и больше). https://doc.rust-lang.org/std/iter/index.html
Ленивое выполнение std::ranges умеют?
allcreater
В более-мене современном виде в C++ оно появилось лет 12 назад в Boost (а первые попытки затащить были в в далёком 2003), но до реализации в стандарте ехало долго: библиотеку полировали, и тем временем учили компилятор не выдавать полотна сообщений в ответ на одну ошибку при инстанциировании шаблона.
Так это ж стандартная фича для таких библиотек.
0xd34df00d
Что-то там инлайнится только тогда, когда включены оптимизации. Долгая компиляция обусловлена достаточно наркоманской семантикой темплейтов и неудачной грамматикой, которая, вообще говоря, не то что не контекстно-свободна (что парсить было бы легко), а неразрешима.
У меня были проекты, где TU компилируется без оптимизаций условно пять минут, а с оптимизациями — пять минут тридцать секунд. Остальное время — шаблоны, да.
Проблема с шаблонами (по сравнению с аналогичными средствами полиморфизма из более других языков) в том, что подстановка аргумента в шаблон не сводится к подстановке конкретных методов этого объекта. Подстановка аргумента требует практически с нуля распарсить всё тело функции, выполнить name lookup, и так далее. Это долго, больно и неприятно.
qw1
Видишь UB? И я не вижу. А он в моём коде есть…
Alexey2005
Flux
Язык другой — грабли те же.
spqr_voldi
Не надо его убивать, ему просто не надо жить.
vovchisko
Слепая ненависть к JS detected :)
Все зависит от кривизны рук. У меня есть примеры оверлея для игры (более одного), и все летает без просадки FPS. И тот же клиент для БД (забыл как его, зыбал как его, но кажется что-то для mongodb) который тормозит просто когда по нему мышкой водишь.
Revertis
Так всё зависит от количества текста. Ваш оверлей видимо три строчки выводит и всё.
Например, в HTML не сделать нормальные списки сообщений, в случае применения для мессенджеров. Всё тормозит.
JustDont
А пацаны-то и не знают, что существует виртуализация.
Которая, кстати, становится нужна только когда ваши "нормальные списки" доходят хотя бы эдак до тысяч элементов, если вы печетесь о юзерах со старыми мобилками. И до десятков тысяч, если нет.
Если у вас "нормальные списки" начинают тормозить раньше — проблема в вас, а не в HTML.
Revertis
Ну как бы я не настоящий JS'ник, я пишу под Андроид и на Расте. А вижу тормоза именно как пользователь. Везде.
JustDont
Я тоже. А потом как "настоящий JS'ник" прихожу куда-нибудь работать и вижу там на фронте список на 100 элементов, который тормозит. Не потому, что список, и не потому, что на 100 элементов. А потому, что фронт написан настолько убого, что перерисовывается целиком на любое действие пользователя (а иногда и на бездействие тоже).
А потом прихожу работать в другое место, и вижу там то же самое. И так далее. И потом когда как пользователь хожу по тормозящему вебу — уже не удивляюсь ничему.
Дело не в HTML, и даже не в JS, а в минимизации затрат на разработку. В конце концов, я как "обычный пользователь" с андроидом вам тоже могу предъявить, что в мобилке кругом почему-то безумно тормозные и забагованные приложения. Видать, чё-то не на расте их пишут ^_^
Alexey2005
Я подозреваю, что их уже и на чистой Java никто не пишет, а юзают какие-то говнофреймворки для ускорения разработки.
Недаром же каждый фонарик требует 100500 разрешений, включая доступ к отправке SMS. Сразу видно, что разработчики заюзали какие-то готовые компоненты с параметрами по умолчанию, которые запрашивают всего и побольше.
SabMakc
Это для интеграции рекламы обычно требуется куча разрешений.
Saiv46
К слову, как пользователь я вижу что именно приложения на Rust тормозят, в отличии от Electron-приложении (правда с потреблением памяти беда)
Revertis
Ух ты, интересно, какие? :)
cepera_ang
На расте есть приложения?
/s
x8core
Дело не в электроне, а скорее просто в устаревшем вебе, который вероятно отправится на свалку вместе с кастомными костылями вроде реакта, вью и прочих хоть и весьма изящных, но всё же костылей и стероидов.
HemulGM
++. Сахара, конечно можно сыпать сколько угодно, но вскоре пузырь лопнет