Три бывших разработчика (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)


  1. FreakII
    16.12.2021 02:37
    +140

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

    Пресвятые Керниган и Ричи, неужели ж до кого-то стало наконец доходить!


    1. QeqReh
      16.12.2021 07:29
      +26

      Ещё бы до остальных дошло...


    1. alexshelkov
      16.12.2021 13:18
      +36

      А кто нибудь может мне объяснить почему у меня VSCode с кучей всяких плагинов (т.е работающий с Typescript как полноценная IDE), использующий электрон, работает быстрее и стабильней чем IDEA (при работе с тем же Typescript) написанная на Java? Или чтобы быстро работало нужно прям на C писать?


      1. MyraJKee
        16.12.2021 13:34
        +25

        Ну может потому что vscode это все таки ближе к паруснику, а idea это больше океанский лайнер?)


        1. Barabas79
          16.12.2021 13:39
          +4

          Угу, один такой тоже почти лайнер застрял недавно )


        1. alexshelkov
          16.12.2021 14:41
          +9

          Т.е если взять, например, WebStorm, то он будет мощнее как IDE чем VSCode? Или к чему тут ваша аналогия? А по-моему опыту VSCode на больших веб проектах (моно-репо с кучей typescript пакетов) как раз быстрее, мощнее, и глючит меньше, я даже баг репортил по этому поводу, потому что достало.

          VSCode — для нескорых языков полноценная IDE, например, для веб разработки ничем не уступает тому же WebStorm.


          1. Atton
            16.12.2021 15:48
            +6

            Уступает. Редактор никогда не будет IDE.

            VSCode ужасно тормозит при поиске по исходникам большого проекта.

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


            1. JustDont
              16.12.2021 16:23
              +3

              VSCode ужасно тормозит при поиске по исходникам большого проекта.

              Большой — это сколько в цифрах?


            1. Gordon01 Автор
              16.12.2021 16:28
              +10

              VSCode ужасно тормозит при поиске по исходникам большого проекта.

              Слишком сомнительно. Для поиска в VSCode используется ripgrep, быстрее которого ничего нет.


              1. jtraub
                16.12.2021 16:37
                +3

                Для поиска в VSCode используется ripgrep, быстрее которого ничего нет.

                https://github.com/Genivia/ugrep#performance-results


                1. Gordon01 Автор
                  16.12.2021 16:47

                  У разработчиков ripgrep другие данные. Почему?


                  1. rjhdby
                    16.12.2021 22:41
                    +5

                    Потому, что они разработчики ripgrep? Собственно то-же самое можно сказать и о бенчмарке выше.


              1. cepera_ang
                16.12.2021 16:39
                +19

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


              1. pbatanov
                16.12.2021 17:31
                +7

                Для поиска в VSCode используется ripgrep

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

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


                1. cepera_ang
                  16.12.2021 17:33
                  +1

                  vscode или то, что он использует под капотом для вашего конкретного языка? (это не умаляёт того, что комплекс vscode + расширения для языка как единый продукт могут быть тормозными)


                  1. pbatanov
                    16.12.2021 17:37
                    -3

                    я поставил какой-то топовый по загрузкам экстеншен, без него это совсем не работало.но не надо забывать,что php - это на самом деле тоже расширение для idea, иными словами phpstorm - это преконфигуренная идея


                    1. cepera_ang
                      16.12.2021 17:40

                      Проприетарное расширение от авторов самого софта — это не просто "преконфигуренная идея" :)


                      1. pbatanov
                        16.12.2021 17:52

                        Я упростил, да. Тем не менее это все же расширение, я про это. Сама идея - технически опенсурсная, можно также написать свое расширение под %языкнейм% (как было например с андроид студией, насколько я помню)

                        https://github.com/JetBrains/intellij-community

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

                        upd. попробовал поставить расширение php Для idea ultimate - работает так же моментально все после индексации. Так что тезис про преконфигуренную идею работает


      1. gev
        16.12.2021 14:18
        -5

        +100500!


      1. alexeishch
        16.12.2021 14:52
        +4

        Во-первых, потому что VSCode написан компанией, которая делает лучшие среды разработки на этой планете (это главная причина)
        IDEA же изначально была глотком воздуха в мире безумства авторов Java, которые изначально(!) решили что джаве своя IDE не нужна. Но основная проблема Java с жором памяти никуда не делась.
        Во-вторых, потому что JavaScript там всё же компилируется, благодаря V8. Без этого Electron был бы не юзабелен.

        От себя добавлю, что Visual Studio на винде работает быстрее чем IDEA на MacOS (проверялось на одном интеловском ноуте Apple). А так покупайте Мак - с его железом разница в производительности не ощущается, если памяти 32Гб


        1. alexshelkov
          16.12.2021 15:02
          +12

          Т.е я правильно понял, что в посте где за производительность, ругают электрон (=VSCode) вы предлагаете покупать комп помощнее, чтобы быстрее работала Java(=WebStorm), ведь электрон и так работает быстро?

          PS. Я и так сижу на Маке :)


        1. KReal
          16.12.2021 16:53
          +10

          Долгое время считал так же (Visual Studio rulezz), но в итоге с удовольствием перешёл на Rider (c# / .net core). Однако для фронта использую VS Code)


          1. Alexsey
            16.12.2021 17:52
            +1

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

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


            1. KReal
              16.12.2021 18:07

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


            1. kira-dev
              16.12.2021 21:41
              +3

              Я на нем с бетки сижу(на работе - с релиза) и чет особо не страдаю от отсутствия превью блока)

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


        1. yroman
          16.12.2021 17:35
          -6

          Это Visual Studio лучшая среда разработки? Очень голословное утверждение. Про её производительность и про Resharper я вообще скромно умолчу.


      1. telpos
        16.12.2021 17:06
        +4

        Потому что ms переписала критические куски кода на webassembly


      1. Flux
        16.12.2021 23:20
        +5

        А кто нибудь может мне объяснить почему у меня VSCode с кучей всяких плагинов ..., использующий электрон, работает быстрее и стабильней чем IDEA

        Потому что ты всегда побеждаешь если волен выбирать удобного соперника. IDEA действительно тормозит, но это не очко в пользу приложений на электроне. Есть замечательный Sublime Text, приложение одного класса с VSCode, который всегда работает быстрее последнего. Есть намного более тяжелая Visual Studio которая тоже работает быстрее чем VSCode.


        Собственно, и электрон можно допилить до юзабельного состояния, но какой ценой? VSCode делает огромная команда разработчиков за которыми стоит бюджет MS, Sublime пишется на плюсах командой из одного или двух разработчиков (насколько я знаю).


        А IDEA довольно стара и видимо страдает от неудачной архитектуры языкового ядра общего для всех продуктов JetBrains.


      1. AlexSelivanoff
        17.12.2021 06:44
        +1

        Да ещё и батарейку у ноута VSCode расходует намного гуманнее, чем Idea


    1. Revertis
      16.12.2021 13:52
      +9

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


      1. picul
        16.12.2021 14:55

        Присмотритесь, до них все еще не дошло, они переписывают графический фреймворк.


        1. Revertis
          16.12.2021 14:57
          +1

          Не, ну они же заявили, что таки поняли, что именно HTML/CSS/JS всё тормозили.


          1. picul
            16.12.2021 15:07
            +3

            Ага, увидел цитату в конце. Ну, не прошло и десяти лет. А нет, прошло...


      1. Gordon01 Автор
        16.12.2021 15:02
        +4

        У меня один вопрос: если все вокруг точно знают как нужно сделать, то почему за прошедшие 9 лет с момента представления Электрона его убийцу так и не написали?


        1. Revertis
          16.12.2021 15:07
          +14

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


          1. Gordon01 Автор
            16.12.2021 15:16
            +6

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

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

            Вы будто сами с собой разговариваете.

            Но текущая команда Zed — 4 человека.

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


            1. Revertis
              16.12.2021 15:49

              Вы будто сами с собой разговариваете.

              Но текущая команда Zed — 4 человека.

              Так я не про Zed говорил, а про кучу других продуктов по миру.

              Где все эти сотни убийц электрона от тысяч разработчиков по всему миру?

              А вот об этом как раз мой предыдущий коммент, на который вы отвечали.


            1. picul
              16.12.2021 16:03
              +2

              Где все эти сотни убийц электрона от тысяч разработчиков по всему миру?

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


              1. Gordon01 Автор
                16.12.2021 16:21
                +4

                Если бы да кабы в саду выросли грибы.

                Везде заговор ради того, чтобы сделать ТС мейнстримом.


                1. picul
                  16.12.2021 16:32
                  -1

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


                  1. Gordon01 Автор
                    16.12.2021 16:39
                    +7

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

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

                    Еще вчера для быстрых программ ничего кроме С / С++ не было, сегодня есть раст, зиг и на них пишут программы, потому что они объективно лучше.

                    Просто возьмите и напишите убийцу JS, станьте миллионером, это ведь не сложно, по вам видно что вы ТОЧНО ЗНАЕТЕ ЧТО НУЖНО ДЕЛАТЬ.


                    1. DirectoriX
                      16.12.2021 17:14
                      +3

                      ничего лучше просто нет
                      А каков критерий «лучшести»? Electron-приложения, например, на диске занимают не менее 100 МБ только за счёт исполняемого файла, а ведь вместе с ними ещё и пачка DLL/SO идёт в комплекте (зачем мне та же ffmpeg.dll для VS Code?). Да, дисковое пространство не такое уж дорогое, но когда даже Hello World весит по 100+ МБ… тут явно есть какой-то подвох.
                      Вторая проблема Electron — вся его браузерная половина. Большинство приложений даже близко не используют всю ту бездну говнокода возможностей, которые заложены в Chromium. Когда вы в последний раз пользовались Slack-приложением с помощью геймпада? Это почти как зайти в магазин бытовой техники и купить по 1 товару из каждой категории, на всякий случай. Ну и пусть потом вафельница пылится на газонокосилке, нужный нам утюг-то купили!


                      1. Gordon01 Автор
                        16.12.2021 17:32

                        Вы только что и написали критерий "лучшести". Что-то такое, что бы позволяло писать кросс-платформенные графические программы, где hello-world весил бы меньше 100 МБ.

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


                      1. avengerweb
                        16.12.2021 19:43
                        +3

                        Да 100мб куда уж там, если что у меня на телефоне 1Тб памяти. Сравнивать hello world очень прикольно, но фишка в том что в 100мб уже содержат все. Да, да как только вы в своё приложение, назовите язык, начнёте добавлять нужные вам библиотеки его размер будет доростать для электрона. Поэтому никто и не парится. Вам не нужен ffmpeg до того момента пока ваш маркетинг отдел не попросит вас засунуть видосик с овервью обновления прямо в приложение. А потом ещё окажется что в ваше приложение все равно нужно вставить веб-вью по какой нибудь причине. И тут все уже переплюнули размер электрона


                      1. Gordon01 Автор
                        16.12.2021 20:27

                        Ещё очень интересно спросить у этих специалистов по всему какой-нибудь легковесный аналог ffmpeg, чтобы воспроизвести нормально сжатое видео в своей программе, вот смеху то будет)


                      1. picul
                        16.12.2021 21:10
                        +11

                        Смеху будет, когда до Вас дойдет, что никаких альтернатив не требуется - нужно статически вкомпилировать ffmpeg в приложение, и компилятор сам выкинет абсолютно все лишнее. Правда Вам как "специалисту не по всему" видимо придется для начала объяснить что такое компиляция.


                      1. mafia8
                        17.12.2021 08:55

                        Electron-приложения, например, на диске занимают не менее 100 МБ

                        А что они не сделали как с .net и vc_redist? Чтобы Electron тоже устанавливался отдельно.


                      1. qark
                        18.12.2021 13:32

                        В некоторых линуксах так и сделали https://repology.org/project/electron/versions. Оказалось, что разработчики не спешат использовать актуальный Electron. В итоге почти каждая версия нужна одному-двум приложениям, что сводит на нет преимущество отдельной установки.
                        Забавно, что ни Atom, ни VSCode не используют свежий Electron.


                    1. picul
                      16.12.2021 17:30
                      +7

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

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

                      ничего лучше просто нет.

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

                      Еще вчера для быстрых программ ничего кроме С / С++ не было, сегодня есть раст, зиг и на них пишут программы, потому что они объективно лучше.

                      Ага, "объективно". Это вы спроецировали фронтендерское "новый модный фреймворк лучше старого"?

                      Просто возьмите и напишите убийцу JS

                      Зачем их писать? Их уже вагон и маленькая тележка. Возьмите любой современный не-эзотерический язык - он будет лучше чем JS. А теперь попробуйте убедить Гугл впилить поддержку этого языка в Chromium наравне с JS. И после этого подождите лет 10, пока он раскрутится.


                      1. Gordon01 Автор
                        16.12.2021 19:02

                        Я дико извиняюсь, но поддержка WebAssembly впилена в современные браузеры. И даже понадобилось меньше 10 лет.


                      1. SabMakc
                        16.12.2021 19:12
                        +1

                        Справедливости ради - WebAssembly не особо запустишь без JavaScript-обвязки...


                      1. lam0x86
                        16.12.2021 20:38

                        Это переходный период. Когда из WebAssembly можно будет делать всё то же, что и из JS, то импорты типа `<script src="myassembly.wasm"></script>` (ну или более элегантный подход) появятся очень быстро.


                      1. picul
                        16.12.2021 19:14
                        +1

                        Я тоже извинясь, но WebAssembly - это средство выработки выученной беспомощности у веб-программистов. Так извращенно добавить нормальные языки надо постараться, это под силу лишь лучшим из тех, кто заинтересован в сохранении доминации JS.


                      1. freecoder_xx
                        17.12.2021 01:21

                        Это смотря на каком языке вы будете программировать. Я использую Rust и он хорошо подходит для использования с WebAssembly.


                    1. thesun2003
                      16.12.2021 23:03
                      -1

                      У Electron есть один "фатальный недостаток". https://lurkmore.to/Фатальный_недостаток


        1. Alexey2005
          16.12.2021 16:26
          +4

          Кроссплатформенность. Именно в ней весь затык. В современном мире обеспечить кроссплатформенную работу не просто сложно, а чрезвычайно сложно.
          Но если мы ограничиваемся только одной платформой, то проблем нет и убийц Electron хватает. Скажем, под x86+Windows у нас есть .NET Framework, который буквально нокаутирует Electron.


          1. SKProCH
            16.12.2021 17:50
            +1

            Да нет, достаточно давно все уже есть - Qt на C++ способен в запуск на большинстве популярных платформ. На Mono был Xamarin. С появлением .Net Core - Avalonia, с появлением .Net 5 - MAUI.


            1. Gordon01 Автор
              16.12.2021 18:04
              +1

              Qt на C++ способен в запуск на большинстве популярных платформ

              Маленькая загвоздка: Qt на C++ не способен в быструю разработку.

              На Mono был Xamarin. С появлением .Net Core - Avalonia, с появлением .Net 5 - MAUI.

              За пределами энерпрайза об этом почти никто не знает и не хочет знать.


              1. TiGR
                16.12.2021 21:26
                +2

                Есть же QtQuick


            1. harios
              17.12.2021 01:11
              +5

              Кхм кхм...так то еще Delphi умеет в кросплатформу и быстро.


              1. AlexSelivanoff
                17.12.2021 07:00

                И судя по рассылке в моей почте, он ещё и вполне себе жив


                1. harios
                  17.12.2021 09:11

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


                  1. AlexSelivanoff
                    17.12.2021 11:07

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


            1. beezy92
              17.12.2021 20:33
              -2

              у QT проблема с лицензией, с 5-й версией они решили периеграть лицензию, и выпускать на ней коммерческий продукт стало не выгодно.


              1. apro
                18.12.2021 11:53

                Как все основные части были под lgpl 4 версии, так в 5 и остались. Что поменялось?


        1. vtb_k
          16.12.2021 18:17

          почему за прошедшие 9 лет с момента представления Электрона его убийцу так и не написали?

          Tauri на расте опять же)


          1. Gordon01 Автор
            16.12.2021 18:21
            +2

            Ну это опять раст, да. Еще пять лет назад про него знало слишком мало человек))


            Просто громче всего "закопать электрон и переписать на нативщину" кричат обычно плюсовики, которые не могут в адекватные сроки сделать ни того, ни другого.


            1. vtb_k
              16.12.2021 18:32

              Все время забываю, что новый "красивый" редактор комментов хабра съедает хтмл тег </sarcasm>


            1. picul
              16.12.2021 19:22
              +1

              Плюсовики вообще не кричат особо, опять проецируете на фронтендеров.


              1. 0xd34df00d
                16.12.2021 21:33
                +1

                Конечно не кричат, устали кричать после всех UB.


                1. picul
                  16.12.2021 21:41

                  Эхх, давно я не ловил старого доброго UB. И что со мной не так...


                  1. 0xd34df00d
                    16.12.2021 23:45
                    +2

                    Я тоже давно не ловил — просто уже почти два года не пишу на плюсах.


                    1. BioHazzardt
                      16.12.2021 23:59

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


                      1. Gordon01 Автор
                        17.12.2021 00:09
                        -1

                        Хах, это вы ещё раст не коНпеляли))


                      1. BioHazzardt
                        17.12.2021 00:12

                        раст трогал ради интереса, там все норм. Просто плюсы я не в IDEшках делаю, а в Kate, там кроме подсветки синтаксиса нихрена особо и нету. Если подскажете хорошую IDE под плюсы на линуксах буду благодарен


                      1. 0xd34df00d
                        17.12.2021 01:25

                        Раньше kdevelop норм было, теперь стало валиться на больших проектах с кучей хардкорных темплейтов (но для мелочёвки норм).
                        CLion, в принципе, относительно сойдёт. Ему бы отзывчивость уровня kdevelop — и будет шикарно.
                        QtCreator ещё народ хвалит, но я не осилил, их работа с многотаргетными проектами меня просто убивает, придумать хуже было невозможно.


                      1. BioHazzardt
                        17.12.2021 01:58

                        спасибо) но QtCreator именно для QT хорошо работает, и при разработке на Qt я его в основном и использую, kdevelop ну так себе, вылетает часто, Clion не использовал, попробую


                      1. allcreater
                        17.12.2021 23:33

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

                        Насколько лично мне известно, std::ranges из C++20, предоставляющие функциональный доступ к контейнерам, чуть ли не только в "плюсах" могут работать так же быстро, как написанные от руки циклы, и именно благодаря этой фиче компилятора.

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


                      1. Gordon01 Автор
                        18.12.2021 11:03

                        Насколько лично мне известно, std::ranges из C++20, предоставляющие функциональный доступ к контейнерам, чуть ли не только в "плюсах" могут работать так же быстро, как написанные от руки циклы, и именно благодаря этой фиче компилятора.

                        Это было в расте еще лет 5-7 назад (а может и больше). https://doc.rust-lang.org/std/iter/index.html

                        Ленивое выполнение std::ranges умеют?


                      1. allcreater
                        18.12.2021 14:58

                        Это было в расте еще лет 5-7 назад

                        В более-мене современном виде в C++ оно появилось лет 12 назад в Boost (а первые попытки затащить были в в далёком 2003), но до реализации в стандарте ехало долго: библиотеку полировали, и тем временем учили компилятор не выдавать полотна сообщений в ответ на одну ошибку при инстанциировании шаблона.

                        Ленивое выполнение std::ranges умеют?

                        Так это ж стандартная фича для таких библиотек.


                      1. 0xd34df00d
                        19.12.2021 01:03
                        +1

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


                        У меня были проекты, где TU компилируется без оптимизаций условно пять минут, а с оптимизациями — пять минут тридцать секунд. Остальное время — шаблоны, да.


                        Проблема с шаблонами (по сравнению с аналогичными средствами полиморфизма из более других языков) в том, что подстановка аргумента в шаблон не сводится к подстановке конкретных методов этого объекта. Подстановка аргумента требует практически с нуля распарсить всё тело функции, выполнить name lookup, и так далее. Это долго, больно и неприятно.


                  1. qw1
                    16.12.2021 23:57
                    +4

                    Видишь UB? И я не вижу. А он в моём коде есть…


                1. Alexey2005
                  17.12.2021 01:34
                  +1

                  Конечно не кричат, устали кричать после всех UB.
                  Скорее после настройки окружения и тулчейна в пачке контейнеров, по контейнеру на каждую из целевых платформ. Процесс сборки проекта в C++ абсолютно не кроссплатформенный и по-настоящему мучительный.


          1. Flux
            16.12.2021 23:54
            +2

            Build smaller, faster, and more secure desktop applications with a web frontend

            Язык другой — грабли те же.


        1. spqr_voldi
          17.12.2021 12:35
          +2

          Не надо его убивать, ему просто не надо жить.


      1. vovchisko
        16.12.2021 15:37
        +2

        Слепая ненависть к JS detected :)

        Все зависит от кривизны рук. У меня есть примеры оверлея для игры (более одного), и все летает без просадки FPS. И тот же клиент для БД (забыл как его, зыбал как его, но кажется что-то для mongodb) который тормозит просто когда по нему мышкой водишь.


        1. Revertis
          16.12.2021 15:50

          Так всё зависит от количества текста. Ваш оверлей видимо три строчки выводит и всё.

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


          1. JustDont
            16.12.2021 16:27
            +3

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

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


            1. Revertis
              16.12.2021 16:32
              +1

              Ну как бы я не настоящий JS'ник, я пишу под Андроид и на Расте. А вижу тормоза именно как пользователь. Везде.


              1. JustDont
                16.12.2021 16:39
                +4

                А вижу тормоза именно как пользователь. Везде.

                Я тоже. А потом как "настоящий JS'ник" прихожу куда-нибудь работать и вижу там на фронте список на 100 элементов, который тормозит. Не потому, что список, и не потому, что на 100 элементов. А потому, что фронт написан настолько убого, что перерисовывается целиком на любое действие пользователя (а иногда и на бездействие тоже).


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


                Дело не в HTML, и даже не в JS, а в минимизации затрат на разработку. В конце концов, я как "обычный пользователь" с андроидом вам тоже могу предъявить, что в мобилке кругом почему-то безумно тормозные и забагованные приложения. Видать, чё-то не на расте их пишут ^_^


                1. Alexey2005
                  17.12.2021 01:41

                  Я подозреваю, что их уже и на чистой Java никто не пишет, а юзают какие-то говнофреймворки для ускорения разработки.
                  Недаром же каждый фонарик требует 100500 разрешений, включая доступ к отправке SMS. Сразу видно, что разработчики заюзали какие-то готовые компоненты с параметрами по умолчанию, которые запрашивают всего и побольше.


                  1. SabMakc
                    17.12.2021 12:32
                    +2

                    Это для интеграции рекламы обычно требуется куча разрешений.


              1. Saiv46
                16.12.2021 17:33
                -3

                К слову, как пользователь я вижу что именно приложения на Rust тормозят, в отличии от Electron-приложении (правда с потреблением памяти беда)


                1. Revertis
                  16.12.2021 17:38
                  +3

                  Ух ты, интересно, какие? :)


                1. cepera_ang
                  16.12.2021 17:41
                  +8

                  На расте есть приложения?


                  /s


    1. x8core
      16.12.2021 19:11

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


      1. HemulGM
        18.12.2021 13:56

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


  1. Tanner
    16.12.2021 03:45
    +30

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


  1. zorn-v
    16.12.2021 04:42
    +35

    Электрон это не редактор. Редактор - это atom. Электрон делался для него и изначально назывался atom-shell. Когда поняли что получилось нечто большее, оформили и назвали электрон (атом состоит из электронов).


    1. shnegs
      16.12.2021 09:00
      +39

      атом состоит из электронов

      Вот с этим то знанием они его и написали, электрон этот Ваш:)


      1. zorn-v
        18.12.2021 12:26

        Ну электрон модно хаить, а по факту ?

        Те люди которые пишут гавно на электроне, напишут что то стоящее на с++ ? Вы реально в это верите ?


        1. quwy
          18.12.2021 15:45
          -1

          Те люди которые пишут гавно на электроне, напишут что то стоящее на с++ ?

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


          1. qw1
            18.12.2021 19:17

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


            1. HemulGM
              18.12.2021 20:27
              +1

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


            1. quwy
              19.12.2021 02:34

              А других нормальных инструментов кроме плюсов нет?

              Даже многими порицаемая на десктопе Java в тысячу раз лучше этого электрона поганого.


    1. trokhymchuk
      16.12.2021 09:07
      +13

      атом состоит из электронов

      Не то чтобы электронов там не было, но мне кажется, вы что-то упускаете. ;)


      1. ksbes
        16.12.2021 10:20
        +14

        atom shell (атомная оболочка) состоит из электронов - так что всё правильно.


      1. zorn-v
        17.12.2021 15:41

        Я же не написал ТОЛЬКО из электронов )


    1. Gordon01 Автор
      16.12.2021 10:32

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


  1. Oxyd
    16.12.2021 05:10
    +6

    Да неужели-ж молитвы были услышаны?... Хотя вряд-ли тонны софта будут переписаны под новый фреймворк. :-(


    1. GeneAYak
      16.12.2021 11:10
      +2

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


    1. IvaYan
      16.12.2021 14:13

      Тут еще нужно чтобы новый фреймворк оказался столько же удобным для разработки (сам я под электрон не пишу, поэтому продаю за что купил). Один из факторов успеха электрона в том, что там можно писать на JS-е, знатоков которого полно. При этом зная веб-стек в лице HTML, CSS + JS стало возможным получить настольное приложение почти любому желающему (опять же, качество этих приложений оценивать не хочу сейчас).

      И вот теперь у нас есть фреймворк на Rust (фреймворк ли? я пока понял, что там редактор). Каким будет порог входа в него для не-растоводов?


      1. alexeishch
        16.12.2021 14:53
        +1

        >можно писать на JS-е, знатоков которого полно
        Вот тут я прям в голос засмеялся


      1. kira-dev
        16.12.2021 21:44

        Я не переживу еще один электрон-комбайн в довесок к пятаку электрон-прилаг на своем ноуте


  1. Zeiram
    16.12.2021 06:59
    +3

  1. Mingun
    16.12.2021 07:31
    +20

    Средство текстовой коммуникации, встроенное в редактор

    Вот что-то уже начинает напрягать. Просто сделайте нормальный не тормозящий редактор. С нормальным фолдингом на основе лексера, а не регулярок (поголовно все редакторы не могут нормально свернуть XML в котором есть куски многострочного текста, так как реализуют фолдинг на основе отступов, а не структуры документа). Встраивать всякие свистелки для полутора человек не надо


    1. iliazeus
      16.12.2021 09:13
      +4

      В Language Server Protocol есть folding ranges, поэтому почти любая современная ide должна, в теории, это уметь с плагинами. Попробуйте, например, VSCode вместе с https://marketplace.visualstudio.com/items?itemName=redhat.vscode-xml


    1. shoco
      16.12.2021 10:32
      +2

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


      1. Mingun
        16.12.2021 11:47
        +1

        Проблема в том, что раскраска тоже требует лексера и она-то работает правильно!


    1. Gordon01 Автор
      16.12.2021 10:47
      -2

      Очень полезная и нужная фича.

      Какие сейчас варианты? Кидаться исходниками через мессенджеры? Делать коммиты на каждое изменение, если нельзя вставить исходник в мессенджеры?

      Шарить экран? А если интернет плохой, надо вдвоем редактировать, а коллега вообще не может голосом разговаривать?

      Единственное, чем не отвратительно пользоваться сейчас — это геррит, но это инструмент для ревью.


      1. Mingun
        16.12.2021 11:51
        +5

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


    1. c01nd01r
      16.12.2021 17:52
      +3

      Как вам Sublime Text?


    1. AlexSelivanoff
      17.12.2021 07:09
      +1

      Да што уж там, Zoom сразу встроить можно. Абсолютно непонятно, зачем это нужно в редакторе. Я был очень удивлен, когда нашел для VSCode дополнение Stories


    1. goldrobot
      17.12.2021 16:19

      А я вот не соглашусь.

      Нормальных не тормозящих редакторов вагон и тележка. Да тот же neovim вас удовлетворит.

      Зато нормальных не тормозящих IDE нету. Потому хороший функционал в ядре программы очень даже нужен.


  1. Oblitus
    16.12.2021 08:06

    использующий GPU для рендеринга

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


    1. n0isy
      16.12.2021 09:01
      +1

      Что очень удивительно, ведь современный GPU это как раз сотни одинаковых ядер


      1. Wingtiger
        16.12.2021 10:27
        +6

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


    1. GamePad64
      16.12.2021 13:13
      +2

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


  1. QuAzI
    16.12.2021 08:34
    +19

    и они считают, что Zed не удалось бы создать с помощью других инструментов

    Громкое заявление. Но ничего ж нет. Софта нет, репозитория нет, LSP, не говоря о более навороченных штуках лишь только "будет". Tree-Sitter на треть состоит совсем не из раста.

    Как выше отмечали, электрон и не редактор. Atom редактор. VSCode редактор. До последнего, с контейнерами, удалённой работой по SSH, Live Share и прочим вагоном кастомизаций этим прогрессивным штукам догонять и догонять и ещё большой вопрос, какой перфоманс на метр багов будет при сопоставимом функционале.

    Новость максимально кликбейтная.


    1. k102
      16.12.2021 10:56

      А надо догонять? Я не пользуюсь и половиной из фич vscode, не говоря уже о монстрах типа webstorm. Если они сделают что-то типа атома, но быстрее - отлично, дайте два.


      1. QuAzI
        16.12.2021 11:57
        +3

        VSCode достаточно быстр даже на ужасающе древних штуках типа Np-nc110p, которые хочется выкинуть в окно ещё до того как оно забутается. Если нужно прям ещё быстрее, есть vim. Который по фичам тоже пока впереди. Ну а так, если вам нужен просто блокнот, то спор ни о чём.


        1. k102
          16.12.2021 14:20
          -2

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


          1. QuAzI
            16.12.2021 15:43
            +2

            Не используйте. Достаточно просто не ставить дополнения. Ну и Zen mode + Vim-like navigation в помощь. Более лаконичных адекватных именно IDE не заточенных под "подрыгать только вот этой лампочкой" вам не найти. Но можно лепить монстров из sublime/npp и пытаться выдать тёплое за мягкое


            1. zviryatko
              16.12.2021 22:17

              Долго думал как это "под-рыгать лампочкой", а потом дошло "по-дрыгать".


  1. NeoCode
    16.12.2021 08:47
    +21

    Много лет назад была такая Visual Studio 6, написанная на С/C++ Winapi/MFC. Или ранние версии С++Builder. Прекрасно работали даже на старых машинах (без всяких GPU). А на новых просто летали. Но кому-то понадобилось писать IDE на C#, на Java, на JS... Ну хорошо что одумались и вернулись на язык системного уровня (хотя я все равно не понимаю зачем в этой задаче GPU).

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


    1. trokhymchuk
      16.12.2021 09:12
      +6

      Прекрасно работали даже на старых машинах (без всяких GPU). А на новых просто летали. Но кому-то понадобилось писать IDE на C#, на Java, на JS...

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

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


      1. iliazeus
        16.12.2021 09:22
        +4

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

        Я не думаю, что это так. VSCode и Atom, оба хоть сколько-то популярных Electron-редактора, скомпилированы в js скорее потому, что оба выросли из проектов браузерных редакторов/ide, и во многом ими и остаются (GitHub Codespaces это VSCode, к примеру). В браузере выбор языков и технологий намного меньше, по крайней мере, до широкого распространения тулинга и библиотек для wasm.


        1. Gordon01 Автор
          16.12.2021 13:13
          +3

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

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

          Какую альтернативу вы предложили бы им в 2012 году? wxWidgets?

          Можно сколько угодно болтать о том, что на библиотеке Х из экосистемы С/С++ можно сделать все то же самое, но "нативно" и используя 10 МБ оперативки, но за десять лет эти разговоры так и никуда не переросли, "убийцы" электрона на с/с++ так и не появилось. Как и не появилось возможности использовать асинхронщину и многопоточность в с/с++, так же удобно, как это происходит в современных языках.


          1. iliazeus
            16.12.2021 13:35
            +6

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

            Atom начинался с Ace, собранного в standalone-приложение. VSCode начинался с Monaco, который пилили для всяческих нужд Azure. Да и Visual Studio Online был там с самого начала.

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

            Ага, особенно учитывая, что для Atom этот Electron еще надо было сначала написать. Да и виджетов в нем никаких нет, ребята свои UI-фреймворки писали, фактически.

            Какую альтернативу вы предложили бы им в 2012 году? wxWidgets?

            Из того, что знаю, вполне неплохо чувствовали себя IDE на Java.


            1. Gordon01 Автор
              16.12.2021 14:00
              +4

              Из того, что знаю, вполне неплохо чувствовали себя IDE на Java.

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


              1. iliazeus
                16.12.2021 14:02

                Википедия говорит, что IDEA началась еще в 2001 году. Но, опять-таки, я слишком плохо знаю тогдашний мир IDE.


            1. BioHazzardt
              16.12.2021 16:53

              Из того, что знаю, вполне неплохо чувствовали себя IDE на Java.

              У меня есть старенький ноутбук, с которого иногда приходилось вносить правки в код. Так вот — на vscode я их вносил за то же самое время, за которое IDEA только запускалась


              1. zaiats_2k
                16.12.2021 18:47
                -2

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


                1. BioHazzardt
                  16.12.2021 18:53

                  ну у меня основная рабочая машина — это стационарная пекарня, а ее с собой не потаскаешь, еще есть старенький мак и тот самый ноут (новый не покупаю, т.к. пользуюсь даст бог если раз в полгода). Так уж получилось, что мака под рукой не было. Кстати если говорить про IDE на жабе, идея вполне себе хорошая штука, на какой-нибудь eclipse или netbeans вообще без слез не взглянешь


                1. ALiEN175
                  17.12.2021 01:11
                  +3

                  Это хорошая практика. Прежде чем кидать код в продакшен, возьми и запусти сначала на два ядра/два гига (хотя бы). Может тогда поменьше было бы монструозных поделий программ и веб-страниц, сразу отжирающих половину ресурсов 4-х ядерной машины с 8 гб памяти. Про занимаемое на диске место скромно промолчу, там вообще ад какой-то творится.


          1. IvaYan
            16.12.2021 14:17
            +2

            Какую альтернативу вы предложили бы им в 2012 году? wxWidgets?

            Sublime Text появился в 2008, изначально C++ и Python.


            1. Gordon01 Автор
              16.12.2021 14:28
              +5

              В 2008 он был хорош, но потом стал очередным "продвинутым блокнотом" вплоть до 2020.

              Sublime Text появился в 2008

              Только под Windows.

              К тому времени, как они допилили кросс-платформенность, уже появился Atom.

              Затем, понадобилось еще 7 лет, чтобы допилить это до функционала вскода образца 2015 года.

              В принципе, это все что нужно знать о скорости кросс-платформенной разработки графических приложений на С++.


      1. HemulGM
        18.12.2021 15:24

        В итоге мы получаем засахаренный язык, кторый без него уже не используется. Такими темпами, скоро складывать числа в js нужно будет через сахарный метод sum(a, b)


    1. Gordon01 Автор
      16.12.2021 09:42
      +9

      Только вот студия не кросс-платформенная и написана огромной командой, у которой есть ресурсы, чтобы обмазаться санитайзерами, анализаторами и прочим. Но она все равно падает, а интерфейс может замереть при длительной операции из-за того что написать многопоточное приложение на c/c++ все равно невероятно сложно.

      Последняя студия без плагинов открывает хеллоу-ворлд на моём 12-ядерном компьютере с 32 ГБ оперативки и nvme около 15 секунд. VSCode делает это за 2-3.

      Студия есть под мак, но фронт там переписан с нуля. Версии для линукс нет.


      1. vdudouyt
        16.12.2021 10:27
        -6

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


        1. Starl1ght
          16.12.2021 22:50
          +2

          Даже странно слышать такое про студию

          Так потому-что это вранье. Вижуал студия за 15 секунд вполне грузит себе Unreal Engine 4.

          А вот зачем врать "КАКОЙ МИКРАСОФТ ПЛОХОЙ" - это я уже не знаю. Может ты знаешь? :)


      1. impwx
        16.12.2021 11:02
        +9

        написана огромной командой, у которой есть ресурсы

        Вы прямо досконально знаете, какие у нее ресурсы и какой объем функционала нужно поддерживать, или это диванная аналитика?


        Последняя студия без плагинов открывает хеллоу-ворлд

        Какую вы считаете последней? У меня аналогичная конфигурация — "голая" VS2022 открывает проект с 20K+ SLOC за 3-5 секунд, заметно быстрее чем 2019. С R# — да, получается ближе к 15 секундам, но лично в моем понимании он того стоит.


        Сравнивать с VSCode не совсем корректно, т.к. они в разных весовых категориях — как Paint.NET и Photoshop. К счастью, ими можно пользоваться параллельно, выбирая каждую для подходящих задач.


        1. Gordon01 Автор
          16.12.2021 11:53
          -7

          Сравнивать с VSCode не совсем корректно

          Действительно, вскод — кросс-платформенный, а студия — нет.

          т.к. они в разных весовых категориях — как Paint.NET и Photoshop

          Абсолютно верно. Что студия, что фотошоп — тормозные, падучие и однопоточные монстры. VSCode заменил студию у массового программиста, Affinity Designer заменил фотошоп у массового дизайнера.


          1. impwx
            16.12.2021 12:21
            +13

            Ну вот опять — вы собственный опыт обобщаете на всех.


            Кто такой "массовый программист"? Веб-разработчик? Большинство веб-ориентированных языков динамически (или частично) типизированные, поэтому для разработки на них возможностей VSCode действительно хватает.


            На противоположном конце спектра находится энтерпрайз — банки, предприятия, биржи и тому подобное. Там тоже приличное количество программистов работает. Вы знаете истории, где "vscode заменил студию" в контексте реально крупного энтерпрайзного проекта на Java, .NET, C++? Я не знаю, но с удовольствием послушаю.


            1. Gordon01 Автор
              16.12.2021 14:31

              Работаю в крупном российском кровавом энтерпрайзе (не банке и не бирже).

              Основной редактор по результатам опроса — VSCode, разработка на С/С++.

              Получается, вы собственный опыт обобщаете на всех?


              1. impwx
                16.12.2021 14:39
                +1

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


                1. Gordon01 Автор
                  16.12.2021 14:48
                  -8

                  У меня нет к этому малейшего интереса. Занимайтесь, если вам нужно.

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


                  1. impwx
                    16.12.2021 14:51

                    Очень рад за вас и за ваш опыт :)


      1. gev
        16.12.2021 12:00

        Аналогично, только в сравнении с Idea, Android Studio и XCode


      1. Carburn
        16.12.2021 13:53

        при чем тут C++? VS написана на C#.


        1. darkdaskin
          16.12.2021 16:51
          +1

          Изначально на C++, и только начиная с VS 2012 отдельные части (в основном UI) начали переписывать на C#. Лишь к VS 2022 смогли выпустить 64-битную версию, потому что устаревший плюсовый код не позволял сделать это ранее, хотя потребность была уже давно (приходилось выносить куски кода в отдельные процессы, чтобы уложиться в 32-битное адресное пространство).


          1. Carburn
            16.12.2021 19:17
            -1

            так сейчас не осталось кода c++?


            1. darkdaskin
              18.12.2021 04:07

              Остался, как минимум ядро IDE, отладчик и подсистемы для старых типов проектов. Тем не менее, если 10 лет назад написание расширений к IDE представляло из себя пляски вокруг COM, сейчас всё больше подсистем доступно из .NET напрямую, что сильно упрощает разработку. Навскидку, если посмотреть на запущенный процесс IDE, из 1000+ загруженных DLL нативных осталось порядка пары десятков (не считая входящих в состав Windows).
              И да, в предыдущем комментарии я немного ошибся, переписывать начали с VS 2010.


      1. IvaYan
        16.12.2021 14:20
        +1

        Студия есть под мак, но фронт там переписан с нуля.

        Строго говоря, студия под мак это вроде бывший Xamarin Studio, который к Visual Studio не имеет отношения.


        1. Gordon01 Автор
          16.12.2021 14:33
          -2

          Не знал, тогда все еще хуже)


        1. slonopotamus
          17.12.2021 00:05

          бывший Xamarin Studio

          Который в свою очередь является бывшим MonoDevelop.


      1. KReal
        16.12.2021 17:06

        Последняя студия без плагинов открывает хеллоу-ворлд на моём 12-ядерном компьютере с 32 ГБ оперативки и nvme около 15 секунд. VSCode делает это за 2-3.

        Это странно, на гораздо более слабом железе студия без плагинов открывает и индексирует hello world за те же 2-3 секунды. А без индексации (анализа исходников) открывается солюшен любого размера)


        1. Gordon01 Автор
          16.12.2021 17:12
          -1

          Учитывается еще время на открытие самого редактора. Причем, у студии оно не уменьшается, если уже открыто одно окно.


          1. KReal
            16.12.2021 17:20

            У меня 19я, не 22я, но открывается редактор одну секунду. Может быть в новой версии что-то накосячили, конечно…


      1. Carburn
        18.12.2021 13:09

        Студия есть под мак, но фронт там переписан с нуля

        По-моему это Sublime Text, а не Visual Studio.


    1. joyfolk
      16.12.2021 11:00
      +6

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


      1. Static_electro
        16.12.2021 12:45
        +2

        что-то вы странное помните. В билдере поддержка их диалекта была очень хороша.


        1. joyfolk
          16.12.2021 12:56
          +1

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


      1. speakingfish
        17.12.2021 11:19

        Watcom Optima ещё была — с похожим редактором форм как C++Builder, но с большим числом компонент, фич, гораздо шустрее и компактней и конечно на базе нормального, в отличие от Borland, компилятора C++. Но не выдержала конкуренции с C++Builder.


    1. qw1
      16.12.2021 13:16
      +5

      я все равно не понимаю зачем в этой задаче GPU
      Потому что разрешение экрана 4k. Если напрямую писать во фрейм-буфер, это 1.8ГБ/c (на 60fps)
      Это на порядок ниже теоретического максимума CPU memory bandwidth, но легко в это упереться, если не применять хаки по оптимизации передачи данных.

      А нужно ещё делать что-то осмысленное, не просто blit, а буковки рисовать шрифтами, стили. Если буковки загрузить в текстуру, а всякие стили/фоны делать шейдерами, явно будет быстрее, т.к. GPU умеет всё это аппаратно.


      1. bzq
        16.12.2021 17:57
        +2

        Это проблемы не среды разработки, а GUI. И они данным давно так или иначе решены во всех современных ОС с графическим интерфейсом. Так что я в недоумении, зачем среде разработки нужен GPU, если конечно не считать в фоне крипту.


        1. cepera_ang
          16.12.2021 17:59
          +4

          А как они решены "во всех современных ОС"? Уж не предоставлением API к видеокарте ли? :)


        1. qw1
          16.12.2021 18:12

          А через какое API рисовать, чтобы было переносимым и быстрым? OpenGL неплохо подходит.


    1. avkudrin
      16.12.2021 19:05
      +4

      Да не работали они прекрасно, чего вы придумываете. Синтаксис C++ разбирали с трудом, сложные директивы препроцессора - сразу смерть, используете темплейты - забудьте о нормальном автодополнении. Автоформатирование, рефакторинги? Не, не слышал. Фичи, которые более-менее работали в MSVS6, сейчас есть в каждом первом блокноте. А то, что умеет например, VSCode с плюсовым плагином, да с плагином для системы сборки, да с плагином для системы контроля версий, этого во времена MSVS 6 даже в розовых мечтах разразработчиков не было.


  1. oxdef
    16.12.2021 10:30
    +5

    Странно, что ничего не сказано про лицензию будущего проекта.


  1. RiverFlow
    16.12.2021 10:56
    -24

    Пара олдо-высе*ов про говняшность "этого вашего жээса" и про "ваком-си-под-досом-для-всех" и про то как страшно в 2021 целый гигабайт оперативы сожрать.

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

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

    Электрон это возможность школьнику, преподавателю, учёному, домохозяйке или музыканту выучить ОДИН язык и написать на нем вообще всё и от мобильника до десктопа и веба а сейчас ещё и iot (espruino).

    JS это золотая середина между всяким но-код-ноде scratch и прямым управлением памятью.

    Максимально от высоко-абстрактный, без табунов сферических коней паттернов и ООП.

    И пока вы сообщите свои носики пузатого бородатого трушного мамкиного кодера, на всех этих "JS - макак" и формошлепов, мой знакомый дворник у себя в подсобке лепит на электроне в локалке своей поликлиники приложение для уборщиц, обнажая беспомощность и ненужность всех этих ваших мега-ВТУЗОВ и прибивая ценник разработки к плинтусу!

    Ещё бы вы не пенились своими г*внами )

    На счёт раста я не знаю, и мне пофиг, но непонятно почему rust-убийца node - deno, не умеет жить на arm вообще и 32 бит в частности?

    Если этот "убийца" электрона тоже зазвездится своей трушностью и "скорострельностью" но забудет про дворников в поликлиниках, то пойдёт он туда же куда все эти си-билдеры со студиями.

    Ну и для тех кто до сих пор никак не поймет "зачем весь этот веб-зоопаок" :

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


    1. vdudouyt
      16.12.2021 12:28
      +2

      Так вроде никто и не спорит с тем, что в некоторых случаях (как, например, в приведенных Вами) это может быть хорошо для кодеров. Речь за user experience.


      1. Revertis
        16.12.2021 16:16
        +4

        Речь не за, а про user experience.


    1. cepera_ang
      16.12.2021 12:29
      +25

      Электрон это возможность школьнику, преподавателю, учёному, домохозяйке или музыканту выучить ОДИН язык и написать на нем вообще всё и от мобильника до десктопа и веба а сейчас ещё и iot (espruino).

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


      1. alexdesyatnik
        16.12.2021 20:08
        +1

        Весь софт - нет. Однако вот есть такой пример: Obsidian. Это приложение не идеально, но оно реализует очень интересные идеи, и при этом реализует (а) в браузере, (б) в кроссплатформенном десктопном приложении, (в) в мобильном приложении под Андроид и айОС. Насколько я знаю, разработкой занимаются два (2) человека, инструменты - TypeScript/React/Electron. Скачайте, покрутите функционал, и ответьте на такой вопрос: смогут ли два человека в разумные сроки реализовать что-то подобное с помощью других инструментов? C++/Qt, C#/WPF, что там ещё из живого GUI-шного осталось, вот это всё.

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


        1. cepera_ang
          16.12.2021 20:46

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


          Или может я пропустил какую-то особенную функциональность обсидиана? Что там такого уникального и сложного?


          1. alexdesyatnik
            16.12.2021 21:07
            +1

            Так вы сами же и сказали - возможность сравнительно легко делать плагины, для начала. "Просто" взять браузер и "просто" завернуть туда редактор маркдауна с возможностью расширять внешний вид и функционал плагинами, прикиньте хотя бы примерно, сколько на это усилий потребуется на любой другой платформе для GUI. Насколько я с этим делом знаком (кроме Flutter, не трогал его) - два человека в разумные сроки такое не осилят и близко. Большая команда осилит, да кто только кто денег на неё даст. Путь от идеи до MVP и далее до первых релизов в JS-экосистеме в разы, если не на порядки, короче альтернатив.


            1. cepera_ang
              16.12.2021 21:22

              Путь от идеи до MVP и далее до первых релизов в JS-экосистеме в разы, если не на порядки, короче альтернатив.

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


              1. alexdesyatnik
                16.12.2021 21:51

                Вы упорно утверждаете, что запилить заметочник с браузером - что-то простое. Это не так. До Обсидиана было множество попыток реализовать методику Zettelkasten, ни одна из них не взлетела настолько хорошо, насколько мне известно. Да и если оставить Zettelkasten в покое и забыть про кроссплатформенность и плагины, оставить просто иерархический заметочник - работает оно ровнее и быстрее альтернатив, написанных такими же одиночками на Swing/WinForms/MFC/whatever.


        1. DirectoriX
          16.12.2021 20:51

          Если ваша цель делать и сайт, и приложение, которые полностью (как Discord) или частично (как Obsidian, я не припомню, чтоб там был веб-редактор, видел только возможность опубликовать хранилище на их сервере как сайт) дублируют возможности друг друга — да, в Electron есть смысл. Но как часто вам это действительно нужно?
          С другой стороны, есть, например, Telegram, у которого вполне нативные клиенты для разных платформ, включая веб.
          P.S. сам пользуюсь Obsidian, VS Code, Discord, но на этом список хороших (на мой взгляд) Electron-приложений и заканчивается.


          1. alexdesyatnik
            16.12.2021 21:14

            С Телеграмом сравнение некорректно, у него помимо нативных клиентов есть бэкер-миллиардер, может позволить себе.

            Пример Обсидиана показывает, что эта экосистема даёт возможность быстой разработки достаточно продвинутых в GUI-плане приложений очень малыми усилиями, воплощая в жизнь какие-то интересные идеи, которые в ином случае остались бы либо долгостроем, либо нереализованными вовсе. (Я имею ввиду не Electron конкретно, а скорее всю JS-экосистему, т.к. Electron по большому счёту лишь ещё один рантайм для неё.)


        1. mr_bag
          16.12.2021 21:02

          Именно поэтому Гугл, Инста и т.д. в самом начале строчили на Пайтоне.

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


        1. vtb_k
          17.12.2021 00:28

          Однако вот есть такой пример: Obsidian. Это приложение не идеально, но оно реализует очень интересные идеи

          Кроме "модного" интерфейса в нем ничего интересного нету, а по возможностям оно и 10% не дотягивает до Емаксовского org/org-roam mode


    1. WraithOW
      16.12.2021 12:40
      +8

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

      Ну раз вы богатый и вам не жалко — зашлите эту сотку баксов мне, буду благодарен.


    1. Static_electro
      16.12.2021 12:48
      +3

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

      можно подумать, у веба здесь всё прекрасно...


    1. quillon45
      16.12.2021 13:22
      +7

      Типичный формошлёп.


    1. Alexsey
      16.12.2021 18:04
      +2

      Этим, в принципе, все сказано.


    1. Alex_ME
      16.12.2021 21:25
      +2

      Странно, мне казалось, что между си и nocode не только js, но и множество других языков, популярных и нет, разной степени абстрактности: C#, Java, Kotlin, Go, Rust, D, Dart, Lua... Не JS единым. Тот же C#/Kotlin не сказать бы, что как-то сильно сложнее JS.


    1. 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 фреймворков, позволяющих делать красивый интерфейс.


      1. Chamie
        18.12.2021 02:07

        А как там с accesibility и прочей доступностью для людей с особыми потребностями?


        1. HemulGM
          18.12.2021 12:37

          Например? Я, к сожалению, не сталкивался с такими требованиями.


          1. IvaYan
            18.12.2021 15:13

            Screen Reader-ы для слепых, я думаю.


          1. vsh797
            18.12.2021 16:00

            А они есть, причем всегда. :) И веб, как по мне, наиболее стандартизован и предсказуем в этом плане. Для того, чтобы веб приложение сделать неюзабельным для скринридеров, нужно приложить немалые усилия. И то останется шанс хоть как-то это обойти. А нативные платформы могут просто не иметь должную поддержку accessibility. Ведь обычно "в требованиях это явно не прописано".


            1. HemulGM
              18.12.2021 16:04

              Как правило, вне веба это зависит от платформы. Тот же андроид именно для этого отдельный фреймворк. Через fmx его можно использовать без проблем. Можно импортировать классы java напрямую. Так же и в винде. Доступ к данным окна можно обеспечить без проблем. Например, дня озвучки текста.


              1. vsh797
                18.12.2021 16:18

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

                Со стороны разработчика?


                К сожалению, это не мешает многие годы официальным клиентам viber и telegram быть полностью недоступными на винде. Да и по smartgit я писал разработчикам по этому поводу. Они причем даже пытались что-то сделать, но решения так и не нашли. На андроиде тоже подобных примеров достаточно. Но там скорее халатность вроде неподписанных кнопок и недоступных элементов управления.


                1. HemulGM
                  18.12.2021 18:19

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

                  Ну а в вебе придётся каждый раз что-то особенное использовать.


                  1. vsh797
                    18.12.2021 18:47

                    при генерации вызывать нативного озвутчика.

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


              1. vsh797
                18.12.2021 16:27

                Еще из последнего перевод JetBrains toolbox с web view на собственный Compose Multiplatform. Ребята хвастаются уменьшением размера приложения, увеличением отзывчивости, но accessibility пропало совсем. Обещают в перспективе поправить, но когда конкретно — неизвестно. Но им хотя бы верить можно, ведь их IDE по результатам сознательно проведенной работы вполне доступны. А пока можно сидеть на старой неэффективной версии.
                Причем, что симптоматично, Compose Multiplatform недавно перешел в production ready 1.0 версию. Но accessibility там все еще нет.


  1. gred
    16.12.2021 11:48

    эммм. этот zed какое-то унылое говно, походу. ничего толком нету, из того, чем я бы пользовался. пока останусь на vi/vim как вездеходе, и spacemacs для локального редактирования. ничего лучше пока не видел.


  1. Cheater
    16.12.2021 13:32
    -2

    Специально создали коллизию имен с zed из zsh (встроенный редактор zsh)?

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

    Видимо вдохновлялись трупом xi-editor xi-editor, лучше бы коммитили в него.


  1. 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, при котором при любом изменении пересоздаётся целиком вся иерархия компонентов. При работе с большим количеством кода, при большом количестве элементов на экране, это всё будет тормозить. Можно расходиться, товарищи.


    1. cepera_ang
      16.12.2021 15:54
      +3

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


      1. Gordon01 Автор
        16.12.2021 16:10
        -2

        1. cepera_ang
          16.12.2021 16:37
          +2

          Что должна обозначать эта ссылка? "Посмотрите, рендерить кнопочки и текст можно без тормозов, тут описано как" или "Посмотрите, какая это сложная задача, рендерить миллиард вещей, поддерживаемых современным браузером" (но тогда причём тут редактор кода, он что обязательно должен поддерживать весь груз веба ради отображения этой сотни квадратных панелек и странички текста?)


      1. Revertis
        16.12.2021 16:13

        Проблема не с самой отрисовкой, а с компоновкой и перекомпоновкой когда что-то удаляется из DOM, или что-то вставляется.


        1. cepera_ang
          16.12.2021 16:22

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


          1. Revertis
            16.12.2021 16:31
            +1

            Например, любые списки. Кстати, сколько <span>'ов у вас на одной странице кода?


            1. cepera_ang
              16.12.2021 16:50
              +2

              Каких <span>'ов? Простите, я на веб-девелоперском не говорю :)


      1. WraithOW
        16.12.2021 19:39

        Я сварщик не настоящий, но замечу, что:

        1. современные видеокарты архитектурно заточены под рендеринг миллионов треугольников;
        2. растеризация векторного текста, а в особенности юникода — вещь далеко не самая тривиальная и быстрая (емодзи, лигатуры и прочая порнография, без которой в 2022 выпускать редактор текста как-то моветон).

        В совокупности это обозначает, что львиную долю работы — растеризацию глифов и построение layout'а текста выполняет исключительно CPU, на GPU тут разве что финальный рендеринг получится отгрузить, и это отработает быстро, да.

        Text Rendering Hates You


        1. qw1
          16.12.2021 19:58

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

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

          Построение layout-а копейки, просто из-за объёмов данных. Тут надо 40-60 КБ прошерстить, это в кеш CPU влезет, это не десятки мегабайт графики.


          1. WraithOW
            16.12.2021 21:02

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

            Буква — это не прямоугольник. В этом и суть, что GPU очень хорошо умеет делать вещи, под которые он заточен, например, под вывод треугольников. Рендеринг шрифтов к таким вещам не относится (хотя у Mali вроде есть набор OpenGL-расширений для текста, так что там, возможно, ситуация получше).

            Кто мешает все буквы нужного размера шрифта заранее нарисовать в текстуру, а дальше только ренедерить куски текстуры в нужные места?

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

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

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

            Построение layout-а копейки, просто из-за объёмов данных. Тут надо 40-60 КБ прошерстить, это в кеш CPU влезет, это не десятки мегабайт графики.

            Во-первых, откуда такая оценка? Во-вторых, вы же понимаете, что сложная логика даже на 40-60Кб может занять непристойно много времени? А у вас нет много времени, вам нужно все UI-операции уложить в 16мс.

            Я конечно не исключаю, что вы правы. Но, с одной стороны, есть ваши слова о том, как все просто, с другой — есть объективная реальность, в которой куча разработчиков тратят кучу времени на движки рендеринга текста, с третьей — пользователи на том же хабре, которые регулярно жалуются, что шрифты мыльные. И это в целом намекает, что проблема несколько глубже, чем просто свалить в GPU текст и сказать «рендери!»


            1. qw1
              16.12.2021 21:06

              Я не говорю, что просто. Я пытаюсь опровергнуть утверждение, что GPU в этой задаче делать нечего.


          1. EvilFox
            17.12.2021 00:27

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

            Можно и одним обойтись.


  1. windymindy
    16.12.2021 14:07

    Atom не умеет писать файлы атомарно, возможна потеря данных.
    https://github.com/atom/atom/issues/11406
    Судя по исходникам VSCode у него должна быть такая же проблема, но на последний жалются меньше.


    1. JustDont
      16.12.2021 14:37
      +1

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


  1. tangro
    16.12.2021 15:35
    +2

    Разработка на С / C++ заняла бы слишком много времени и скорее всего закончилась бы неудачей проекта

    Ага, а на Rust она типа уже закончилась, и удачно. Да и вообще, с чего они взяли что на Rust что-то напишется быстрее? Rust безопаснее плюсов, это да. Но не проще, и писать на нём не быстрее.


    1. SabMakc
      16.12.2021 15:42
      +8

      Rust безопаснее плюсов - а значит меньше времени уйдет на отладку. Поэтому и быстрее будет.


      1. Gordon01 Автор
        16.12.2021 16:08
        +8

        Да не только по этому.

        Потому что у раста есть взрослая экосистема, а у плюсов нет ничего.

        Если цель — быстро написать условную Windows 98, то есть что-то падучее, неподдерживаемое уже через несколько лет, с неверной внутренней архитектурой и слабой поддержкой многопоточности/асинхронности, под одну платформу и без внешних библиотек, но работающее реально быстро, то скорость разработки на плюсах и расте будет сравнима.

        Стоит убрать из этого условия хоть что-нибудь, и внезапно оказывается, что приходится обмазываться санитайзерами, анализаторами, valgrind, делать отдельные сборки со всем этим включенным, писать тесты для абсолютно всех сценариев, обязательно прогонять фаззинг, делать отдельные релизные сборки, где все это выключено, делать джобы, которые проверяют что нужные флаги сборки РЕАЛЬНО прокидываются (ведь мы не доверяем никаким инструментам на С++), делать тесты, которые бы сравнивали поведение обеих сборок. Если что-то надо собирать под несколько платформ, то писать мозговыносящие скрипты для симейка, а потом — и вовсе надстройку над симейком. Где-то в перерыве тратить недели на поиск подходящей библиотеки, которая бы делала то что нам нужно нормально (потому что их ровно десять, но понять какая из них стоящая невозможно, пока лично не потестируешь). Ой, мы хотим стороннюю библиотеку... но она собирается тулой XYZ, которая у нас не работает. Придется выбрать другую, которая симейком собирается.

        И это мы еще не дошли до самого написания самой программы!

        И с чего же они взяли что на Rust что-то напишется быстрее?! Удивительно конечно, ведь все так просто, нужно просто приложить старый советский...


        1. tangro
          16.12.2021 19:47
          +2

          Обожемой, у раста нет ничего из вышеописанного просто потому, что у раста пока ещё вообще нет ничего, кроме больших перспектив. Как только на нём начнут реально писать, вот прям в продакшене, вот прям живые люди - внезапно понадобится вот это всё, поскольку языковые преимущества закроют 1% потребностей, а всё остальное как было нужно, так и будет дальше.


          1. AnthonyMikh
            17.12.2021 22:46
            -1

            На Rust прям реально пишут прям живые люди в CloudFlare, Amazon, Dropbox и ещё куче других компаний. Отзывы в основном положительные.


          1. Gordon01 Автор
            18.12.2021 11:09
            -1

            А мужики-то и не знают https://stratis-storage.github.io/


        1. Alex_ME
          16.12.2021 21:46
          +5

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

          Да, C++ сложен, но чаще всего не настолько, как описывают.


        1. IvaYan
          18.12.2021 12:18

          Потому что у раста есть взрослая экосистема, а у плюсов нет ничего.

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

          Например: для линала в плюсах я использую Eigen причем с кастомным BLAS-бекендом (на маках это Accelerate, если что) и ничего подобного для раста я не нашел. Есть nalgebra, но нельзя сторонний бекенд подключить, только их самостийная реализация. Есть rust-blas, который есть обертка над произвольным BLAS-ом, но это именно обертка -- надо самому настраивать данные и дергать низкоуровневые функции.


      1. IvaYan
        16.12.2021 16:22

        Особенно на отладку логики.


        1. SabMakc
          16.12.2021 17:05
          +5

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

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

          Так что - да, на Rust быстрее будет разработка. А главное - надежнее.


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


    1. AnthonyMikh
      16.12.2021 18:03
      +2

      Но не проще, и писать на нём не быстрее.

      И проще, и быстрее. Хотя бы потому что выучить Rust реально, а выучить C++ — нет.


      1. tangro
        16.12.2021 19:50

        Угу, именно поэтому в мире миллион программистов на С/С++ и считанные единицы вакансий по всему миру на расте.


  1. 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 однопоточен


  1. random1st
    16.12.2021 19:59
    +3

    Собственно самого редактора мне найти не удалось. И о чем тогда статья?


  1. Ingulf
    17.12.2021 08:33
    +2

    что-то мне кажется, что боязнь работы с С\С++ немного связана с незнанием новых стандартов и все-таки недостачной квалификацией, для очередного убийцы С++ у него (Rust) немного медленный рост реальных проектов


    1. Alexey2005
      17.12.2021 12:48

      Потому что Rust используется в качестве замены C++ только там, где по какой-то причине нельзя использовать сборку мусора. Если же есть возможность поднять GC, то вместо возни с borrow checker программисты предпочитают юзать Go. И собственно именно Go отжирает основную часть аудитории у C++, и там рост проектов очень даже заметный. А Rust'у достаются крохи вроде написания модулей для ядра Linux.


      1. Alex_ME
        17.12.2021 14:02

        Borrow checker - это не только про управление памятью, но и про потокобезопасность.

        https://habr.com/ru/company/otus/blog/578138/

        На safe Rust нельзя вызвать гонку. Вроде как.


        1. picul
          18.12.2021 04:07

          Нельзя вызвать data race (если использовать safe Rust). Race condition/deadlock полностью поддерживаются.


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