ну не все. Если я правильно понимаю, там минимум один тред бэкенд (нода), один тред фронтэнд (хромой). И еще оно в фоне вызывает туеву хучу тулов типа ctags, и прочих, которые часто крутятся в фоне. Так что я бы не назвал это совсем однопоточным. Скорее, с особо извращенной многопоточностью.

Поздно, репутация у него уже как у говна.

Надо будет обновиться. Хотел в нем свой говнокод писать

ну тулы ctags оно же форкает, и просто через пайпы парсит output, это скорее интеграция внешних инструментов(как gdb в qtcreator~ а не многопоточность. Сам же редактор и его gui был на cep(хромой) соотвественно в рамке одного документа он однопоточен.

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

Кстати, эклипс на 32bit жаве без проблем работает (есди все плагины разом не включпть)... Так что, докатились.

Странно.
Я за Атомом давно не слежу, но VSCODE не тормозит на компе 7ми летней давности как в Python так и в TypeScript

Как говаривал Хрущёв

" - Акуля, что шьёшь не оттуля?

- А, всё равно пороть буду. "

А VSCODE так же данные гуглу сливает как Atom или нет?

Нет, сливает микрософту же.

У нас есть QML, который ваш хтмл/ксс рвёт как Тузик грелку.

А можно было быстренько написать на C++, а потом оптимизировать.

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

Ибо это основная фича Qt - легко клепать кастомные виджеты.

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

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

Переписали на сишечку веб-сервис, серьезно? Эдди бы порадовался.

У Rust (rls) так-то всего 2,5 тыс. установок. Не сказать, что запредельное число.

QML

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

На ЯваСкрипте может тормозить что угодно.

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

Вы же взрослый человек с большим опытом в программировании. Как можно JS называть высокоуровневым?!

2017. Тормозит программа для ручного ввода текста (редактор).

А в VIM'е в режиме ввода нельзя между строками (т.е. внутри длинной строки разбитой на экране на несколько строк) перемещаться вверх вниз без тормозящего переключения в нормальный режим.
И проблему бережно перенесли в nvim)
Идеального редактора нет.

github вроде на ruby

На рельсе если точнее.

и это чувствуется

Каким образом?

Ъ

Ты спутал Ъ с !Ъ.

Переписали на сишечку веб-сервис, серьезно? Эдди бы порадовался.

Не весь, они части какие-то повыносили в C-модули.

и это чувствуется

Каким образом?

Медленно работает (всякие лимиты на диффы повводили, а теперь даже прогресс бар для страниц добавили), причина не только в руби конечно. Но если бы при тех же мощностях код был написан на чём-то, что работает быстрее, то должно бы быть быстрее.

В рельсах обычная практика выносить функционал в C-экстеншены, хотя думаю гитхаб постепенно переходит на go или c++ для таких целей, чтобы хиповее было или как в случае с атомом.
А изначально такой функционал не мог быть написан, нерентабельно — лучше запуститься быстрее. Гитлаб в прямом эфире проходит тот же путь.

всякие лимиты на диффы повводили

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

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

Дифф можно всё равно получить (всегда или практически всегда). И мне кажется, что на про-аккаунтах было аналогично. У них и нагрузка возрасла, на всё же.

Вас уже не вылечить.

Да, vscode тоже поверх electron, но каким-то образом они умудрились сделать его не таким тугим. Тонкостей не знаю. Но по сравнению с тем же Sublime - он всё равно тугой.

У них там правда движок на TS, а не на JS.

Но у них тоже фейлы были: https://github.com/Microsoft/vscode/issues/22900

А при чём тут rls?

Год назад же на ЛОРе обсасывали.

Это была фича Электрон.
Кстати, тайпскрипт компилируется в JS и исполняется JS, так что не понятно что они в Атоме накодили так, что пришлось на на С++ переписывать.

Саблайм, по моему личному мнению, остался в прошлом и уже никогда не догонит даже Атом, не говоря уже о VSCODE.

Это была фича Электрон.

Это «фича» платформы. Никто не мешал им использовать нормальное ядро.

не понятно что они в Атоме накодили так, что пришлось на на С++ переписывать.

Вебмакаки.

Саблайм, по моему личному мнению, остался в прошлом

Тем не менее, у него ещё осталось пару тузов в рукаве.

Это каких-же?

А с каких пор JS позволяет напрямую работать с ресурсами компьютера?

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

• скорость запуска
• работа с большими файлами
• удобный поиск (в vscode унылый)
• история буфера обмена (у vscode только через плагины, что бред)
• темы интерфейса (у vscode только недавно дали возможность цвета менять, но даже шрифт приложения сменить нельзя, что уныло)
• больше «зрелых» плагинов на нормальном ЯП
• Удобный *.sublime-project. task.json я так и не осилил.
• общая производительность
• меньше занимает RAM и HDD

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

Это говно жрало 2 гига памяти...

Бугагашеньки!

Сначала начали тормозить браузеры, потом текстовые редакторы, что дальше? Эмуляторы терминала? /bin/cat?

Эмуляторы терминала?

https://hyper.is/

Нет, не начали. А те разработчики js которые что-то подозревали, на заре ещё использовали nodejs модули на С++.

Наркоманы

Сначала начали тормозить браузеры, потом текстовые редакторы, что дальше?

Внезапно, ... BIOS! причём я уже такое наблюдал. На пне 4-ом была мать 2005-6 года выпуска, она сгорела, поставил новую (2010) и начальная загрузка стала дольше проходить(лого BIOS, найденные устройства до старта ОС). Никто не обращает внимания на такие «мелочи».

А в VIM'е в режиме ввода нельзя между строками (т.е. внутри длинной строки разбитой на экране на несколько строк) перемещаться вверх вниз без тормозящего переключения в нормальный режим.

Можно: gj / gk - вниз / вверх. Или сразу в конфиге:

nnoremap j gj
nnoremap k gk

И проблему бережно перенесли в nvim)

Нет никакой проблемы.

А прикинуть популярность можно сравнив количество плагинов для Atom и VSCode'а.

Неподдерживаемых плагинов?

Гитхаб уже сравнил количество контрибьюторов.

У VSCODE больше чем у Атом;)

Перечитайте внимательно, мною написанное:

в режиме ввода

т.е. INSERT mode, и настройка такая:

vnoremap <Down> gj
vnoremap <Up> gk

Ждём переписывания на Qt

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

Это полный атас. Совсем крыша у людей едет.

Постоянно переключаться в нормал мод (без такой настройки) порой напрягает.

А зачем вам вообще vim, если для вас insert mode является основным?

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

Это не косяк философии vim, а косяк использования инструмента.

Как вообще текстовый редактор тормозить может?