Обычные atomic числа подойдут если у вас переменные никак не зависят друг от друга, а могут и зависеть.
Пример: статистика по вызовам и времени работы функции. С независимыми атомиками может случиться, что на читающей стороне вы получите условные fn_calls_under10ms == 100, fn_calls_under100ms == 10, fn_calls_long == 1, а fn_calls_total == 110 (просто потому что он инкрементируется последним). Иногда это приемлемо, а если нет - придётся или делать atomic<call_stats_struct>, или с мьютексом, с мьютексом как будто бы выглядит проще...
Всё пытался вспомнить, какие слова бесят (или хотя бы раздражают) - и пришёл к выводу, что не столь плохи слова, как их неуместное употребление. У нас в команде устоялось слово "таска" (именно женского рода), но один коллега упорно продолжает использовать в мужском роде, и "сделал таск" в первую очередь воспринимается как "сделал [несколько] таск/тасок", а не "сделал [одну] таску". По уровню раздражения - примерно как комар ночью: вроде и пищит тихо, и не кусает, но ТВОЮ ЖЕ МАТЬ КРОВОСОСУЩУЮ!!
А так иногда используем и совсем уж неграмотные слова, например если опять приходится разбираться в JS-лапше (номинально, у нас в команде нет JS-разработчиков, но влезать в проекты соседних команд всё же иногда приходится), или если Jira опять тормозит и не даёт нормально работать, то они "ЖыЕс" и "Жыра" соответственно. Да, "жи-ши", но нет, в подобные моменты они на "жи" не тянут. А Atlassian - те ещё Атласяны...
Используем AWS. В русскоязычных обсуждениях он простой и понятный "А-Вэ-Эс", а вот если с американцами... Их "Эй-Дабйу-Эс" и длиннее, и сложнее произносить, чем просто "Амазон"/"Эм'зон"
Довольно много времени провожу в англоязычных Дискордах. Заметил, что если человек хоть иногда ошибается в использовании there / they're / their или you're / your - он почти наверняка или из Великобритании, или из Америки. Бывают, конечно, и те, кто просто плохо по-английски говорит, но их сразу видно по напрочь поломанной грамматике.
Моё любимое - это когда кто-то возвращается после отсутствия (или просто стример запускает трансляцию на Твиче), и в чате пишут "Your back!". Что, мать вашу, с его спиной не так, что надо обращать внимание: белая, в огне, вообще отсутствует?
Может быть и так. Основной системой что тогда, что сейчас у меня является Windows (хоть и разрабатываем под Linux, но делаем это удалённо, либо "локально" в WSL). Насколько помню, всякие Thunderbird, LibreOffice, Qt Creator, VS Code имеют одинаковые сочетания клавиш и в Win, и на Linux, и это именно Ctrl+H для замены. ... хотя в Qt Creator может и вообще нет отдельного сочетания для замены, там вроде только Ctrl+F ? Эхх, давно уже им не пользовался...
Как бы то ни было, в моём "везде" это всё равно Ctrl+H , так что для меня CLion был непривычно-неприятной белой вороной. Конечно, были и другие причины, почему он мне не понравился (например, тогда, в 2019, он ещё довольно туго работал с Qt).
Если вам он не подходит, то почему он не должен подходит всем?
Я такого не говорил и даже не подразумевал. Более того, мне вообще без разницы, чем пользуетесь вы или кто-либо другой - старый vi, чуть менее старый vim, neovim, emacs, nano, mcedit, VS Code, IDEA, или вообще LibreOffice Writer, главное чтоб не навязывали свой выбор окружающим.
Не нужно. Плагин, стартует сразу, при старте Vim, а LSP-сервер подгружается в фоне.
Согласен, неверно сформулировал мысль. Хотел сказать что-то вроде " всё равно надо дожидаться LSP для полностью готового окружения". Так-то и в других IDE-редакторах процесс анализа проекта обычно идёт фоном, и можно начинать редактировать файл сильно раньше, чем всё будет готово полностью.
никакой конкретной привязки к прошлому
Логично, что должно быть какое-то разумное ограничение, но речь идёт именно о 80 символах. 80 символов - это примерно треть ширины экрана (обычного, FullHD). Я согласен, что читать текст, размазанный по всей ширине экрана не очень удобно, но ТРЕТЬ? Много проектов перешли на 120 символов в ширину (или требуют их с самого начала), это хотя бы половина экрана получается, спасибо им. Для печати - возможно, около 80 символов в самый раз (хотя опять-таки, почему не 70 и не 90, а именно 80?) Померил только что размер шрифта в "Совершенном коде" Макконнелла от БХВ - там как раз 80 выходит на ширину страницы (20 символов на 3 см). На альбомный же лист спокойно поместились бы все 120...
Что мешает, например, графическим эмуляторам терминалов иметь ширину по умолчанию в те же 120 символов? Но нет, если открыть условный Git Bash или терминал XFCE, то они будут иметь размер 80х24, прям как VT100, прям как перфокарты IBM. Хотя в Windows Terminal, например, осмелились проигнорировать это сомнительное наследие, там размер аж 120х30.
Vim, и тем более vi, теряют популярность из-за форков, того же NeoVim.
А вот почему всё семейство пользуется популярностью (относительной) - нет, не понимаю.
Без супер-конфига (кстати, почему скрипты на vimscript/Lua называют "конфигами", хотя тот же .bashrc - это всё равно скрипт, хоть и настраивающий окружение?) и пачки плагинов сам редактор может выполнять только некоторые... интересные действия, польза которых зачастую сомнительна (типа "прыгнуть на 3 слова вперёд").
С плагинами - это всё равно не "vim такой мощный и удобный", это "плагины такие мощные и удобные, спасибо vim что имеет поддержку плагинов".
Кстати, один из основных аргументов в пользу vi-семейства - "я могу делать то же самое, что и IDE, с помощью LSP". Интересно, что LSP как технологию придумал и реализовал не кто-нибудь из сообщества vim, а ребята из Microsoft для VS Code... Похоже, что vi-сообществу было нормально не уметь подражать IDE, пока не появился другой редактор, который умеет. Вот она, конкуренция, толкающая прогресс.
Аргумент "нужно нажимать меньше клавиш для редактирования" - странный из-за методики подсчёта. В некоторых случаях - да, соглашусь. В некоторых - наоборот. Почему-то vim-пользователи любят считать горячие клавиши современных редакторов/IDE так: "Ctrl+S = два нажатия", а "Ctrl+Shift+S = три", но при этом и d, и D - одно (хотя второе - это явное "Shift+D"), и обычно совсем игнорируют бесконечные Esc.
Скорость работы самого редактора как обычно демонстрируют (например, упомянутый где-то здесь Primeagen)? Правильно - переключаясь между разными файлами, или вовсе между файлом и навигацией по ФС, раз 5 туда-сюда. Разумеется, переключает это всё не сам редактор, а плагин(-ы). Это примерно как демонстрировать комфорт автомобиля открывая и закрывая багажник.
Часто ещё любят хвалить быстрый запуск (по сравнению с IDE). С появлением и распространением LSP, время старта клиента становится несущественным, потому что всё равно надо дожидаться загрузки и готовности этого самого LSP. А замерять время старта только редактора-оболочки... пустые, без проекта, IDE обычно тоже запускаются довольно быстро, особенно нынче, на SSD. Да и обычно этот запуск происходит всего пару раз за день. Это ж за месяц может суммарно накопиться десяток минут разницы, как раз будет время с конфигом поиграться.
В итоге, большинство аргументов в пользу использования vim-семейства как будто бы являются актуальными не столько для разработчиков, сколько для админов, которым и ходить по разным серверам приходится (а там как раз уже стоит vim!), и вносить точечные изменения в произвольные файлы в произвольные моменты времени (тут и может понадобиться та самая "странная навигация" и быстрый запуск).
Несколько другой вопрос про vim-управление в других редакторах/IDE, но это уже больше дело привычки. Я, например, в своё время не подружился с CLion именно потому, что в IDE от JetBrains горячие клавиши, мягко говоря, отличаются от тех, которые можно встретить в большинстве других IDE/редакторах; ключевым отличием для меня стало то, что Replace (в открытом файле) - это почему-то Ctrl+R, хотя везде это Ctrl+H. И нет, я всё равно не понимаю, зачем в современных, графических редакторах может понадобиться модальность.
Ну и наконец нельзя не вспомнить про другие явления, которые "прошли проверку временем". Сколько проектов в своих стандартах форматирования кода до сих пор требуют ширину 80 символов, потому что перфокарты IBM стандарта 1928 года были шириной в 80 символов (а потом "ну так исторически сложилось, значит прошло проверку временем, значит правильно")?
люди там только ради халявы и эксклюзивов, коих нет в стиме
Более чем достаточный аргумент использовать EGS, ведь люди что его, что Steam (что другие лаунчеры) ставят не ради самих лаунчеров, а ради доступных игр.
Как можно путать баш и шелл, если bash и есть shell (один из многих)?
А так, что есть оригинальный sh (который и есть shell), и есть множество потомков-наследников: bash, dash, fish, zsh, и так далее. У них у всех свои собственные фишечки, делающие их не очень совместимыми друг с другом, чего только стоит разное поведение echo в отдельных сценариях.
“консоль гит и консоль гит-баш”.
Git for Windows создаёт ярлык и для Git Bash, и для Git CMD. Они оба откроют консоль, но очень разную.
Всё же стримы на Твиче/Ютубе - это довольно конкретный вид трансляций. Прямых трансляций (и уж тем более прямых включений), передающих аудио-видео-информацию, но которые не назовут стримами (в повседневно-бытовом смысле), очень много:
Телевидение и радио, включая онлайн-версии;
Онлайн-кинотеатры и музыкальные сервисы типа Spotify (хоть они и стриминговые сервисы, да);
Miracast / Chromecast / что там ещё есть для беспроводных экранов;
WebRTC и иже с ним;
Программы / протоколы удалённого доступа - RDP, VNC, и т.д.
Пожалуй, самое большое общее отличие - стримы-стримы передают видео только в одну сторону, от одного ко многим, и у них есть мгновенная обратная связь в виде чата, интегрированного в саму платформу (даже если конкретный стример этот чат и не читает). Ещё обычно стример - это всего 1 человек, а не целая команда, работающая одновременно (хотя есть и всякие киберспортивные трансляции, например).
"Ручка" для именно функции-обработчика, вроде, пошла от Яндекса? И там да, это как раз странный и не совсем корректный перевод.
Но в некоторых компаниях / продуктах почему-то сам путь называют handle (хотя он обычно route, или хотя бы path), и там "ручка" выглядит... чуть менее плохо. Да, handle в этом контексте - это очень локальное соглашение, но, впрочем, и в самой статье тоже есть примеры очень локальных названий, которые у всех в итоге разные.
Логика примерно такая, что есть например handle "/forum/post/<id>", и есть соответствующая функция-handler, отвечающая за обработку handle. В каком-то смысле этот handle соотносится с дескриптором, тоже дескриптует, за что именно он отвечает.
И да, некоторые компании / команды это ещё и переводят как "ручка".
поток-flow... не очень уверен, наверное проектируется.
А совсем без контекста и более привычные понятия не всегда получится отличить, например "терминал был пуст" - какой ещё терминал? Аэропорт без человек? xterm очистили? Терминал оплаты с экраном без надписей? Терминал-разъём, в который не воткнули провод?
мы не пишем для пиццерии пошаговую инструкцию, что делать, а лишь указываем, какую пиццу мы хотим получить
Но ведь рецепт не нужно писать заказчику только потому, что в самой пиццерии уже есть жёстко забитый список императивных рецептов. А вот если вы хотите заказать пиццу "как мой коллега привозил на работу на дни рождения" - вам придётся явно указывать набор ингредиентов... если ваша пиццерия вообще позволяет менять состав.
Впрочем, с функциональными языками (особенно с теми, которые чистые) так и есть - как только доходит до деталей выполнения, то обязательно нужна прослойка-рантайм этих самых "рецептов", а то и железо у нас императивно-пошаговое, и сайд-эффекты нужны (хотя бы ввод-вывод), и ресурсы мало того, что не бесконечные, так ещё их явно запрашивать у ОС надо...
Если в голове нет понимания того для чего нужен vim именно тебе, то и трогать его не нужно, писать комменты и глумится над людьми тоже бессмысленно.
Эта (как и многие другие похожие статьи) страдают обратным: автор настойчиво высказывает мысль, что vim - это объективно хорошо, а всё остальное - плохо. Иногда явно, иногда завуалированно, иногда просто глупо (как вот это "Сделает ли меня более компетентным разработчиком использование Vim? — Да, я могу это гарантировать" в конце).
А, ну и засилье подобных статей. Попробуйте написать статью "Как я перестал бояться и полюбил VS Code / IDEA / Qt Creator / Eclipse / Notepad++"... или нет, просто представьте, что вы увидели такую статью здесь на Хабре. Ну перешёл человек с X на Y, и что, об этом всем рассказывать надо? А вот vim-любители рассказывали и продолжают, хотя те же emacs-любители так себя не ведут (интересно, почему?)
Rust как таковой здесь не важен, просто это единственный пример, для которого у меня есть актуальное время полного запуска LSP-сервера.
Если ваш LSP-сервер делает чуть больше, чем простую подсветку, он тоже будет тратить на анализ при запуске какое-то время. Просто берите проекты больше и больше, и в какой-то момент он тоже будет думать десятки секунд.
Впрочем, некоторые LSP (по ощущениям) при запуске как раз почти ничего не делают, зато потом на каждое действие тратят заметное время. Это ещё сильнее "компенсирует" скорость запуска редактора/IDE, потому что происходит многократно.
Обычные atomic числа подойдут если у вас переменные никак не зависят друг от друга, а могут и зависеть.
Пример: статистика по вызовам и времени работы функции. С независимыми атомиками может случиться, что на читающей стороне вы получите условные
fn_calls_under10ms== 100,fn_calls_under100ms== 10,fn_calls_long== 1, аfn_calls_total== 110 (просто потому что он инкрементируется последним). Иногда это приемлемо, а если нет - придётся или делатьatomic<call_stats_struct>, или с мьютексом, с мьютексом как будто бы выглядит проще...Всё пытался вспомнить, какие слова бесят (или хотя бы раздражают) - и пришёл к выводу, что не столь плохи слова, как их неуместное употребление. У нас в команде устоялось слово "таска" (именно женского рода), но один коллега упорно продолжает использовать в мужском роде, и "сделал таск" в первую очередь воспринимается как "сделал [несколько] таск/тасок", а не "сделал [одну] таску". По уровню раздражения - примерно как комар ночью: вроде и пищит тихо, и не кусает, но ТВОЮ ЖЕ МАТЬ КРОВОСОСУЩУЮ!!
А так иногда используем и совсем уж неграмотные слова, например если опять приходится разбираться в JS-лапше (номинально, у нас в команде нет JS-разработчиков, но влезать в проекты соседних команд всё же иногда приходится), или если Jira опять тормозит и не даёт нормально работать, то они "ЖыЕс" и "Жыра" соответственно. Да, "жи-ши", но нет, в подобные моменты они на "жи" не тянут. А Atlassian - те ещё Атласяны...
Используем AWS. В русскоязычных обсуждениях он простой и понятный "А-Вэ-Эс", а вот если с американцами... Их "Эй-Дабйу-Эс" и длиннее, и сложнее произносить, чем просто "Амазон"/"Эм'зон"
Довольно много времени провожу в англоязычных Дискордах. Заметил, что если человек хоть иногда ошибается в использовании there / they're / their или you're / your - он почти наверняка или из Великобритании, или из Америки. Бывают, конечно, и те, кто просто плохо по-английски говорит, но их сразу видно по напрочь поломанной грамматике.
Моё любимое - это когда кто-то возвращается после отсутствия (или просто стример запускает трансляцию на Твиче), и в чате пишут "Your back!". Что, мать вашу, с его спиной не так, что надо обращать внимание: белая, в огне, вообще отсутствует?
Может быть и так. Основной системой что тогда, что сейчас у меня является Windows (хоть и разрабатываем под Linux, но делаем это удалённо, либо "локально" в WSL). Насколько помню, всякие Thunderbird, LibreOffice, Qt Creator, VS Code имеют одинаковые сочетания клавиш и в Win, и на Linux, и это именно
Ctrl+Hдля замены.... хотя в Qt Creator может и вообще нет отдельного сочетания для замены, там вроде только
Ctrl+F? Эхх, давно уже им не пользовался...Как бы то ни было, в моём "везде" это всё равно
Ctrl+H, так что для меня CLion был непривычно-неприятной белой вороной. Конечно, были и другие причины, почему он мне не понравился (например, тогда, в 2019, он ещё довольно туго работал с Qt).Я такого не говорил и даже не подразумевал. Более того, мне вообще без разницы, чем пользуетесь вы или кто-либо другой - старый vi, чуть менее старый vim, neovim, emacs, nano, mcedit, VS Code, IDEA, или вообще LibreOffice Writer, главное чтоб не навязывали свой выбор окружающим.
Согласен, неверно сформулировал мысль. Хотел сказать что-то вроде " всё равно надо дожидаться LSP для полностью готового окружения". Так-то и в других IDE-редакторах процесс анализа проекта обычно идёт фоном, и можно начинать редактировать файл сильно раньше, чем всё будет готово полностью.
Логично, что должно быть какое-то разумное ограничение, но речь идёт именно о 80 символах. 80 символов - это примерно треть ширины экрана (обычного, FullHD). Я согласен, что читать текст, размазанный по всей ширине экрана не очень удобно, но ТРЕТЬ? Много проектов перешли на 120 символов в ширину (или требуют их с самого начала), это хотя бы половина экрана получается, спасибо им.
Для печати - возможно, около 80 символов в самый раз (хотя опять-таки, почему не 70 и не 90, а именно 80?) Померил только что размер шрифта в "Совершенном коде" Макконнелла от БХВ - там как раз 80 выходит на ширину страницы (20 символов на 3 см). На альбомный же лист спокойно поместились бы все 120...
Что мешает, например, графическим эмуляторам терминалов иметь ширину по умолчанию в те же 120 символов? Но нет, если открыть условный Git Bash или терминал XFCE, то они будут иметь размер 80х24, прям как VT100, прям как перфокарты IBM. Хотя в Windows Terminal, например, осмелились проигнорировать это сомнительное наследие, там размер аж 120х30.
Vim, и тем более vi, теряют популярность из-за форков, того же NeoVim.
А вот почему всё семейство пользуется популярностью (относительной) - нет, не понимаю.
Без супер-конфига (кстати, почему скрипты на vimscript/Lua называют "конфигами", хотя тот же
.bashrc- это всё равно скрипт, хоть и настраивающий окружение?) и пачки плагинов сам редактор может выполнять только некоторые... интересные действия, польза которых зачастую сомнительна (типа "прыгнуть на 3 слова вперёд").С плагинами - это всё равно не "vim такой мощный и удобный", это "плагины такие мощные и удобные, спасибо vim что имеет поддержку плагинов".
Кстати, один из основных аргументов в пользу vi-семейства - "я могу делать то же самое, что и IDE, с помощью LSP". Интересно, что LSP как технологию придумал и реализовал не кто-нибудь из сообщества vim, а ребята из Microsoft для VS Code... Похоже, что vi-сообществу было нормально не уметь подражать IDE, пока не появился другой редактор, который умеет. Вот она, конкуренция, толкающая прогресс.
Аргумент "нужно нажимать меньше клавиш для редактирования" - странный из-за методики подсчёта. В некоторых случаях - да, соглашусь. В некоторых - наоборот. Почему-то vim-пользователи любят считать горячие клавиши современных редакторов/IDE так: "Ctrl+S = два нажатия", а "Ctrl+Shift+S = три", но при этом и d, и D - одно (хотя второе - это явное "Shift+D"), и обычно совсем игнорируют бесконечные Esc.
Скорость работы самого редактора как обычно демонстрируют (например, упомянутый где-то здесь Primeagen)? Правильно - переключаясь между разными файлами, или вовсе между файлом и навигацией по ФС, раз 5 туда-сюда. Разумеется, переключает это всё не сам редактор, а плагин(-ы). Это примерно как демонстрировать комфорт автомобиля открывая и закрывая багажник.
Часто ещё любят хвалить быстрый запуск (по сравнению с IDE). С появлением и распространением LSP, время старта клиента становится несущественным, потому что всё равно надо дожидаться загрузки и готовности этого самого LSP. А замерять время старта только редактора-оболочки... пустые, без проекта, IDE обычно тоже запускаются довольно быстро, особенно нынче, на SSD. Да и обычно этот запуск происходит всего пару раз за день. Это ж за месяц может суммарно накопиться десяток минут разницы, как раз будет время с конфигом поиграться.
В итоге, большинство аргументов в пользу использования vim-семейства как будто бы являются актуальными не столько для разработчиков, сколько для админов, которым и ходить по разным серверам приходится (а там как раз уже стоит vim!), и вносить точечные изменения в произвольные файлы в произвольные моменты времени (тут и может понадобиться та самая "странная навигация" и быстрый запуск).
Несколько другой вопрос про vim-управление в других редакторах/IDE, но это уже больше дело привычки. Я, например, в своё время не подружился с CLion именно потому, что в IDE от JetBrains горячие клавиши, мягко говоря, отличаются от тех, которые можно встретить в большинстве других IDE/редакторах; ключевым отличием для меня стало то, что Replace (в открытом файле) - это почему-то Ctrl+R, хотя везде это Ctrl+H. И нет, я всё равно не понимаю, зачем в современных, графических редакторах может понадобиться модальность.
Ну и наконец нельзя не вспомнить про другие явления, которые "прошли проверку временем". Сколько проектов в своих стандартах форматирования кода до сих пор требуют ширину 80 символов, потому что перфокарты IBM стандарта 1928 года были шириной в 80 символов (а потом "ну так исторически сложилось, значит прошло проверку временем, значит правильно")?
Как вам, нормально на проверенном годами ADM-3A работается в 2023?
Более чем достаточный аргумент использовать EGS, ведь люди что его, что Steam (что другие лаунчеры) ставят не ради самих лаунчеров, а ради доступных игр.
А так, что есть оригинальный sh (который и есть shell), и есть множество потомков-наследников: bash, dash, fish, zsh, и так далее. У них у всех свои собственные фишечки, делающие их не очень совместимыми друг с другом, чего только стоит разное поведение echo в отдельных сценариях.
Git for Windows создаёт ярлык и для Git Bash, и для Git CMD. Они оба откроют консоль, но очень разную.
Профессиональные навыки и навыки общения?
Очевидно же, что в запущенном thread'е открывается stream, а в него пишется stream.
Всё же стримы на Твиче/Ютубе - это довольно конкретный вид трансляций. Прямых трансляций (и уж тем более прямых включений), передающих аудио-видео-информацию, но которые не назовут стримами (в повседневно-бытовом смысле), очень много:
Телевидение и радио, включая онлайн-версии;
Онлайн-кинотеатры и музыкальные сервисы типа Spotify (хоть они и стриминговые сервисы, да);
Miracast / Chromecast / что там ещё есть для беспроводных экранов;
WebRTC и иже с ним;
Программы / протоколы удалённого доступа - RDP, VNC, и т.д.
Пожалуй, самое большое общее отличие - стримы-стримы передают видео только в одну сторону, от одного ко многим, и у них есть мгновенная обратная связь в виде чата, интегрированного в саму платформу (даже если конкретный стример этот чат и не читает). Ещё обычно стример - это всего 1 человек, а не целая команда, работающая одновременно (хотя есть и всякие киберспортивные трансляции, например).
"Ручка" для именно функции-обработчика, вроде, пошла от Яндекса? И там да, это как раз странный и не совсем корректный перевод.
Но в некоторых компаниях / продуктах почему-то сам путь называют handle (хотя он обычно route, или хотя бы path), и там "ручка" выглядит... чуть менее плохо. Да, handle в этом контексте - это очень локальное соглашение, но, впрочем, и в самой статье тоже есть примеры очень локальных названий, которые у всех в итоге разные.
В некоторых компаниях / командах - да, давно :)
Логика примерно такая, что есть например handle "/forum/post/<id>", и есть соответствующая функция-handler, отвечающая за обработку handle. В каком-то смысле этот handle соотносится с дескриптором, тоже дескриптует, за что именно он отвечает.
И да, некоторые компании / команды это ещё и переводят как "ручка".
Да ладно вам, как будто на английском так нельзя: handle (API endpoint) и handle (descriptor). Может быть даже handle handle
Вообще-то получится, если есть хоть какой-то контекст:
поток-thread запускается / выполняется / останавливается;
поток-stream открывается / читается-пишется / закрывается;
поток-flow... не очень уверен, наверное проектируется.
А совсем без контекста и более привычные понятия не всегда получится отличить, например "терминал был пуст" - какой ещё терминал? Аэропорт без человек? xterm очистили? Терминал оплаты с экраном без надписей? Терминал-разъём, в который не воткнули провод?
Но ведь рецепт не нужно писать заказчику только потому, что в самой пиццерии уже есть жёстко забитый список императивных рецептов. А вот если вы хотите заказать пиццу "как мой коллега привозил на работу на дни рождения" - вам придётся явно указывать набор ингредиентов... если ваша пиццерия вообще позволяет менять состав.
Впрочем, с функциональными языками (особенно с теми, которые чистые) так и есть - как только доходит до деталей выполнения, то обязательно нужна прослойка-рантайм этих самых "рецептов", а то и железо у нас императивно-пошаговое, и сайд-эффекты нужны (хотя бы ввод-вывод), и ресурсы мало того, что не бесконечные, так ещё их явно запрашивать у ОС надо...
Эта (как и многие другие похожие статьи) страдают обратным: автор настойчиво высказывает мысль, что vim - это объективно хорошо, а всё остальное - плохо. Иногда явно, иногда завуалированно, иногда просто глупо (как вот это "Сделает ли меня более компетентным разработчиком использование Vim? — Да, я могу это гарантировать" в конце).
А, ну и засилье подобных статей. Попробуйте написать статью "Как я перестал бояться и полюбил VS Code / IDEA / Qt Creator / Eclipse / Notepad++"... или нет, просто представьте, что вы увидели такую статью здесь на Хабре. Ну перешёл человек с X на Y, и что, об этом всем рассказывать надо? А вот vim-любители рассказывали и продолжают, хотя те же emacs-любители так себя не ведут (интересно, почему?)
Rust как таковой здесь не важен, просто это единственный пример, для которого у меня есть актуальное время полного запуска LSP-сервера.
Если ваш LSP-сервер делает чуть больше, чем простую подсветку, он тоже будет тратить на анализ при запуске какое-то время. Просто берите проекты больше и больше, и в какой-то момент он тоже будет думать десятки секунд.
Впрочем, некоторые LSP (по ощущениям) при запуске как раз почти ничего не делают, зато потом на каждое действие тратят заметное время. Это ещё сильнее "компенсирует" скорость запуска редактора/IDE, потому что происходит многократно.